Bug 12235

Reply-To: akpm@linux-foundation.org


(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Tue, 16 Dec 2008 03:36:11 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=12235
> 
>            Summary: /sys/devices/virtual/backlight/acpi_video0/brightness
>                     has it backwards
>            Product: ACPI
>            Version: 2.5
>      KernelVersion: 2.6.28-rc8
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Power-Video
>         AssignedTo: acpi_power-video@kernel-bugs.osdl.org
>         ReportedBy: khashayar.lists@gmail.com
> 
> 
> Latest working kernel version:
> 2.6.27
> 
> Earliest failing kernel version:
> probably 2.6.28-rc1, but could be later in the release candidates.
> 
> Distribution:
> Ubuntu 8.10
> 
> Hardware Environment:
> Asus, N20A, all intel.
> 
> Problem Description:
> If the laptop loads the video module at boot time,
> /sys/devices/virtual/backlight/acpi_video0/brightness is created. However,
> it's
> all backwards, confusing applications like gnome-power-manager and the likes
> (well, that basically means hal). Echoing 0 to 'brightness' raises the
> backlight of this laptop to maximum. Echoing 13 to it, takes the backlight to
> a
> minimum. 
> actual_brightness' seems to stay at 0 at all times.
> 
> If I disalllow the video module to be loaded at boot time, there's no
> backlight
> interface in /sys/class/backlight/*. But, nevertheless, the xbacklight
> utility
> and hal seem to be able to control the backlight just fine. In this latter
> case, withouth the video module loaded, xbacklight & hal handle the backlight
> correctly, i.e. less means lower backlight, and more means brighter
> backlight.
> 
> I just confirmed this problem exists with the latest git from Linus' tree, as
> well as the rc8 patch.
> 
> If I remember correctly, the 2.6.27-series created an interface under
> /sys/devices/platform/asus-laptop/ for controlling backlight which worked
> just
> fine.
> 
> Please let me know what additional information to post. I'd love to have this
> fixed before the 2.6.28 release.

OK, that's weird.  I have a suspicion that we're about to find out that
this is intentional, but I don't know what the fix is..

Reply-To: mjg59@srcf.ucam.org

On Tue, Dec 16, 2008 at 10:00:23AM -0800, Andrew Morton wrote:

> OK, that's weird.  I have a suspicion that we're about to find out that
> this is intentional, but I don't know what the fix is..

My recollection is that some BIOSes provide the list of brightness 
values in reverse order - someone posted a patch to sort them in-kernel, 
but I can't remember what happened to it. xbacklight will work because 
it triggers a direct write to the hardware if the acpi driver isn't 
loaded.

On Wed, 2008-12-17 at 04:55 +0800, Matthew Garrett wrote:
> On Tue, Dec 16, 2008 at 10:00:23AM -0800, Andrew Morton wrote:
> 
> > OK, that's weird.  I have a suspicion that we're about to find out that
> > this is intentional, but I don't know what the fix is..
> 
> My recollection is that some BIOSes provide the list of brightness 
> values in reverse order - someone posted a patch to sort them in-kernel, 
> but I can't remember what happened to it. xbacklight will work because 
> it triggers a direct write to the hardware if the acpi driver isn't 
> loaded.
> 
right, this seems to be a duplicate of
http://bugzilla.kernel.org/show_bug.cgi?id=12037

khashayar,
please attach the result of "grep . /proc/acpi/video/*/*/*".
please try the patch in
http://bugzilla.kernel.org/show_bug.cgi?id=12037#c5
and see if it helps.

thanks,
rui

On Wed, Dec 17, 2008 at 1:57 AM, Zhang Rui <rui.zhang@intel.com> wrote:
> On Wed, 2008-12-17 at 04:55 +0800, Matthew Garrett wrote:
>> On Tue, Dec 16, 2008 at 10:00:23AM -0800, Andrew Morton wrote:
>>
>> > OK, that's weird.  I have a suspicion that we're about to find out that
>> > this is intentional, but I don't know what the fix is..
>>
>> My recollection is that some BIOSes provide the list of brightness
>> values in reverse order - someone posted a patch to sort them in-kernel,
>> but I can't remember what happened to it. xbacklight will work because
>> it triggers a direct write to the hardware if the acpi driver isn't
>> loaded.
>>
> right, this seems to be a duplicate of
> http://bugzilla.kernel.org/show_bug.cgi?id=12037
>
> khashayar,
> please attach the result of "grep . /proc/acpi/video/*/*/*".
> please try the patch in
> http://bugzilla.kernel.org/show_bug.cgi?id=12037#c5
> and see if it helps.
>
Here's the output of "grep . /proc/acpi/video/*/*/*". The video module
wasn't loaded at boot time, but just before greping. I don't know if
that has any relevance. Also, there's an external display attached at
this point.

/proc/acpi/video/VGA/CRTD/brightness:<not supported>
/proc/acpi/video/VGA/CRTD/EDID:<not supported>
/proc/acpi/video/VGA/CRTD/info:device_id:    0x0100
/proc/acpi/video/VGA/CRTD/info:type:         CRT
/proc/acpi/video/VGA/CRTD/info:known by bios: yes
/proc/acpi/video/VGA/CRTD/state:state:     0x1d
/proc/acpi/video/VGA/CRTD/state:query:     0x00
/proc/acpi/video/VGA/DVID/brightness:<not supported>
/proc/acpi/video/VGA/DVID/EDID:<not supported>
/proc/acpi/video/VGA/DVID/info:device_id:    0x0321
/proc/acpi/video/VGA/DVID/info:type:         DVI
/proc/acpi/video/VGA/DVID/info:known by bios: yes
/proc/acpi/video/VGA/DVID/state:state:     0x1d
/proc/acpi/video/VGA/DVID/state:query:     0x00
/proc/acpi/video/VGA/HDMI/brightness:<not supported>
/proc/acpi/video/VGA/HDMI/EDID:<not supported>
/proc/acpi/video/VGA/HDMI/info:device_id:    0x7320
/proc/acpi/video/VGA/HDMI/info:type:         DVI
/proc/acpi/video/VGA/HDMI/info:known by bios: yes
/proc/acpi/video/VGA/HDMI/state:state:     0x1d
/proc/acpi/video/VGA/HDMI/state:query:     0x00
/proc/acpi/video/VGA/LCDD/brightness:levels:  100 91 86 81 76 70 65 60
55 50 45 40 35 30 25 20
/proc/acpi/video/VGA/LCDD/brightness:current: 86
/proc/acpi/video/VGA/LCDD/EDID:<not supported>
/proc/acpi/video/VGA/LCDD/info:device_id:    0x0410
/proc/acpi/video/VGA/LCDD/info:type:         LCD
/proc/acpi/video/VGA/LCDD/info:known by bios: yes
/proc/acpi/video/VGA/LCDD/state:state:     0x1d
/proc/acpi/video/VGA/LCDD/state:query:     0x00


I will try the patch as soon as I can, and get back to you.

> thanks,
> rui
>
Thank you,
Khash.

On Wed, Dec 17, 2008 at 10:44 AM, Khashayar Naderehvandi
<khashayar.lists@gmail.com> wrote:
> On Wed, Dec 17, 2008 at 1:57 AM, Zhang Rui <rui.zhang@intel.com> wrote:
>> On Wed, 2008-12-17 at 04:55 +0800, Matthew Garrett wrote:
>>> On Tue, Dec 16, 2008 at 10:00:23AM -0800, Andrew Morton wrote:
>>>
>>> > OK, that's weird.  I have a suspicion that we're about to find out that
>>> > this is intentional, but I don't know what the fix is..
>>>
>>> My recollection is that some BIOSes provide the list of brightness
>>> values in reverse order - someone posted a patch to sort them in-kernel,
>>> but I can't remember what happened to it. xbacklight will work because
>>> it triggers a direct write to the hardware if the acpi driver isn't
>>> loaded.
>>>
>> right, this seems to be a duplicate of
>> http://bugzilla.kernel.org/show_bug.cgi?id=12037
>>
>> khashayar,
>> please attach the result of "grep . /proc/acpi/video/*/*/*".
>> please try the patch in
>> http://bugzilla.kernel.org/show_bug.cgi?id=12037#c5
>> and see if it helps.
>>
> Here's the output of "grep . /proc/acpi/video/*/*/*". The video module
> wasn't loaded at boot time, but just before greping. I don't know if
> that has any relevance. Also, there's an external display attached at
> this point.
>
> /proc/acpi/video/VGA/CRTD/brightness:<not supported>
> /proc/acpi/video/VGA/CRTD/EDID:<not supported>
> /proc/acpi/video/VGA/CRTD/info:device_id:    0x0100
> /proc/acpi/video/VGA/CRTD/info:type:         CRT
> /proc/acpi/video/VGA/CRTD/info:known by bios: yes
> /proc/acpi/video/VGA/CRTD/state:state:     0x1d
> /proc/acpi/video/VGA/CRTD/state:query:     0x00
> /proc/acpi/video/VGA/DVID/brightness:<not supported>
> /proc/acpi/video/VGA/DVID/EDID:<not supported>
> /proc/acpi/video/VGA/DVID/info:device_id:    0x0321
> /proc/acpi/video/VGA/DVID/info:type:         DVI
> /proc/acpi/video/VGA/DVID/info:known by bios: yes
> /proc/acpi/video/VGA/DVID/state:state:     0x1d
> /proc/acpi/video/VGA/DVID/state:query:     0x00
> /proc/acpi/video/VGA/HDMI/brightness:<not supported>
> /proc/acpi/video/VGA/HDMI/EDID:<not supported>
> /proc/acpi/video/VGA/HDMI/info:device_id:    0x7320
> /proc/acpi/video/VGA/HDMI/info:type:         DVI
> /proc/acpi/video/VGA/HDMI/info:known by bios: yes
> /proc/acpi/video/VGA/HDMI/state:state:     0x1d
> /proc/acpi/video/VGA/HDMI/state:query:     0x00
> /proc/acpi/video/VGA/LCDD/brightness:levels:  100 91 86 81 76 70 65 60
> 55 50 45 40 35 30 25 20
> /proc/acpi/video/VGA/LCDD/brightness:current: 86
> /proc/acpi/video/VGA/LCDD/EDID:<not supported>
> /proc/acpi/video/VGA/LCDD/info:device_id:    0x0410
> /proc/acpi/video/VGA/LCDD/info:type:         LCD
> /proc/acpi/video/VGA/LCDD/info:known by bios: yes
> /proc/acpi/video/VGA/LCDD/state:state:     0x1d
> /proc/acpi/video/VGA/LCDD/state:query:     0x00
>
>
> I will try the patch as soon as I can, and get back to you.
>

I've now tried the patch and can confirm that it fixes the problem.
Well, almost; I'm now having the same issue reported in comment 8,
http://bugzilla.kernel.org/show_bug.cgi?id=12037#c8.

But that, I guess, is a whole other thing. Thanks for this one, though!

Will the patch be part of the 2.6.28 final release?

Regards,
Khash.

For the dark screen issue, please open a new bug report. :)
I think the patch will be queued for 2.6.29.

*** This bug has been marked as a duplicate of bug 12037 ***

Khashayar,
please follow the suggestion in http://bugzilla.kernel.org/show_bug.cgi?id=12249#c34 and see if it helps.

*** This bug has been marked as a duplicate of bug 12249 ***

hi, please follow the instructions in
http://bugzilla.kernel.org/show_bug.cgi?id=12249#c60
to see if the patch helps.

hi, the previous patch you tested is not for upstream kernel.
please try this patch in
http://bugzilla.kernel.org/show_bug.cgi?id=12249#c69