Bug 85051

Summary: Asus X53SM: Brightness control does not work anymore [regression]
Product: ACPI Reporter: Ralf (post+kernel)
Component: Power-VideoAssignee: Aaron Lu (aaron.lu)
Status: CLOSED CODE_FIX    
Severity: normal CC: aaron.lu, alan, martin
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.16.3 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: Output of acpidump
Add debug statements to see why video backlight interface gets created
dmesg with patch applied
Run _BCL before deciding if we should register backlight interface
Run _BCL before deciding if we should register backlight interface
dmidecode output

Description Ralf 2014-09-23 14:32:53 UTC
With Linux 3.16.3, controlling the brightness of my laptop screen does not work anymore. It's working fine with the 3.15.10 kernel (both vanilla).

Previous behavior (3.15):
* When I drag the brightness slider in KDE, the OSD appears and the
  brightness changes.
* After some minutes of inactivity with no AC (as configured in the
  KDE power-saving options), the screen is dimmed.
* When I press the brightness keys on the keyboard, the brightness
  changes *but* KDE does not notice, no OSD appears, and the brightness
  slider in the battery applet does not move.

Current behavior (3.16):
* Dragging the brightness slider does nothing except for showing the OSD.
* No dimming on inactivity happens.
* Pressing the brightness ekys on the keyboard results in the KDE brightness
  OSD appearing, without the brightness changing.

So the power system (KDE, presumably through upower?) now notices that
I press the power keys. However, the keys don't work anymore. Overall, this
is clearly a regression as I can now no longer control the brightness.

I bootet the current system with the old kernel to verify that the kernel
is the only part that changed.

I can do a bisect, but I'd appreciate a pointer which directory to restrict the bisect to.

I reported this bug against Debian as well at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762285>. That report contains a whole lot of information about by hardware. Please let me know if you need further information.
Comment 1 Aaron Lu 2014-09-29 08:13:47 UTC
Please do:
$ ls /sys/class/backlight
on both kernels.

Also, please test if manually change the brightness file works(as root):
# cd /sys/class/backlight/XXX
# cat max_brightness
xxx
# echo 500 > brightness
# echo 600 > brightness
...

Please attach acpidump:
# acpidump > acpidump.txt
Comment 2 Ralf 2014-09-29 09:55:13 UTC
With an old kernel (3.14 Debian kernel):

$ ls /sys/class/backlight
acpi_video0  acpi_video1  intel_backlight

$ cd /sys/class/backlight/acpi_video0
$ cat max_brightness
100
# changing the brightness file here does nothing

$ cd /sys/class/backlight/acpi_video1
$ cat max_brightness
100
# changing the brightness file here works

$ cd /sys/class/backlight/intel_backlight
$ cat max_brightness
4882
# changing the brightness file here works


With a new kernel (3.16 Debian kernel):

$ ls /sys/class/backlight
acpi_video0  intel_backlight

$ cd /sys/class/backlight/acpi_video0
$ cat max_brightness
100
# changing the brightness file here does nothing

$ cd /sys/class/backlight/intel_backlight
$ cat max_brightness
4882
# changing the brightness file here works
Comment 3 Ralf 2014-09-29 09:55:36 UTC
Created attachment 152071 [details]
Output of acpidump
Comment 4 Aaron Lu 2014-10-13 08:10:28 UTC
With v3.16, if the firmware has a query of _OSI("Windows 2012") as is your laptop, we will not create ACPI video backlight interface to let the GPU one to take over. I don't know why acpi_video0 still gets created with v3.16, did you use any kernel cmdline option?
Comment 5 Ralf 2014-10-13 08:19:24 UTC
(In reply to Aaron Lu from comment #4)
> With v3.16, if the firmware has a query of _OSI("Windows 2012") as is your
> laptop, we will not create ACPI video backlight interface to let the GPU one
> to take over. I don't know why acpi_video0 still gets created with v3.16,
> did you use any kernel cmdline option?

No:
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.17.0-rc7 root=/dev/mapper/cryptvg-rootlv ro quiet

As you can see, this is with 3.17-rc7. The issue persists with that kernel, and the cmdline is the same (modulo the BOOT_IMAGE, obviously) for all kernels.
Comment 6 Aaron Lu 2014-10-14 01:25:07 UTC
Created attachment 153661 [details]
Add debug statements to see why video backlight interface gets created

Please apply this debug patch and attach dmesg, thanks.
Comment 7 Ralf 2014-10-14 09:37:15 UTC
Created attachment 153711 [details]
dmesg with patch applied

I'm not sure if I mentioned it before, but the fact that it's talking about two "GFX" in the dmesg reminded me that I actually have two GPUs in this laptop: An Intel HD card built into the Core i5-2450M, and an NVidia 630M. The latter doesn't have any screen attached, I have bumblebee and bbswitch installed to turn the card on only when needed.
Sorry that I didn't mention this earlier (and I'm not sure if that shows up in the dumps I provided), it didn't even occur to me that a GPU without attached screen could even be relevant for backlight, so I forgot about this.

