Bug 47861 - Brightness controls on Compaq 6720s break in 3.4-rc1 commit
Summary: Brightness controls on Compaq 6720s break in 3.4-rc1 commit
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Video (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Zhang Rui
Depends on:
Reported: 2012-09-23 15:45 UTC by Stefan Wilkens
Modified: 2013-11-15 12:22 UTC (History)
9 users (show)

See Also:
Kernel Version: 3.4-rc1 - 3.6-rc6
Regression: Yes
Bisected commit-id:

relevant data (dmesg, lspci etc) (19.62 KB, application/x-gzip)
2012-09-23 15:45 UTC, Stefan Wilkens
dmesg (45.27 KB, application/octet-stream)
2012-09-23 15:46 UTC, Stefan Wilkens
lspci (10.45 KB, application/octet-stream)
2012-09-23 15:47 UTC, Stefan Wilkens
cpuinfo (686 bytes, application/octet-stream)
2012-09-23 15:47 UTC, Stefan Wilkens
bisect log (3.12 KB, application/octet-stream)
2012-09-23 15:48 UTC, Stefan Wilkens
ver_linux.sh output (1.37 KB, application/octet-stream)
2012-09-23 15:48 UTC, Stefan Wilkens
ioports (1.64 KB, application/octet-stream)
2012-09-23 15:48 UTC, Stefan Wilkens
iomem (2.11 KB, application/octet-stream)
2012-09-23 15:49 UTC, Stefan Wilkens
Proposed fix (1005 bytes, patch)
2012-09-23 23:41 UTC, Igor Murzov
Details | Diff
hardware experiencing brightness keys not working on 3.6-rc7 (15.15 KB, text/plain)
2012-09-25 20:28 UTC, Martin Wildam

Description Stefan Wilkens 2012-09-23 15:45:20 UTC
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
Comment 1 Stefan Wilkens 2012-09-23 15:46:55 UTC
Created attachment 80871 [details]
Comment 2 Stefan Wilkens 2012-09-23 15:47:22 UTC
Created attachment 80881 [details]
Comment 3 Stefan Wilkens 2012-09-23 15:47:41 UTC
Created attachment 80891 [details]
Comment 4 Stefan Wilkens 2012-09-23 15:48:08 UTC
Created attachment 80901 [details]
bisect log
Comment 5 Stefan Wilkens 2012-09-23 15:48:31 UTC
Created attachment 80911 [details]
ver_linux.sh output
Comment 6 Stefan Wilkens 2012-09-23 15:48:59 UTC
Created attachment 80921 [details]
Comment 7 Stefan Wilkens 2012-09-23 15:49:28 UTC
Created attachment 80931 [details]
Comment 8 Igor Murzov 2012-09-23 23:38:36 UTC
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.
Comment 9 Igor Murzov 2012-09-23 23:41:27 UTC
Created attachment 80941 [details]
Proposed fix

Can you check if this patch fixes your issue?
Comment 10 Stefan Wilkens 2012-09-24 14:31:00 UTC
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.
Comment 11 Martin Wildam 2012-09-25 20:23:06 UTC
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.
Comment 12 Martin Wildam 2012-09-25 20:28:14 UTC
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.
Comment 13 Igor Murzov 2012-10-10 00:47:26 UTC
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.
Comment 14 Martin Wildam 2012-10-10 19:06:22 UTC
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
Comment 15 Simonas Leleiva 2012-10-24 20:21:44 UTC
Apparently yesterday it made it to linux-next: https://patchwork.kernel.org/patch/1588511/

Let's hope for the fast turnover!
Comment 16 Florian Mickler 2012-11-05 23:10:30 UTC
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.
Comment 17 Len Brown 2013-02-08 17:43:36 UTC
patch mentioned in comment #16 shipped in Linux 3.7

Comment 18 Ali Gholami Rudi 2013-11-15 12:22:57 UTC
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).

Note You need to log in before you can comment on or make changes to this bug.