Created attachment 80861 [details] relevant data (dmesg, lspci etc) [1.] One line summary of the problem: Brightness controls on Compaq 6720s break in 3.4-rc1 commit. [2.] Full description of the problem/report: My Compaq 6720s laptop features a Fn key that allows for some features of the laptop to be controlled. One of these features is the LCD's brightness / backlight, specifically controlled though Fn + F{7,8}. A bisect (log attached) shows that commit ea9f8856bd6d4ed45885b06a338f7362cd6c60e5 first causes this issue, being that the key combination no longer causes the LCD's brightness to vary. Brightness can still be controlled through /proc and DE (Gnome 3.x), however both Fn + F7 and Fn + F8 no longer produce scancodes and are unable to manipulate the LCD's brightness. [3.] Keywords (i.e., modules, networking, kernel): backlight, brightness, 3.4-rc1, acpi, kernel, 6720s [4.] Kernel version (from /proc/version): first occurs in vanilla 3.4-rc1, issue remains in current vanilla 3.6-rc6 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) not applicable [6.] A small shell script or example program which triggers the problem (if possible) not applicable [7.] Environment Arch Linux @ 3.5.4 (rolling release) GNOME 3.4.2
Created attachment 80871 [details] dmesg
Created attachment 80881 [details] lspci
Created attachment 80891 [details] cpuinfo
Created attachment 80901 [details] bisect log
Created attachment 80911 [details] ver_linux.sh output
Created attachment 80921 [details] ioports
Created attachment 80931 [details] iomem
I'm not sure how video module worked for you, as according to your dmesg acpi_video_device_enumerate() is not able to find any video device, because of this error: ACPI Exception: AE_AML_PACKAGE_LIMIT, Evaluating _DOD (20120320/video-1149) I'm not sure if this error could be safely ignored.
Created attachment 80941 [details] Proposed fix Can you check if this patch fixes your issue?
applies cleanly to v3.6-rc7 and does fix the issue. The screen brightness can be controlled again and both key combinations produce scancodes again. This is not the case in a clean v3.6-rc7.
I have different hardware (Dell Latitude E6530), but for me the problem occurs with v3.6-rc7. Didn't have the problem with v3.4.
Created attachment 81051 [details] hardware experiencing brightness keys not working on 3.6-rc7 On boot I also get "Invalid iomem size. You may experience problems." in the syslog. Don't know if this is related.
Martin, if you don't have any issues with brightness keys with v3.4, then it's a different bug. It would be better if you'll file separate ticket for your bug.
I do experience now the problem also on kernel 3.4 - however, it already worked with 3.4. It seems to depend on the moon phase if it works or not... I filed a different bug for my case: https://bugzilla.kernel.org/show_bug.cgi?id=48681
Apparently yesterday it made it to linux-next: https://patchwork.kernel.org/patch/1588511/ Let's hope for the fast turnover!
A patch referencing this bug report has been merged in Linux v3.7-rc4: commit fba4e087361605d1eed63343bb08811f097c83ee Author: Igor Murzov <e-mail@date.by> Date: Sat Oct 13 04:41:25 2012 +0400 ACPI video: Ignore errors after _DOD evaluation.
patch mentioned in comment #16 shipped in Linux 3.7 closed.
This patch actually sets the brightness of my screen to its maximum value when booting or after DPMS unblank. Reverting fba4e08736 on 3.12 fixes the problem. Note that I had other problems with ACPI http://bugzilla.kernel.org/show_bug.cgi?id=15106 (includes my acpidump output).