Bug 85051
| Summary: | Asus X53SM: Brightness control does not work anymore [regression] | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Ralf (post+kernel) |
| Component: | Power-Video | Assignee: | 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
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 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 Created attachment 152071 [details]
Output of acpidump
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?
(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. Created attachment 153661 [details]
Add debug statements to see why video backlight interface gets created
Please apply this debug patch and attach dmesg, thanks.
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.
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. 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.
(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. (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")... 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.
Created attachment 154721 [details]
Run _BCL before deciding if we should register backlight interface
Slightly changed.
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? It's not a hack, I'll submit that patch upstream. Please attach your dmidecode: # dmidecode > dmi.txt I want to know your laptop's model. 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.
Patch sent out: http://marc.info/?l=linux-acpi&m=141447817127355&w=2 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 |