Latest working kernel version: 2.6.27 Earliest failing kernel version: 2.6.28 Distribution: Debian unstable / experimental Hardware Environment: Asus M51VR Laptop Software Environment: Debian unstable with xorg 7.4 / server 1.5 / gnome / asus_laptop acpi module Problem Description: I have a problem with the screen brightness level control. I can control the screen brightness with the brightness up and down keys. However when I keep on pressing the brightness level up button, the screen brightness goes up till the brightness level reach its maximum value and then it falls to the lowest value and start increasing again. Please let me know if you need more information (Additional software version / log or debug output). Regards, Jonathan Dray Steps to reproduce: 1. swith the lid sensor to off and 2. raise the brightness level with the appropriate keys.
Hi, Jonathan From the description it seems that this is a regression. Will you please use git-bisect to identify the commit which causes the regression? Of course please attach the output of acpidump, dmesg. thanks.
please attach the output of "grep . /proc/acpi/video/*/*/*" in both .27 and .28 kernel. please kill acpid, run "cat /proc/acpi/event" and attach the output when pressing the brightness level up hotkey for 3 times.
Created attachment 19844 [details] Debug output information on 2.6.27.10 kernel This archive contains : - the output of dmesg - the outpu of acpidump - information displayed on /proc/acpi/event after pressing the times on brightness up button - grep . /proc/acpi/video/*/*/* output
Created attachment 19845 [details] Debug output information on 2.6.28 kernel This archive contains : - the output of dmesg - the outpu of acpidump - information displayed on /proc/acpi/event after pressing the times on brightness up button - grep . /proc/acpi/video/*/*/* output
Created attachment 19849 [details] Debug output information on 2.6.29-rc1 kernel This archive contains : - the output of dmesg - the outpu of acpidump - information displayed on /proc/acpi/event after pressing the times on brightness up button - grep . /proc/acpi/video/*/*/* output
Hi, I attached acpi and dmesg information for the 3 kernels. The behaviour of the brightness keys is different with the 3 kernels : - on the 2.6.27.10 kernel : the screen brightness is evolving normally when pressing the brightness up and down keys - on the 2.6.28 kernel : the brightness controls are inverted - on the 2.6.29-rc1 kernel : the behaviour is the one described in my first comment. I'm new to kernel debugging with git. Could you please give me more information for using git-bisect please ? Thank you Jonathan Dray
Hi, Jonahan How about this issue if you add the boot option of "acpi_backlight=vendor" on the 2.6.28 kernel? Thanks.
Hi, Jonathan Will you please checkwhether there exists the platform backlight interface on the 2.6.28/2.6.29-rc1 kernel? (/sys/class/backlight/asus-laptop/*) Thanks.
Hi Yakui, It seems that without the acpi_backlight boot option, the wrong backlight class get loaded. Here are the /sys/class/backlight tree for both cases : * Without acpi_backlight option : /sys/class/backlight/acpi_video0 - actual_brightness - bl_power - brightness - max_brightness - power - subsystem - uevent * With acpi_backlight=vendor option : /sys/class/backlight/asus_laptop - actual_brightness - bl_power - brightness - max_brightness - power - subsystem - uevent The brightness level works fine with the boot option activated and the brightness tuning seems to be more precise. Do I need to always force this boot option on my laptop or is it the case because of a bug ? I keep this on my boot options meantime. Thanks. Regards, Jonathan Dray
Thanks for the test. It seems that the backlight can't work well when it is registered by generic ACPI video driver. But it can work well if it is registered as platform backlight. After the following commit is shipped, the generic backlight interface will be preferred when the backlight can be registered by platform driver and ACPI video driver. >commit c3d6de698c84efdbdd3781b7058bcc339ab43da8 >Author: Thomas Renninger <trenn@suse.de> >Date: Fri Aug 1 17:37:55 2008 +0200 >ACPI video: if no ACPI backlight support, use vendor drivers Of course I will continue to investigate why the ACPI backlight interface can work on your box. Thanks.
Will you please add the boot option of acpi_osi="!Windows 2006" on the 2.6.28/2.6.29-rc1 kernel and see whether the backlight can work well? (Unnecessary to add the option of acpi_backlight=vendor). It will be great if you can attach the output of /proc/acpi/event when the hotkey is pressed. (Of course you should kill the process which is using the /proc/acpi/event). Thanks.
Hi, First, I would to thank you for the time you're spending on this issue. I switched the boot option to acpi_osi="!Windows 2006". The backlight is registered by the generic ACPI video driver again. (/sys/class/backlight/acpi_video0). Unfortunately, The brightness level adjustement fails again. I stopped the acpi daemon and attached the output of /proc/acpi/event to this message. One more precision which might be useful here: I'm using radeonhd as my video driver. I should try to switch to ati proprietary driver (fglrx) to see if the backlight is handled properly.
Created attachment 19914 [details] /proc/acpi/event output with acpi_osi="!Windows 2006" boot option activated
Created attachment 19944 [details] try the custom DSDT Will you please try the custom DSDT on the latest kernel(2.6.29-rc1/rc2) and see whether the issue still exists? Please see whether it will go to the lowest brightness after keeping on pressing down hotkey. How to use the custom DSDT can be found in http://www.lesswatts.org/projects/acpi/faq.php (As the DSDT.hex is already attached, you can directly start from the step 5) Thanks.
On the Asus laptop there exist three issues when using the latest kernel. a. Asus platform backlight device Vs ACPI generic backlight device On the latest kernel the ACPI generic backlight device will be preferred. But it can't work as expected. After the boot option of "acpi_backlight=vendor" is added, the platform backlight device will be used. In such case it can work well. b. backlight brightness is reverted on the 2.6.28 kernel This is caused by the broken BIOS. On the box the following package is returned by the _BCL object, which is opposite to the brightness order on most laptops.At the same time the backlight index is returned instead of real brightness. >Method (_BCL, 0, NotSerialized) { Return (Package (0x10) { 0x0F, 0x0E, 0x0D, 0x0C,0x0B, 0x0A, 0x09,0x08, 0x07, 0x06, 0x05, 0x04,0x03, 0x02, One, Zero }) } Of course the reverted order is fixed by the following commit: >commit 935e5f290ec1eb0f1c15004421f5fd3154380fd5 >Author: Zhang Rui <rui.zhang@intel.com> >Date: Thu Dec 11 16:24:52 2008 -0500 >ACPI: video: Fix reversed brightness behavior on ThinkPad SL series The above commit is already shipped in the 2.6.29-rc1. c. it will fall back to the lowest level when keeping on pressing up hotkey. I have no idea about this issue. Will you please try the custom DSDT and see whether this issue still exists? Thanks.
Created attachment 19948 [details] Skip the first two elements in the _BCL package Hi, Jonathan How about the custom DSDT? If it is OK, will you please also try the attached patch on the latest kernel (2.6.29-rc1/rc2)and see whether the mentioned issue still exists? Thanks.
Hi Yakui, I applied the custom DSDT on a 2.6.29-rc1 kernel and it works . The brightness level limits are respected when pressing the brightness level up and down keys. I also tried to compile a 2.6.29-rc1 kernel with the attached patch and it also works great ! Great job. Thanks a lot.
Hi, Jonathan Thank for the confirm. As the box can work well after applying the patch in comment #16, the bug will be marked as resolved. And I will try to push it into upstream kernel. Thanks.
patch in comment #16 applied to acpi tree
0a3db1cec5d476804185114ff5d1845aed3936b3 (ACPI: Skip the first two elements in the _BCL package) shipped in linux-2.6.29-rc4 closed.