New: /sys/devices/virtual/backlight/acpi_video0/brightness has it backwards

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: [email protected]
        ReportedBy: [email protected]

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..

Quoted 2 lines · Andrew Morton

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.

Quoted 11 lines · Matthew Garrett

Quoted 2 lines · Andrew Morton

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

Quoted 12 lines · Zhang Rui

Quoted 11 lines · Matthew Garrett

Quoted 2 lines · Andrew Morton

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.

Quoted 9 lines

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.