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.
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