Bug 12450

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.