Description of problem: Keyboard function keys (Fn-Left and Fn-Right) make a slider appear on screen which moves up and down as one might expect, but the brightness of the display does not change. The value in the file /sys/class/backlight/acpi_video0/brightness changes from 0 to 10 [but only in increments of 2] in accordance with the position of the onscreen slider. The value in the file /sys/class/backlight/intel_backlight/brightness does not change when the keyboard function keys are pressed, nor does the timestamp on that file change. However, editing the value in /sys/class/backlight/intel_backlight/brightness by hand, immediately results in a coherent change in display brightness. (For example setting it to 700 results in a moderately bright display, 300 a moderately dim display, and 0 seems to turn the backlight off etc..) This is happening on a fresh install from DVD of Fedora 19 Desktop (Fedora Default download) on a new Acer Aspire V5-171-9620 with an Intel HD Graphics 4000 display adapter. Version-Release number of selected component (if applicable): kernel 3.9.9-301.fc19.x86_64 How reproducible: Steps to Reproduce: 1. Press either of the keyboard brightness keys (Fn-Left or Fn-Right). 2. 3. Actual results: Brightness indicator appears on screen and slider moves (down or up) in increments of about 1/5th of its length; the value in /sys/class/backlight/acpi_video0/brightness decreases (or increases) by 2, between 0 and 10). No change in display brightness. Expected results: Most importantly, display brightness changes (less bright or brighter). Also brightness indicator appears on screen and slider moves (down or up) in increments of 1/10th of its length (or finer) -- 1/5th is far too coarse. Additional info: On startup, the display brightness is reset to a very bright (the maximum?) level and the value in the file /sys/class/backlight/intel_backlight/brightness is set to 976. (This is equal to the value in /sys/class/backlight/intel_backlight/max_brightness.) The power management software is able to dim the display after the system has been idle for a set period of time, and this functionality seems to work just fine. (The display dims on schedule, and brightens again to its former level with keyboard or mouse activity.) I can happily provide additional information upon request. Similar bugs: This bug is very similar to Bug 903136 (https://bugzilla.redhat.com/show_bug.cgi?id=903136) except that the onscreen slider was not moving for the poster of that bug. Also that poster found that modifying /sys/class/backlight/acpi_video0/brightness would change the brightness, but that has no effect on the brightness on my system, it just effects the position of the onscreen slider. So if this is the same bug, it is not obviously so.
Same behaviour here on a new Acer TravelMate P653-M. The only workaround is echoing the value in /sys/class/backlight/intel_backlight/brightness as already mentioned.
After adding the kernel parameter acpi_backlight=vendor, it's possible to control the brightness with the Gnome screen applet too (settings>power management). Hence, the problem seems to be related to an incorrect keycode.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
Maybe the problem is solved? Let me sum up. My Acer Travelmate notebook is similar to the one owned by N. Jackson. It also has an Intel HD4000 integrated card and the maximum brightness value is 976. After adding the kernel parameters acpi_osi=Linux and acpi_backlight=vendor, I was able to control the brightness via the Gnome screen applet or echoing the value in /sys/class/backlight/intel_backlight/brightness (the last method works without the acpi_backlight=vendor parameter too). Then I blacklisted the acer_wmi kernel module and now I'm able to change the brightness via the keyboard brightness keys too (Fn-Left and Fn-Right). The control works perfectly: is very "granular" and the "slider" (a sort of "sun") appears on screen, allowing the bar to move left and right as one might expect. Now I'm running kernel 3.11.1-200.fc19.x86_64.
Laptop Fujitsu Lifebook E8420 doesn't work too. The FN-Keys don't change the backlight. The symbol occurs on the screen, but the backlight doesn't change the brightness. In gnome-shell the slider in the upper right menu works fine. 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
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.12.6-200.fc19. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20. If you experience different issues, please open a new bug report for those.
(In reply to Justin M. Forbes from comment #6) > Fedora 19 has now been rebased to 3.12.6-200.fc19. Please test this > kernel update (or newer) and let us know if you issue has been > resolved or if it is still present with the newer kernel. No. This latest kernel (3.12.6-200.fc19.x86_64) does not resolve the issue. I have been using the workaround of appending acpi_osi=Linux to my kernel boot options. With this workaround the keyboard brightness keys work but the onscreen slider is not displayed and after a restart the display is always reset to full brightness. With kernel 3.12.6-200 the workaround continues to work (to the same limited extent that it worked previously), but the original bug remains: that is if I don't boot with the acpi_osi=Linux option, the behaviour is the same as it was in the original bug report.
I've installed Fedora 20 and the behaviour is the same as described above. Works with the workaround.
From a naive, superficial viewpoint this bug seems extremely simple: Changing the value in /sys/class/backlight/intel_backlight/brightness changes the display brightness. Changing the values in /sys/class/backlight/acpi_video0/brightness does not change the display brightness. But using the keyboard brightness keys changes the values in the later file rather than the former. Consequently the keyboard brightness keys do not change the display brightness.
I can add that for an Asus UL50VT running on intel graphics, with F20, echoing into /sys/class/backlight/intel_backlight/brightness does change brightness. [root@host intel_backlight]# cat max_brightness 2583660 [root@host intel_backlight]# echo "1000000" > brightness kernel.x86_64 3.12.6-300.fc20
Giving the kernel parameter "acpi_backlight=vendor" at boot solved the problem. This is system (Asus UL50VT) has hybrid graphics and uses bumblebee with Intel / Nvidia. I don't know that contributes to the confusion.
<metoo> on an HP Spectre Envy laptop. acpi_backlight=vendor makes things work right. Interestingly, I did *not* have this problem until the F20 upgrade; now it happens even with the F19 3.11 kernel. So something else has changed in there somewhere...
Same issue occurs on HP EliteBook 8470p running F20 with the 3.12.9 kernel. Adding acpi_backlight=vendor to the kernel parameters fixes the issue though. uname -r 3.12.9-301.fc20.x86_64 lspci VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.13.5-100.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
Just tried; this bug is still present with kernel-3.13.6-200.fc20.x86_64 on F20.
I'm running Fedora 20 (kernel-3.13.6) and the behaviour is the same as described above. Works with the workaround.
(In reply to Justin M. Forbes from comment #14) > Fedora 19 has now been rebased to 3.13.5-100.fc19. Please test this kernel > update and let us know if you issue has been resolved or if it is still > present with the newer kernel. I am now running with 3.13.7-100.fc19.x86_64 and the bug is still present. There is no change to the behaviour I described in my initial bug report last July. I'm still using the workaround I reported in Comment #7 (acpi_osi=Linux) and it continues to work in the limited sense that it was working then. N.
Note that I have tried using the acpi_backlight=vendor workaround and it does not work for me: Used in combination with acpi_osi=Linux the behaviour is no different from using acpi_osi=Linux alone (the screen brightness changes in response to Fn-Left and Fn-Right, but the system always starts up at full brightness, and the onscreen slider does not appear). Used alone, acpi_backlight=vendor stops the onscreen slider from appearing but has no effect on the display brightness. N.
I think this is really an X issue. The keyboard commands and OSD are controlled by X, and you want X to use the intel_backlight. On a little asus netbook that I have but don't much use, I had this with 3.13.7 also, but it worked fairly nicely if I added a file to /etc/X11/xorg.conf.d containing Section "Device" Identifier "Intel Graphics" Driver "intel" Option "Backlight" "intel_backlight" EndSection There was no need for any extra options to kernel command line in grub. Does that work for you?
Hi All, I've been researching backlight issues for the last few days and I think I'm starting to get a handle on them, or at least to some degree. For the original reporter of this bug with the Acer Aspire V5-171-9620, I expect that using the latest fedora kernel and then adding "use_native_backlight=1" on the kernel cmdline, and removing any other special kernel parameters should make things work properly. Also please run: grep '.*' /sys/class/dmi/id/*_* 2> /dev/null And copy and paste the output here, then I can add a quirk to the kernel to do this automatically for your laptop. For the others / for all the me-too-s here. Unless you've the exact same model laptop as the reporter, please file a new bug against the kernel with me in the CC. I'm going to be enforcing a strict one laptop model per bug policy for these brightness bugs otherwise things will become very hard to track. When you file a new bug please start with trying the "use_native_backlight=1" kernel cmdline option mentioned above (with all other backlight options / customization removed), and add a note to the bug if hat helps. Also please run: grep '.*' /sys/class/dmi/id/*_* 2> /dev/null And add the output of that to the bug report. Thanks, Hans
Oops, correction, please try with: "video.use_native_backlight=1" on the kernel cmdline rather then just "use_native_backlight=1".
ACPI / video: Add systems that should favour native backlight interface https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/acpi/blacklist.c?id=0e9f81d
Possible duplicates - Brightness related: Brightness adjustment FN keys doesn't work https://bugzilla.redhat.com/show_bug.cgi?id=702352 Brightness/backlight keys (fn+F8, fn+F9) does not work on lenovo T530 out of the box https://bugzilla.redhat.com/show_bug.cgi?id=947976 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
(In reply to Hans de Goede from comment #20) > > For the original reporter of this bug with the Acer Aspire V5-171-9620, I > expect that using the latest fedora kernel and then adding > "use_native_backlight=1" on the kernel cmdline, and removing any other > special kernel parameters should make things work properly. This doesn't make things work properly. But see my response to your Comment #21. > Also please run: > > grep '.*' /sys/class/dmi/id/*_* 2> /dev/null /sys/class/dmi/id/bios_date:03/08/2013 /sys/class/dmi/id/bios_vendor:Acer /sys/class/dmi/id/bios_version:V2.15 /sys/class/dmi/id/board_asset_tag:Type2 - Board Asset Tag /sys/class/dmi/id/board_name:Mimic /sys/class/dmi/id/board_vendor:Acer /sys/class/dmi/id/board_version:Type2 - Board Version /sys/class/dmi/id/chassis_asset_tag: /sys/class/dmi/id/chassis_type:10 /sys/class/dmi/id/chassis_vendor:Acer /sys/class/dmi/id/chassis_version:V2.15 /sys/class/dmi/id/product_name:V5-171 /sys/class/dmi/id/product_version:V2.15 /sys/class/dmi/id/sys_vendor:Acer
(In reply to Hans de Goede from comment #21) > > Oops, correction, please try with: "video.use_native_backlight=1" on the > kernel cmdline rather then just "use_native_backlight=1". Yes! This fixes the problem. With this setting the keyboard brightness keys work _and_ I get the onscreen slider. The granularity is also nice and fine. Thank you. Not really wanting to be too nitpicky, but it _is_ a little sluggish -- when making a large change in brightness there's a very noticeable lag. Thank you and best regards, N.
Hi, Thanks for the testing. I've written a patch and added it to the Fedora-20 kernel package, where it will get picked up automatically by the next build. I've also started a kernel (scratch) build with the patch added for testing: http://koji.fedoraproject.org/koji/taskinfo?taskID=6803021 Note it is currently still building. Can you please give this build a try, it should work without you needing to specify any kernel cmdline parameters. Regards, Hans
(In reply to Hans de Goede from comment #26) > Hi, > > Thanks for the testing. I've written a patch and added it to the Fedora-20 > kernel package, where it will get picked up automatically by the next build. > > I've also started a kernel (scratch) build with the patch added for testing: > http://koji.fedoraproject.org/koji/taskinfo?taskID=6803021 > Note it is currently still building. > > Can you please give this build a try, it should work without you needing to > specify any kernel cmdline parameters. > > Regards, > > Hans Hi Hans, Just to clarify, I'm still on Fedora 19. Can I run your test kernel without upgrading to Fedora 20, or should I upgrade first? Thanks. N.
(In reply to N. Jackson from comment #27) > > Just to clarify, I'm still on Fedora 19. Can I run your test kernel without > upgrading to Fedora 20, or should I upgrade first? You should be able to download the i686 or x86_64 rpm (depending on what you're running) and install it with "rpm -ivh kernel...rpm" without problems. Note it is important to use rpm -ivh and not rpm -Uvh so that your current kernel stays installed, that way in case of problems you can always select your old kernel in the bootloader menu.
kernel-3.14.3-200.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.14.3-200.fc20
Package kernel-3.14.3-200.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.14.3-200.fc20' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6122/kernel-3.14.3-200.fc20 then log in and leave karma (feedback).
kernel-3.14.3-200.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Fedora Update System from comment #30) > Package kernel-3.14.3-200.fc20: > * should fix your issue, > * was pushed to the Fedora 20 testing repository, > * should be available at your local mirror within two days. > Update it with: > # su -c 'yum update --enablerepo=updates-testing kernel-3.14.3-200.fc20' > as soon as you are able to, then reboot. I was unable to retrieve this kernel, perhaps because I tried to get it without waiting the stipulated two days or perhaps because I was still on Fedora 19. Subsequently I got busy with other things and didn't get back to this until this weekend; sorry. Removing my acpi_osi=Linux workaround yesterday revealed that the bug is fixed for me in Fedora 19 with kernel 3.14.27-100.fc19.x86_64. I have the on-screen brightness notification slider thing working correctly with plenty of discrete steps. (It's a little sluggish/laggy but it's perfectly usable now I'm used to it.) Thank you. Also, after installing Fedora 21 (kernel 3.17.8-300.fc21.x86_64) today, the bug remains fixed. Thank you very much.
(In reply to N. Jackson from comment #32) > Removing my acpi_osi=Linux workaround yesterday revealed that the bug is > fixed for me in Fedora 19 with kernel 3.14.27-100.fc19.x86_64. I have the > on-screen brightness notification slider thing working correctly with plenty > of discrete steps. (It's a little sluggish/laggy but it's perfectly usable > now I'm used to it.) Thank you. > > Also, after installing Fedora 21 (kernel 3.17.8-300.fc21.x86_64) today, the > bug remains fixed. > > Thank you very much. Great, thanks for re-testing and for the feedback.