Bug 12450

Summary: brightness keys cause jump between min and max - ASUS MV51R
Product: ACPI Reporter: Jonathan Dray (jonathan.dray)
Component: Power-VideoAssignee: ykzhao (yakui.zhao)
Status: CLOSED PATCH_ALREADY_AVAILABLE    
Severity: normal CC: acpi-bugzilla
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.29-rc1 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: Debug output information on 2.6.27.10 kernel
Debug output information on 2.6.28 kernel
Debug output information on 2.6.29-rc1 kernel
/proc/acpi/event output with acpi_osi="!Windows 2006" boot option activated
try the custom DSDT
Skip the first two elements in the _BCL package

Description Jonathan Dray 2009-01-14 16:19:29 UTC
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.
Comment 1 ykzhao 2009-01-14 16:54:46 UTC
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.
Comment 2 Zhang Rui 2009-01-14 17:24:06 UTC
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.
Comment 3 Jonathan Dray 2009-01-17 03:03:17 UTC
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
Comment 4 Jonathan Dray 2009-01-17 03:04:22 UTC
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
Comment 5 Jonathan Dray 2009-01-17 03:13:16 UTC
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
Comment 6 Jonathan Dray 2009-01-17 04:35:38 UTC
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
Comment 7 ykzhao 2009-01-18 18:58:41 UTC
Hi, Jonahan
    How about this issue if you add the boot option of "acpi_backlight=vendor" on the 2.6.28 kernel?
    Thanks.
Comment 8 ykzhao 2009-01-18 23:36:43 UTC
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.
Comment 9 Jonathan Dray 2009-01-19 14:39:47 UTC
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
Comment 10 ykzhao 2009-01-19 16:47:52 UTC
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.


    
Comment 11 ykzhao 2009-01-20 01:12:15 UTC
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.
Comment 12 Jonathan Dray 2009-01-20 16:26:47 UTC
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.
Comment 13 Jonathan Dray 2009-01-20 16:29:56 UTC
Created attachment 19914 [details]
/proc/acpi/event output with acpi_osi="!Windows 2006" boot option activated
Comment 14 ykzhao 2009-01-22 19:35:36 UTC
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.
Comment 15 ykzhao 2009-01-22 21:17:37 UTC
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.
      
     
Comment 16 ykzhao 2009-01-22 22:13:21 UTC
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.
Comment 17 Jonathan Dray 2009-01-24 01:27:16 UTC
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.
Comment 18 ykzhao 2009-02-01 19:23:41 UTC
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.
Comment 19 Len Brown 2009-02-02 19:38:27 UTC
patch in comment #16 applied to acpi tree
Comment 20 Len Brown 2009-02-21 09:27:31 UTC
0a3db1cec5d476804185114ff5d1845aed3936b3
(ACPI: Skip the first two elements in the _BCL package)
shipped in linux-2.6.29-rc4
closed.