I will do a re-boot with bbswitch blacklisted to check if that has any effect.
Comment 8 Ralf 2014-10-14 09:44:31 UTC
I uninstalled the bbswitch module, with no effect in the backlight stuff. I'm installing it again now so that the NVidia card doesn't drain my battery.
Comment 9 Aaron Lu 2014-10-17 08:33:38 UTC
The problem is that when ACPI video runs, the _OSI("Windows 2012") is not queried yet. It is queried in one of the video ASL calls but that's too late so we created the first non-working ACPI video interface. I'll need to think about how to deal with this problem, at the moment, you can work around the problem by using video.use_native_backlight=1.
Comment 10 Ralf 2014-10-17 09:04:02 UTC
(In reply to Aaron Lu from comment #9)
> you can work around the
> problem by using video.use_native_backlight=1.

Unfortunately, this does not work.

$ ls /sys/class/backlight/
acpi_video0  intel_backlight
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.16-2-amd64 root=/dev/mapper/cryptvg-rootlv ro video.use_native_backlight=1 quiet

The backlight keys still don't work, behaviour is (as far as I can tell) exactly the same as without this option.
Comment 11 Aaron Lu 2014-10-17 09:08:22 UTC
(In reply to Ralf Jung from comment #10)
> (In reply to Aaron Lu from comment #9)
> > you can work around the
> > problem by using video.use_native_backlight=1.
> 
> Unfortunately, this does not work.

Oh right, I forgot that the use_native_backlight cmdline only affects systems that has _OSI("Windows 2012")...
Comment 12 Aaron Lu 2014-10-24 02:23:13 UTC
Created attachment 154711 [details]
Run _BCL before deciding if we should register backlight interface

Please test this patch, on top of v3.18-rc1. Thanks.
Comment 13 Aaron Lu 2014-10-24 02:31:04 UTC
Created attachment 154721 [details]
Run _BCL before deciding if we should register backlight interface

Slightly changed.
Comment 14 Ralf 2014-10-25 11:53:45 UTC
Yes, that patch does the trick :) . I applied it to v3.17 (the patch didn't apply cleanly, but it found the hunks at some offset), and after a reboot I get

$ ls /sys/class/backlight/
intel_backlight

and both the buttons on the keyboard and the KDE brightness slider are working again. Awesome :D

Is this patch kind of a hack, or should I point the Debian kernel maintainers to it?
Comment 15 Aaron Lu 2014-10-27 01:53:50 UTC
It's not a hack, I'll submit that patch upstream.
Comment 16 Aaron Lu 2014-10-27 02:29:25 UTC
Please attach your dmidecode:
# dmidecode > dmi.txt

I want to know your laptop's model.
Comment 17 Ralf 2014-10-27 08:57:47 UTC
Created attachment 155311 [details]
dmidecode output

Here you go. I ran the command with the 3.16 Debian kernel, without your patch - I hope that's okay.
Comment 18 Aaron Lu 2014-10-28 06:39:14 UTC
Patch sent out:

http://marc.info/?l=linux-acpi&m=141447817127355&w=2
Comment 19 Aaron Lu 2015-01-06 07:34:19 UTC
commit dce4ec2e452fddb7542b5fc15d0e6b8531f6d5eb
Author: Aaron Lu <aaron.lu@intel.com>
Date:   Tue Oct 28 14:35:59 2014 +0800

    ACPI / video: Run _BCL before deciding registering backlight