linux-kernel - Re: rc6+ regression - backlight reset to 0 on boot after 7c0ea45be4f114d85ee35caeead8e1660699c46f

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200804032234.03605.arvidjaar@mail.ru>
Date:	Thu, 3 Apr 2008 22:34:01 +0400
From:	Andrey Borzenkov <arvidjaar@...l.ru>
To:	Zhao Yakui <yakui.zhao@...el.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: rc6+ regression - backlight reset to 0 on boot after 7c0ea45be4f114d85ee35caeead8e1660699c46f

On Thursday 03 April 2008, Zhao Yakui wrote:
> On Wed, 2008-04-02 at 22:53 +0400, Andrey Borzenkov wrote:
> > Commit 7c0ea45be4f114d85ee35caeead8e1660699c46f registers ACPI backlight
> > even if _BQC method (query current backlight level) is missing. The effect is:
> > 
> > during initialization video.c:acpi_video_device_find_cap() calls backlight_update_status(). It tries to fetch actual level via acpi_video_get_brightness() - but as _BQC is missing it just returns current value
> > as stored in memory - i.e. zero, because it was never set. So effectively
> > backlight_update_status() reset brightness to minimal value == 0.
> > 
> > This happens on Toshiba Portege 4000. Verified by reverting commit on top of
> > rc8.
> It seems that _BQC object is missing on the Toshiba Portege 4000. And
> acpi video driver will continue to update the status of backlight even
> when _BQC object is missing, which is inappropriate. 
> Maybe it is more appropriate that OS doesn't update the status of
> backlight in boot phase when _BQC object is missing.
> 
> Of course please attach the output of acpidump in kernel bugzilla.
> http://bugzilla.kernel.org/show_bug.cgi?id=10387

While patch in this bugzilla fixes this immediate regression, I still think
this commit should be reverted for 2.6.25 to discuss design a bit more.
Rationale:

- on systems without _BQC it makes sysfs attribute actual_brightness useless.
Semantic of this is to return *real* brightness as reported by hardware; but
this is noop without _BQC. So currently ACPI simply lies about its value.
If we are going support hardware without _BQC we probably should not define
->get_brightness at all allowing read of actual_brightness to fail.

- on at least some Toshibas we already have brightness control via HCI
(toshiba_acpi):

{pts/0}% ll /sys/class/backlight
итого 0
lrwxrwxrwx 1 root root 0 2008-04-03 22:20 acpi_video0 -> ../../devices/virtual/backlight/acpi_video0/
lrwxrwxrwx 1 root root 0 2008-04-03 22:19 toshiba -> ../../devices/virtual/backlight/toshiba/

both of them refer to exactly the same hardware which is rather confusing.
Something has to be done about it. This is even more confusing because ...

- ... on those old Toshibas ACPI brightness control is far inferior. It
effectively supports only three level of brightness while tochiba_acpi
supports seven of them. So there is no need to keep inferior implementation
if more advanced already exists and works just fine.

This has strong chances of confusing user space about which control is real.
So I think we really have to refrain from pushing this unless the issues above
are settled.

Download attachment "signature.asc " of type "application/pgp-signature" (198 bytes)