GNOME Bugzilla – Bug 688052
Brightness can't be controlled although interfaces are available
Last modified: 2019-03-21 01:41:09 UTC
Hi, basically what my problem comes down to is that I can't control the brightness from within GNOME. When pressing the appropriate keys on my keyboard, nothing happens. In contrast to that the volume adjustment works just fine. The system I'm talking about is a Sony laptop. I've contacted the maintainer of the sony-laptop kernel module and according to him it seems to work fine (although he came up with some changes, which in the mean time were merged into mainline already). So the appropriate interface(s) in /sys/class/backlight are available, but for some reason GNOME doesn't recognize them. Here is a listing of the interfaces, which are available: [root@vpcs backlight]# ls -lR */* -r--r--r-- 1 root root 4096 31. Okt 02:01 nv_backlight/actual_brightness -rw-r--r-- 1 root root 4096 31. Okt 02:01 nv_backlight/bl_power -rw-r--r-- 1 root root 4096 31. Okt 01:49 nv_backlight/brightness lrwxrwxrwx 1 root root 0 31. Okt 02:01 nv_backlight/device -> ../../card0-LVDS-1 -r--r--r-- 1 root root 4096 31. Okt 02:01 nv_backlight/max_brightness lrwxrwxrwx 1 root root 0 31. Okt 01:25 nv_backlight/subsystem -> ../../../../../../../../class/backlight -r--r--r-- 1 root root 4096 31. Okt 01:44 nv_backlight/type -rw-r--r-- 1 root root 4096 31. Okt 01:25 nv_backlight/uevent -r--r--r-- 1 root root 4096 31. Okt 02:01 sony/actual_brightness -rw-r--r-- 1 root root 4096 31. Okt 02:01 sony/bl_power -rw-r--r-- 1 root root 4096 31. Okt 01:48 sony/brightness -r--r--r-- 1 root root 4096 31. Okt 01:51 sony/max_brightness lrwxrwxrwx 1 root root 0 31. Okt 01:48 sony/subsystem -> ../../../../class/backlight -r--r--r-- 1 root root 4096 31. Okt 01:48 sony/type -rw-r--r-- 1 root root 4096 31. Okt 01:48 sony/uevent nv_backlight/power: insgesamt 0 -rw-r--r-- 1 root root 4096 31. Okt 02:01 async -rw-r--r-- 1 root root 4096 31. Okt 02:01 autosuspend_delay_ms -rw-r--r-- 1 root root 4096 31. Okt 02:01 control -r--r--r-- 1 root root 4096 31. Okt 02:01 runtime_active_kids -r--r--r-- 1 root root 4096 31. Okt 02:01 runtime_active_time -r--r--r-- 1 root root 4096 31. Okt 02:01 runtime_enabled -r--r--r-- 1 root root 4096 31. Okt 02:01 runtime_status -r--r--r-- 1 root root 4096 31. Okt 02:01 runtime_suspended_time -r--r--r-- 1 root root 4096 31. Okt 02:01 runtime_usage sony/power: insgesamt 0 -rw-r--r-- 1 root root 4096 31. Okt 02:01 async -rw-r--r-- 1 root root 4096 31. Okt 02:01 autosuspend_delay_ms -rw-r--r-- 1 root root 4096 31. Okt 02:01 control -r--r--r-- 1 root root 4096 31. Okt 02:01 runtime_active_kids -r--r--r-- 1 root root 4096 31. Okt 02:01 runtime_active_time -r--r--r-- 1 root root 4096 31. Okt 02:01 runtime_enabled -r--r--r-- 1 root root 4096 31. Okt 02:01 runtime_status -r--r--r-- 1 root root 4096 31. Okt 02:01 runtime_suspended_time -r--r--r-- 1 root root 4096 31. Okt 02:01 runtime_usage Let me know, if there is something more specific you would like to have and/or need to narrow this down. Best regards, Karol Babioch
I can confirm the bug on 3.11.4-1-ARCH #1 running on Lenovo Y500 with Gnome 3.10.0. Keyboard shortcuts for brighness display and change gnome indicator for brightness but screen brightness is not changed. Changing the brightness in the new "power" menu also does nothing. xbacklight -dec/inc does work in terminal to change brightness.
I'm not sure if I should comment on this bug or open a new one, but this seems to be mostly the same problem that I have. I bought a new laptop last week. It's an ASUS ROG GL502VM and I readily installed Fedora 25 Workstation and the NVIDIA Proprietary Drivers from RPMFusion without any major problems. However I noticed that the Fn+F5 and Fn+F6 keys to control brightness were not working (even though Fn+F10, Fn+F11 and Fn+12 control the volume just fine). I know that this is most likely not a GNOME related issue, it should be a kernel/driver issue, but please continue reading because what I want to report goes beyond the Fn keys. To solve the problem I tried many of the tips that I could find online. For instance, setting the kernel parameters to acpi_osi=Linux and trying acpi_backlight=vendor, video, native or none, but nothing worked. Even if I tried to manually change the values on the /sys/class/backlight interfaces (usually acpi_video0, but some of the combinations I tried also showed acpi_video1 and even asus-nb-wmi). Then I came across xbacklight and everything worked smoothly. When I use xbacklight -dec and -inc I'm able to the change brightness of my screen. As a workaround I did some key remapping to use it as Meta+F5 and Meta+F6. However, I also noticed that the GNOME Indicator for Brightness did not reflect any of the changes that I do via xbacklight. Intrigued I tried to run a Ubuntu 16.10 Live USB which allow me to easily boot and install the NVIDIA drivers to do some testing. The same happened there, so it didn't seem to be a distro related issue. Just out of curiosity I also tried Kubuntu 16.10 and to there, to my amazement, KDE Plasma 5.7.5 is able to change the brightness if I move the bar in the brightness indicator. In fact, if I do "xbacklight -set [SOME VALUE]" the brightness changes accordingly and the indicator reflects that change instantaneously. So, what I want to know, is if it possible (and desirable) to implement the GNOME brightness indicator in the same way as on KDE Plasma. Their implementation seems to be more robust when it comes to dealing with problematic hardware. I don't know exactly what do they use as their backend. Are they using xbacklight directly? And what is GNOME using? This is just a heads up so that someone can check how is the "competition" doing it and assess if they have a better solution for this problem. Meanwhile, if you need any further details please don't hesitate to ask.
i have the same situation. My MSI notebook has pascal graphics card + can use the integrated graphics, but you must switch them in the BIOS to either IGPU or DGPU, you can't switch on the fly "optimus-like" or "hybrid-like" or whatever it is called. The shell program "xbacklight -set 30" work in both Ubuntu and Plasma sessions, however the Fn + Up/Down arrow only work on Kde, on ubuntu the brightness stays at 100%. Note that with the nvidia, inside the folder '/sys/class/backlight/' there is nothing, yet xbacklight works. So gnome/wayland/unity whatever is the culprit it's not doing it properly. See here for ubuntu bug: https://bugs.launchpad.net/gnome-power/+bug/1720438
Switching to integrated graphics the Fn works perfectly on gnome. Also: ls -l /sys/class/backlight/ total 0 lrwxrwxrwx 1 root root 0 may 5 12:12 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight
gnome-settings-daemon has some logic to select the correct brightness control and change that. It could be, that this is failing for some reason sometimes. Could anyone with a failure, please attach the output of "udevadm info -e" for a start? This allows us to figure out which backlight GNOME will try to control. It does sound like the core of the issue is that there are no brightness controls for nvidia other than through the X11 driver. Yet, because we find an intel backlight control in sysfs, gnome-settings-daemon tries to control that rather than falling back to going through X11. So, it boil down to us having two brightness controls that would need to be modified in sync.
(In reply to Benjamin Berg from comment #5) > gnome-settings-daemon has some logic to select the correct brightness > control and change that. It could be, that this is failing for some reason > sometimes. > > Could anyone with a failure, please attach the output of "udevadm info -e" > for a start? This allows us to figure out which backlight GNOME will try to > control. > > It does sound like the core of the issue is that there are no brightness > controls for nvidia other than through the X11 driver. Yet, because we find > an intel backlight control in sysfs, gnome-settings-daemon tries to control > that rather than falling back to going through X11. > > So, it boil down to us having two brightness controls that would need to be > modified in sync. Here you have the attachment for "udevadm info -e" as root, on Ubuntu 18.04, on my MSI GT73VR.
Created attachment 372038 [details] udevadm_info_e-ubuntu-18.04-MSI-GT73VR.txt
Some sensitive data has been replaced by 'REMOVED'.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/196.