[asus] /sys/devices/virtual/backlight/acpi_video0/brightness has it backwards

Bug #320874 reported by Khashayar Naderehvandi
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Linux
Fix Released
Medium
linux (Ubuntu)
Incomplete
Medium
Unassigned

Bug Description

From the upstream bug report:
"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 disallow 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."

More info in the upstream bug report, which I filed some time ago. It's fixed in mainline for 2.6.29, but won't be backported to vanilla. I think Ubuntu should include it, however, as it's a major annoyance and regression.

Thanks!

Changed in linux:
status: Unknown → Invalid
Changed in linux:
status: Invalid → Unknown
Changed in linux:
status: Unknown → Incomplete
Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

I realized my upstream bug report was marked a duplicate. Changed the link to the linux kernel bug tracker to reflect that.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Thanks Khashayar,

I'm just including the upstream git commit id for the Ubuntu kernel team to reference. Thanks.

ogasawara@yoji:~/linux-2.6$ git log -p 935e5f290ec1eb0f1c15004421f5fd3154380fd5

commit 935e5f290ec1eb0f1c15004421f5fd3154380fd5

Author: Zhang Rui <email address hidden>

Date: Thu Dec 11 16:24:52 2008 -0500

    ACPI: video: Fix reversed brightness behavior on ThinkPad SL series

    Section B.6.2 of ACPI 3.0b specification that defines _BCL method

    doesn't require the brightness levels returned to be sorted.

    At least ThinkPad SL300 (and probably all IdeaPads) returns the

    array reversed (i.e. bightest levels have lowest indexes), which

    causes the brightness management behave in completely reversed

    manner on these machines (brightness increases when the laptop is

    idle, while the display dims when used).

    Sorting the array by brightness level values after reading the list

    fixes the issue.

    http://bugzilla.kernel.org/show_bug.cgi?id=12037

    Signed-off-by: Zhang Rui <email address hidden>

    Tested-by: Lubomir Rintel <email address hidden>

    Signed-off-by: Len Brown <email address hidden>

Changed in linux:
importance: Undecided → Medium
status: New → Triaged
Andy Whitcroft (apw)
Changed in linux:
assignee: nobody → apw
status: Triaged → In Progress
Revision history for this message
Andy Whitcroft (apw) wrote :

I have pulled this patch down and applied it to the Jaunty kernel. I have built some test kernels including this patch if you could test those and report back here. The kernels can be found at the URL below:

    http://people.ubuntu.com/~apw/lp320874-jaunty/

Changed in linux:
status: In Progress → Incomplete
Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

Andy, the new kernel does not work for me. New behavior:

+ /sys/devices/virtual/backlight/acpi_video0/brightness seems to work accurately.
+ "xbacklight -set" works accurately
- "xbacklight" does not read backlight values properly (it always returns 0.00000)
- Fn-brightness buttons don't work as they should: Pressing brightness down, brightness goes all the way to 0 and the osd. Brightness up, changes brightness level to 1. That's it, 0 and 1 for down and up.
- gnome-power-manager & brightness applet do not work properly

Back when I filed the upstream bug report, the patch in http://bugzilla.kernel.org/show_bug.cgi?id=12235 solved the issue for me. When my report was marked a duplicate, I was pointed to the patch here: http://bugzilla.kernel.org/show_bug.cgi?id=12249#c34, but haven't had time to try it. However, that patch is not the one you used for the new kernel: http://people.ubuntu.com/~apw/lp320874-jaunty/0001-ACPI-video-Fix-reversed-brightness-behavior-on-Thi.patch. So I'm a bit confused which patch actually is supposed to fix this issue :-/

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

This bug is particularly important to fix for kubuntu users. In ubuntu, blacklisting the video module gives a working desktop environment, as gnome-power-manager apparently handles the backlight by some other means. The KDE power manager, however, doesn't seem to have this alternate way of controlling the backlight.

I personally think the importance on this bug should be bumped as it's 1) a regression, and 2) really bad for laptop users wrt power consumption and battery life. There are reports that the issue indeed is fixed in 2.6.29, so I backport should be possible.

Changed in linux:
status: Incomplete → In Progress
Revision history for this message
Chris Jones (cmsj) wrote :

is this a duplicate of bug #311716 ?

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

Note sure if it's a dupe. I'm seeing the problem on Jaunty with a 2.6.28 kernel, so it probably isn't.

One note about this bug: I tried running on kernel 2.6.29-rc4 and with that kernel the values in /sys/devices/virtual/backlight/acpi_video0/brightness work properly. That is, the values from 0 to 13 correspond to the backlight where 0 is lowest possible and 13 is highest possible. However, the userspace tools didn't work the way they should. Neither xbacklight, gnome-power-manager, nor the fn-keys worked well. The changed the backlight in what seemed to be a random manner.

Changed in linux:
status: In Progress → Incomplete
Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

The upstream bug is now resolved, and as far as I understand it, the fix is a general acpi-video fix that possibly could close a number of bugs for jaunty.

I haven't had time to test yet, but it would be great if one of our kernel guys could take a look at it.

Revision history for this message
Andy Whitcroft (apw) wrote :

Those patches are very new, when they hit someones tree we can try them out.

Changed in linux:
status: Incomplete → Fix Released
Changed in linux:
status: Fix Released → Confirmed
Changed in linux:
status: Confirmed → Incomplete
Changed in linux:
status: Incomplete → Fix Released
Revision history for this message
Andy Whitcroft (apw) wrote :

The fixes referred to in the linked bug are now included in Karmic so this is Fix Released there. Also the latest -proposed has fixes to ensure the brightness values are ordered correctly. If you could test one of those and report back that would be helpful.

Changed in linux (Ubuntu):
status: Incomplete → In Progress
status: In Progress → Incomplete
Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

For what it's worth, the backlight seems to work as expected in Kubuntu Karmic. Unfortunately, I don't have an Ubuntu/Karmic installation to try out at the moment.

When it comes to Jaunty, I've completely given up on the intel stack and am currently running what's available from the xorg-edgers PPA (including kernel)...

I'm happy to have this changed to "Fix Released" as it works fine under KDE. If you want me to try it out with gnome-power-manager as well, however, let me know here, and I'll do an apt-get install ubuntu-desktop.

Andy Whitcroft (apw)
Changed in linux (Ubuntu):
assignee: Andy Whitcroft (apw) → nobody
Changed in linux:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.