Description of problem: Using Fn+F8/F9 doesn't change backlight brightness (Neither does the GNOME toolbar widget). xbacklight also has no effect. Attempted boots with video.use_native_backlight=1 and acpi_backlight=vendor - the latter works with the latest Gnome for Rawhide. Background information ====================== $ ls -l /sys/class/backlight/ total 0 lrwxrwxrwx. 1 root root 0 Apr 30 13:22 acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0 $ lspci -v -s 00:01.0 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 00005000-00005fff Memory behind bridge: f2000000-f30fffff Prefetchable memory behind bridge: 00000000e0000000-00000000f1ffffff Capabilities: <access denied> Kernel driver in use: pcieport Kernel modules: shpchp $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.15.0-0.rc3.git1.10.fc21.x86_64 root=/dev/mapper/fedora_oak-root ro rd.lvm.lv=fedora_oak/root rd.lvm.lv=fedora_oak/swap rhgb quiet LANG=en_US.UTF-8 slub_debug=- $ grep '.*' /sys/class/dmi/id/*_* 2> /dev/null /sys/class/dmi/id/bios_date:05/24/2013 /sys/class/dmi/id/bios_vendor:LENOVO /sys/class/dmi/id/bios_version:G5ET93WW (2.53 ) /sys/class/dmi/id/board_asset_tag:Not Available /sys/class/dmi/id/board_name:243852U /sys/class/dmi/id/board_vendor:LENOVO /sys/class/dmi/id/board_version:Win8 Pro DPK TPG /sys/class/dmi/id/chassis_asset_tag:No Asset Information /sys/class/dmi/id/chassis_type:10 /sys/class/dmi/id/chassis_vendor:LENOVO /sys/class/dmi/id/chassis_version:Not Available /sys/class/dmi/id/product_name:243852U /sys/class/dmi/id/product_version:ThinkPad W530 /sys/class/dmi/id/sys_vendor:LENOVO Version-Release number of selected component (if applicable): 3.15.0-0.rc3.git1.10.fc21.x86_64 How reproducible: Always Steps to Reproduce: 1. Boot 2. Attempt to change brightness 3. Log in 4. Attempt to change brightness Actual results: Nothing Expected results: Brightness should change Additional info: $ rpm -q gnome-shell gnome-shell-3.12.1-1.fc21.x86_64
Per the instructions of poma [0] I updated my bios, still to no avail. # echo $(dmidecode -s bios-version && dmidecode -s bios-release-date) G5ET98WW (2.58 ) 04/01/2014 [0] https://bugzilla.redhat.com/show_bug.cgi?id=1012674#c16
Thanks for the bug report, what does ls -l /sys/class/backlight say when you run it after booting with acpi_backlight=vendor ?
And can you also please try with acpi_osi="!Windows 2012" on the kernel cmdline, and then again do: ls -l /sys/class/backlight And ofcourse let us know if the backlight control works or does not work that way.
(In reply to Hans de Goede from comment #2) > Thanks for the bug report, what does ls -l /sys/class/backlight say when you > run it after booting with acpi_backlight=vendor ? $ ls -l /sys/class/backlight total 0 lrwxrwxrwx. 1 root root 0 May 7 11:06 nv_backlight -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-LVDS-1/nv_backlight
(In reply to Hans de Goede from comment #3) > And can you also please try with acpi_osi="!Windows 2012" on the kernel > cmdline, and then again do: > ls -l /sys/class/backlight > > And ofcourse let us know if the backlight control works or does not work > that way. $ ls -l /sys/class/backlight total 0 lrwxrwxrwx. 1 root root 0 May 7 11:58 acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0 Backlight controls don't work with this option. However, they do work with acpi_backlight=vendor. Sorry for the long response time. Let me know if there's anything else I can provide. Thanks!
Hi Mike, Thanks for the info, can you please double check that "video.use_native_backlight=1" on the kernel cmdine does not help ? I find that a bit weird as it helps for all the other *30 Thinkpad models. Regards, Hans
I've just started a scratch kernel build which adds a quirk to force using the native backlight on the W530, can you please install this (with "rpm -ivh --oldpackage kernel...rpm"), and boot into it with nothing special on the kernel commandline and see if it fixes things ? You can find the build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=6826119 Note this is still building atm. Also I would still like you to retry with 3.15 + video.use_native_backlight=1. Thanks, Hans
Hans, I started by attempting the video.use_native_backlight=1 param. $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.15.0-0.rc4.git3.1.fc21.x86_64 root=/dev/mapper/fedora_oak-root ro rd.lvm.lv=fedora_oak/root rd.lvm.lv=fedora_oak/swap rhgb quiet LANG=en_US.UTF-8 video.use_native_backlight=1 slub_debug=- Results in non-working backlight controls. Installing the scratch kernel results in no change. Still nothing when attempting to change backlight settings. $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.14.3-200.rhbz1093171.fc20.x86_64 root=/dev/mapper/fedora_oak-root ro rd.lvm.lv=fedora_oak/root rd.lvm.lv=fedora_oak/swap rhgb quiet LANG=en_US.UTF-8 Thanks again for working on this! // Mike
Ah, found the problem why the scratch build and the video.use_native_backlight=1 param do not work. the nouveau driver is wrongly calling acpi_video_backlight_support() and not registering itself if that returns true. That function is only intended for use in firmware backlight drivers where as the nouveau driver is a native / raw backlight driver.
Created attachment 894577 [details] PATCH: nouveau: Don't check acpi_video_backlight_support() before registering backlight This patch should fix video.use_native_backlight=1 not helping. I'll do a scratch build for you to test later today, including this patch + a patch to make video.use_native_backlight=1 the default on your laptop.
Quick status update, upstream review of the patch has shown that fixing this is not as simple as that :| For now just keep using acpi_video=vendor, I'll keep working upstream towards a proper fix for this.
Ok, I've just started a scratch kernel build with a set of patches which should hopefully fix this, you can download it here: http://koji.fedoraproject.org/koji/taskinfo?taskID=6853115 Note it is still building atm. After downloading install with "rpm -ivh kernel....rpm", and reboot into it without any special kernel cmdline options. Then please let know what the output of ls /sys/class/backlight is, and if everything works as it should. Regards, Hans
Hans, $ ls /sys/class/backlight/ nv_backlight and everything seems to be working with this scratch build. Sorry I didn't get to it Friday. But it looks like you've got it nailed :) Thanks! // Mike
Hi, (In reply to Mike Ruckman from comment #13) > Hans, > > $ ls /sys/class/backlight/ > nv_backlight > > and everything seems to be working with this scratch build. Sorry I didn't > get to it Friday. But it looks like you've got it nailed :) > > Thanks! > > // Mike Thanks for testing. It is good to hear that my patch-set works as advertised, I've send it upstream, hopefully I'll get some feedback on it soon. In the mean time please keep using the scratch build, and let me know if you discover that it breaks something. Regards, Hans
I'll try to switch back and test it. I'm currently running the rawhide kernels as they get updated. // Mike
Hi, I've just started a scratch build of a 3.15 kernel with the fixes for this included, the plan is to add these fixed to the official Fedora 3.15 builds soon, so please test! Please download the kernel-3.15...rpm file for your architecture from here: http://koji.fedoraproject.org/koji/taskinfo?taskID=6919326 And then install it using: sudo rpm -ivh kernel-3.15...rpm Note when installing kernels it is important to rpm -i so that you keep your current kernel as a backup. Then boot into that kernel without any special kernel commandline parameters, and let me know if that works. Once I get confirmation from you that this fixes things I'll send the patch upstream for inclusion into the official Linux kernel, so that the fix will get included into other distributions too. Note please ignore the bug 1025690 number in the version of the kernel, this kernel contains a whole batch of backlight fixes, of which the fix for 1025690 is the latest fix added, hence I used that number. Regards, Hans
Hans, Thanks for the hard work on this. That scratch build worked great. Thanks! // Mike
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Same thing occurs in my Toshiba Satellite running Fedora 22 Beta. It used to work with the xorg.conf workaround [1] (neither acpi_backlight=vendor, video.use_native_backlight=1 worked), but now it doesn't. Should I file a separate bug report? $ uname -a Linux toshiba-laptop 4.0.0-1.fc22.x86_64 #1 SMP Mon Apr 13 10:03:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [1] https://wiki.archlinux.org/index.php/Intel_graphics#Backlight_is_not_adjustable
Hi, (In reply to Alex Puchades from comment #19) > Same thing occurs in my Toshiba Satellite running Fedora 22 Beta. It used to > work with the xorg.conf workaround [1] (neither acpi_backlight=vendor, > video.use_native_backlight=1 worked), but now it doesn't. Should I file a > separate bug report? Yes please, file a separate bug report against component kernel and assign it to me at bug creation time, or put me in the Cc and I'll assign it to myself. Regards, Hans
*********** 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 22 kernel bugs. Fedora 22 has now been rebased to 4.2.3-200.fc22. 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 23, and are still experiencing this issue, please change the version to Fedora 23. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.