+++ This bug was initially created as a clone of Bug #911203 +++ --- Additional comment from Jan Pokorny on 2013-04-03 18:40:47 CEST --- After fresh F18 install, I wasn't able to adjust brightness at all. Appending "acpi_backlight=vendor" to kernel command-line (temporarily) fixed the issue for me. --- It would be nice if such basic thing like eyes-saver (from default=top brightness). Packages: kernel-3.8.5-201.fc18.x86_64 (previous kernel-3.8.3-201.fc18.x86_64 ditto)
...worked out of the box
Related: https://bugzilla.kernel.org/show_bug.cgi?id=51231 http://sourceforge.net/mailarchive/message.php?msg_id=30755994
kernel-3.8.11-200.fc18.x86_64 ditto Confirming these messages being logged upon changing the brightness via keys once booted with acpi_backlight=vendor: > thinkpad_acpi: unknown possible thermal alarm or keyboard event received > thinkpad_acpi: unhandled HKEY event 0x6050 > thinkpad_acpi: please report the conditions when this event happened to > ibm-acpi-devel.net
Does this still happen with 3.11.4 or newer?
Josh, still on F18, kernel updated to kernel-3.11.4-101.fc18.x86_64, I can see no difference, i.e., "acpi_backlight=vendor" is a required part of the kernel cmdline so as to achieve working backlight controls. Also when omitted, I can see no messages as in [comment 3]. Will give 3.11.6-100.fc18 a try.
...with no change.
I updated to F19 this week. The backlight keys appear to work with kernel 3.11.7-200.fc19.x86_64.
Still does not work for me without extra config with neither kernel-3.11.7-100.fc18.x86_64 nor kernel-3.11.8-100.fc18.x86_64
The same here with Laptop Fujitsu Lifebook E8420 lspci 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) Fedora 20 beta, kernel 3.11.9
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still present in Fedora 20 released version.
Provided that F18 is passing EOL, just for reference: no change with kernel-3.11.10-100.fc18.x86_64 either (going to upgrade soon, will report new observations then)
Updated to F19 and unfortunately observing still the same with kernel-3.12.5-200.fc19.x86_64. Haven't tried 3.11.7-200.fc19.x86_64 as per [comment 7] so cannot judge if there was a regression or there is a misunderstanding about this bug, but definitely a reason to bump the release version.
There are a bunch of acpi changes that might affect Lenovos and certain ACPI events (backlight, etc) (i.e. https://lkml.org/lkml/2013/10/15/776) Might be worth giving 3.13rc6 kernel a shot: http://koji.fedoraproject.org/koji/buildinfo?buildID=487242
Updated to F20 and still no change with these: kernel-3.12.6-200.fc19.x86_64 kernel-3.12.5-302.fc20.x86_64 Re [comment 14]: Tried kernel-3.13.0-0.rc6.git0.1.fc21.x86_64, too (kernel + kernel-devel + kernel-modules-extra), and the situation is not better but worse: not even "acpi_backlight=vendor" trick helped (another combination may be required now).
Jan, What desktop environment are you using when you run into this? There's a plethora of "brightness settings don't work" bugs and I'm looking to mark some duplicates. Thanks!!
I use Fedora 20 with Gnome 3.10. Even with the newest kernel-update (3.13) remains the problem.
Mike, desktop environment (as in Gnome, etc.) really does not matter, as it can be reproduced early in the plymouth already (in my case, when entering LUKS password). On the HW side, it is lenovo T530 with integrated Intel graphics - Xorg: Integrated Graphics Chipset: Intel(R) HD Graphics 4000, - lspci: 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) As an extension to [comment 15], indeed it seems I can't even force proper backlight control with "acpi_backlight=vendor" (is there another magic formula?) on 3.13 kernels. This is what I've just (re)tested: kernel-3.12.5-302.fc20.x86_64, "acpi_backlight=vendor" required kernel-3.13.4-200.fc20.x86_64, not even ^ helps kernel-3.13.6-200.fc20.x86_64, ditto Because of this, I am forced to stay with 3.12 one :-/
OK, I wasn't sure. I've had experiences where brightness settings work for one DE and not another.
> Because of this, I am forced to stay with 3.12 one :-/ I gave some attempts to acp_osi (Linux, !Windows2012, ...), with or without "acpi_backlight=vendor", kernel-3.13.6-200.fc20.x86_64. No success -> for me, the regression so far is even more significant with 3.13 kernels
(In reply to Jan Pokorný from comment #18) > Mike, desktop environment (as in Gnome, etc.) really does not matter, > as it can be reproduced early in the plymouth already (in my case, > when entering LUKS password). This is to be expected. How these things work in most cases is the brightness keys generate key events and there needs to be some software listening which actually acts on those and makes the changes. In some rare cases the firmware handles this itself and brightness control will already work at the plymouth screen. But normally you cannot expect it to work until you're fully logged in. Basically there are 2 possible reasons why backlight control does not work: 1) The keys don't generate brightness events 2) The brightness control code is not working If you log into gnome 3, and press the brightness keys and do not get an overlay showing the brightness status (similar to what you get when doing volume up /down) then 1) is a problem. If you change the brightness through the slider in the upper right corner control menu and that does no work, or there is no slider, then 2 is a problem. Note you may have both problems at once.
Jan, Can you please try with a 3.13 kernel in combination with "use_native_backlight=1" on the kernel cmdline, and without any other special kernel parameters ? I've been researching backlight issues for the last few days and I think that that should do the trick for the T530. Once you can confirm that that does the trick we can add a DMI based quirk for the T530 making this the default. Thanks, Hans
Oops, correction, please try with: "video.use_native_backlight=1" on the kernel cmdline rather then just "use_native_backlight=1".
Hans, I've tried your suggestion, but it had no effect on ability to use fn+F{8,9}. However I finally found out that controlling backlight as such via sysfs works even with no special parameter specified (hence point 2. from [comment 21] should be OK): # cat /sys/class/backlight/intel_backlight/max_brightness \ > /sys/class/backlight/intel_backlight/brightness There may have been a confusion about ability to control the backlight level as such and achieving it using native dedicated key combination. This bug report is about the latter (sorry about "adjust brightness at all" that might raise a confusion), specifically about the regression, likely in kernel side, whereas formerly (pre-3.13) specifying "acpi_backlight=vendor" fixed the issue; since 3.13 cannot find any combination that would achieve the same. I want to avoid any middle-man (I do not use Gnome, LXDE here) when I know it used to work on a low-level basis before, even in pure terminal mode.
Possible duplicates - Brightness related: Brightness adjustment FN keys doesn't work https://bugzilla.redhat.com/show_bug.cgi?id=702352 Acer Aspire V5-171-9620 display brightness doesn't change using keyboard Fn keys (but onscreen slider moves) https://bugzilla.redhat.com/show_bug.cgi?id=983342 Dell brightness keys register multiple times https://bugzilla.redhat.com/show_bug.cgi?id=986653 unable to adjust monitor brightness with nouveua, Toshiba, and 3.11.0 kernel https://bugzilla.redhat.com/show_bug.cgi?id=999684 Cannot adjust brightness anymore using Fn keys with F19 x86_64 https://bugzilla.redhat.com/show_bug.cgi?id=1012674 Brightness does not change on Intel graphics (using keys or slider) since about 3.9 kernels https://bugzilla.redhat.com/show_bug.cgi?id=1025690 Brightness keys stopped working between kernel 3.12.10-300 and 3.13.3-201 on Asus EEE PC https://bugzilla.redhat.com/show_bug.cgi?id=1067181 T530: Unsupported brightness interface https://bugzilla.redhat.com/show_bug.cgi?id=1089545 Can't change display brightness on HP EliteBook 8470p https://bugzilla.redhat.com/show_bug.cgi?id=1093120
Hi, (In reply to Jan Pokorný from comment #24) > Hans, I've tried your suggestion, but it had no effect on ability to use > fn+F{8,9}. > > However I finally found out that controlling backlight as such via sysfs > works even with no special parameter specified > (hence point 2. from [comment 21] should be OK): > > # cat /sys/class/backlight/intel_backlight/max_brightness \ > > /sys/class/backlight/intel_backlight/brightness > > There may have been a confusion about ability to control the backlight > level as such and achieving it using native dedicated key combination. > > This bug report is about the latter (sorry about "adjust brightness > at all" that might raise a confusion), specifically about the regression, > likely in kernel side, whereas formerly (pre-3.13) specifying > "acpi_backlight=vendor" fixed the issue; since 3.13 cannot find any > combination that would achieve the same. > > I want to avoid any middle-man (I do not use Gnome, LXDE here) when > I know it used to work on a low-level basis before, even in pure > terminal mode. Jan, I'm afraid that avoiding a middle-man simply is not realistic in these days. I know this has worked in the past on some laptop models, but on more and more models the brightness keys are becomgin just keys sending normal keypress events over ps/2. So you usually need something to pick up the events and frob the backlight interface in /sys for things to work. When you tried with video.use_native_backlight=1 on the kernel cmdline did you try with a middle-man ? If not can you humor me and log into gnome3 with that kernel cmdline option and give things a try? I really expect video.use_native_backlight=1 to work on the T530 when combined with a middle man, and I would like to get this resolved since there are more unhappy T530 owners out there. Also can you please run this command: grep '.*' /sys/class/dmi/id/*_* 2> /dev/null And paste the output here? Thanks, Hans
*** This bug has been marked as a duplicate of bug 1089545 ***