Bug 815625

Thanks. Please attach supportconfig tarball.

Created attachment 535655 [details]
supportconfig tarball

Ok, I found something.  I remembered that Thinkpad brightness keys are implemented in hardware, so have tried working forward and back through the mainline kernel.  The 3.8 series has this bug, so it's not fixed upstream.  So far, linux-3.6.11 (mainline) is the last kernel version where these brightness keys worked.  3.7.10 (mainline) doesn't work, but I haven't worked my way through the 3.7 series to find out where the regression occurred.

Sorry for the mix-up, now it looks like more of a kernel bug.  Will supportconfig still be useful in debugging this?

Brightness keys work in linux-3.6.0, but not in 3.7.0.  It seems like the regression happened somewhere in patch-3.7.

The brightness keys on of my Thinkpad x230i are working perfectly fine with KDE, though in GNOME after pressing Fn+F8 or Fn+F9 the OSD shows up but the brightness doesn´t change. If i change the display brightness manually in "System Settings"->"Brightness and Lock", the keys for controlling display brightness are working almost normal, yet the values displayed in the OSD are moving in a range of ~10% to 70%; this behaviour remains until the machine is rebooted.

With regard to this problem there are already bugreports with discussions on Ubuntus Launchpad and on the Kernel Bug Tracker i have knowledge of.

LP: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1098216
KBT: https://bugzilla.kernel.org/show_bug.cgi?id=51231

Unfortunately so far no real solution for the problem exists.

Oliver, this bug is about Lenovo's Chromebook, not x230i. Things to verify are mentioned on

  https://wiki.archlinux.org/index.php/Backlight

For intel GPUs you can also try using 'xbacklight'.

Stefan, 
increasing and accordingly decreasing the backlight brightness with xbacklight works so far. But if i set the to 0 or 100 with "xbacklight -set 10" or "xbacklight -set 100", things get buggy.

If i set the the brightness to 10, i can´t increase the brightness further than 10, but can only decrease it to 5 using the function keys.

If i set the brightness to 100, using the function keys to control the display brightness doesn´t change the brightness.

If is set the display brightness to 40, by usong the function keys i can decrease the brightness to 20 and increase it up to 70.


A small explanation why i decided to attach my problem to this bugreport:
In comment 4 and 5 Nicholas mentioned, that he tracked the regression of backlight control to be introduced with kernel 3.7, which accords with the bugreports i linked to. Additionally it seems like a lot of Lenovos latest Thinkpads has broken backlight support since kernel 3.7, though the x131e Chromebook isn´t mentioned in the reports yet.

So i´ll leave it up to you whether i shall open a new bugreport for the x230.

Stefan,

Brightness can be changed with /sys/class/backlight/acpi_video0
and /sys/class/backlight/intel_backlight

xset dpms works
xbacklight works

In the bugzilla.kernel.org Oliver links to, Peter Weber maintains that it affects "all current thinkpads From 2012."  This bug report matches the behaviour I've observed.  The commit that broke things:
https://bugzilla.kernel.org/show_bug.cgi?id=51231#c12
and what the ACPI tables show in response to Windows8/2012 OSI:
https://bugzilla.kernel.org/show_bug.cgi?id=51231#c19

Oliver,

It sounds like your Thinkpad model behaves differently than mine, but just to make sure, could you please hold down your brightness-up or brightness-down keys for more than five seconds?  Mine will change the brightness in a jerky and uncontrollable way, but the brightness will lurch in the right direction.

Nicholas,

if i keep the keys brightness-up or brightness-down pressed for several seconds (> 10 seconds), the brightness of the display does not change.

Update:  I'm not sure why I didn't think of this before, but outside of X11 it takes five Fn+F8 keypresses to register one brightness level change.  This is consistent with the Windows8/2012 OSI change in the kernel bug.  Five keypresses per hardware brightness level seems to infer that my Thinkpad actually only supports 20 levels.  

Stephan, to clarify, X11 and/or KDE need to work around the change in kernel behaviour for handling brightness that was introduced in linux-3.7.

Oliver,  Could you please check to see if you can brightness level outside of X11, and if so check count how many keypresses it takes to change one hardware brightness level?

Nicholas,

the control keys have no effect on the brightness outside of X as well.

Oliver,

While there might be some overlap between our Thinkpad's issues, yours has something more serious going on.  I'd definitely file a separate bug for your Thinkpad's hardware issue.  It's possible that the x230i is supported with a newer kernel, so I'd try installing and booting the Tumbleweed kernel (linux-3.9.5)  Be careful if you add the repository, so you don't accidentally upgrade everything to Tumbleweed.

In you new bug report, make sure you mention whether or not your brightness keys work with the Tumbleweed kernel.

As a test for a possible upstream fix, I thought I'd try booting the Fedora 19 KDE live cd.  This bug is fixed in that release.  Maybe it can be back-ported?

(In reply to comment #14)
> As a test for a possible upstream fix, I thought I'd try booting the Fedora 19
> KDE live cd.  This bug is fixed in that release.  Maybe it can be back-ported?

If we would know what the fix is, yes. Most likely the fix has happened upstream, and Fedora  guys don't know either what the fix has been ...

Here, a ThinkPad T430s running openSUSE 13.1 is still affected by this kernel bug: acpi_osi="!Windows 2012" helps to make Fn-F89 work again. But then KDE ignores the brightness change and, thus, there is no OSD and the brightness slider of the power manager applet is not updated.

Works for me now using 13.2 on a T430s.
@Nicholas: Do the brightness keys work on your X131e using 13.2, too?

Product is no longer supported. In case the issue is still reproducable on a maintainerd product (at that momement: openSUSE 13.1 or later), feel free to reopen.