GNOME Bugzilla – Bug 747781
/etc/X11/xorg.conf.d/20-intel.conf ignored by gsd-backlight-helper
Last modified: 2016-01-19 15:23:48 UTC
To be able to control the brightness of my Toshiba laptop after wakeup from sleep I need a custom config file with the following content: Section "Device" Identifier "card0" Driver "intel" Option "Backlight" "intel_backlight" BusID "PCI:0:2:0" EndSection without this, the brightness controls use the "toshiba" device instead of the "intel_backlight" which fails to control the actual brightness of the screen after wakeup from sleep. Until the update to Gnome 3.16, this was working fine. Now, this conf file is respected until I put my laptop to sleep and then it reverts to controlling "toshiba" as the backlight device. I'm using Arch Linux with latest Xorg 1.17. How to replicate: Before sleep: cat /sys/class/backlight/intel_backlight/actual_brightness Value changes when changing brightness. After sleep: /sys/class/backlight/intel_backlight/actual_brightness does not change when changing brightness but /sys/class/backlight/toshiba/actual_brightness does.
This is not related to gdm. I replaced gdm with lightdm and the problem persists. Since I do not know what package is responsible for this issue I'm choosing "General" as product.
Actually the xorg.conf.d file is being ignored not only after wakeup from sleep but from the start. I had that impression because brightness control works before sleep but that's not because the conf file is being obeyed but simply because the toshiba device works before sleep.
I tried masking the systemd backlight device (sys-devices-LNXSYSTM:00-device:00-TOS6208:00-backlight-toshiba.device), rebooting and testing brightness control but there was no change. Next I tried masking the systemd service (systemd-backlight@backlight:toshiba.service) hoping Gnome would use the other service (intel_backlight) but again this did not have any effect.
I can change the brightness after sleep with: sudo tee /sys/class/backlight/intel_backlight/brightness <<< 700
If more information is required to help debug this issue then please let me know.
I just realised that gdm is using Wayland through another bug (https://bugzilla.redhat.com/show_bug.cgi?id=1200581). Even though I'm not using Gnome on Wayland, is it possible that somehow Gnome is using Wayland settings and thus ignoring the custom Xorg configuration? A way to test this hypothesis is to configure Wayland to use the correct backlight device but I didn't find any documentation on this subject.
I hav acpi_backlight=vendor as kernel parameter. I ran "grep -r . /proc/acpi " and got (partial output): /proc/acpi/toshiba/fan:running: 0 /proc/acpi/toshiba/fan:force_on: 0 /proc/acpi/toshiba/lcd:brightness: 1 /proc/acpi/toshiba/lcd:brightness_levels: 8 /proc/acpi/toshiba/keys:hotkey_ready: 0 /proc/acpi/toshiba/keys:hotkey: 0x0000 /proc/acpi/toshiba/video:lcd_out: 0 /proc/acpi/toshiba/video:crt_out: 0 /proc/acpi/toshiba/video:tv_out: 0 /proc/acpi/toshiba/version:driver: 0.21 /proc/acpi/toshiba/version:proc_interface: 1 cat /sys/class/backlight/toshiba/type = platform cat /sys/class/backlight/intel_backlight/type = raw
I tried blacklisting the toshiba_acpi kernel module and adding acpi_backlight=vendor in grub and Gnome used intel_backlight and worked well before and after sleep but this had a nasty side-effect: When waking the laptop from sleep, the screen would remain black. The only workaround this issue was to close the laptop lid and open it again. I tried installing xfce and brightness control works well. This is not an xorg problem but a Gnome one. Also xbacklight works fine. Is there a way to configure Gnome to use the intended backlight device?
The culprit is /usr/lib/gnome-settings-daemon/gsd-backlight-helper. Is there a way to change the order of preference of type of backlight device, that is, to prefer raw over platform type? Or to add intel_backlight to the list of preferred devices with a higher priority than the toshiba device?
Please re-assign this bug. This shouldn't be assigned to GDM Maintainers since the bug is not related to gdm but to gnome-settings-daemon.
I'm suffering for the same issue on Fedora 22 with a Toshiba Portege R830 laptop. I opened this bug some times ago for fixing the issue at the kernel level: https://bugs.freedesktop.org/show_bug.cgi?id=82634. Maybe it could help if you comment there with your hardware information.
This patch works around the problem for Arch Linux. https://aur.archlinux.org/packages/gnome-settings-daemon-backlight-toshiba/
I have this problem with a Dell 17R (5737). The OSD appears as expected. The values of /sys/class/backlight/dell_backlight/brightness change, but it is the values of /sys/class/backlight/intel_backlight/brightness that actually handle the backlight. None of the options listed on https://hansdegoede.livejournal.com/13889.html solve the problem. GNOME 3.14 worked wonderfully with a custom /usr/share/X11/xorg.conf.d/20-intel.conf
@erusan Are you using Arch Linux? If you are, the aur package mentioned in comment 12 should work with your system too.
For reference, on Wayland, xorg.conf.d is indeed ignored, because we don't have an X stack or the xf86-video-intel to interpret it. Backlight has been a tricky thing for a long time, with lots of vendors doing different things. The best option here is to fix this at the kernel level so that ACPI backlight works out of the box. When some of the kernel developers have some free time, we'll be looking into providing this as part of atomic modesetting, so that setting a backlight should just work.
Jasper, Hans de Goede has a kernel patch here: https://bugzilla.kernel.org/show_bug.cgi?id=21012#c35 Is this the kernel solution you're looking for?
This bug remains in GNOME 3.18.1. (In reply to Entodo Ays from comment #14) > @erusan Are you using Arch Linux? If you are, the aur package mentioned in > comment 12 should work with your system too. This patch does work for me on Debian, both in GNOME 3.16 and GNOME 3.18. The hack to get around linking plugins is still required, as well.
I have a Zoostorm Fizzbook (http://www.fizzbook.com/), essentially a netbook with a pivoting resistive touch screen designed for education. It is a type of Intel ClassMate PC (http://www.intel.com/content/www/us/en/education-solutions/classmatepc-convertible.html) Initially the backlight was set to full brightness and could not be changed. I was running Ubuntu Gnome 15.04 (based on Gnome 3.14). Adding the 20-intel.conf Xorg configuration file as described in the initial bug description fixed the problem. When I upgraded to Ubuntu Gnome 15.10 (based on Gnome 3.16) the backlight control was broken again. Presumably the dependencies on Xorg configuration files have been removed as part of the Wayland changes. Running the following command for interface in /sys/class/backlight/*; do echo -e "\n $interface"; cat $interface/{brightness,max_brightness,actual_brightness}; done displays /sys/class/backlight/cmpc_bl 3 7 3 /sys/class/backlight/intel_backlight 1000 13046 1000 The Gnome shell brightness control changes the values on the cmpc_bl backlight device which has no effect. Changing values on the intel_backlight device using xbacklight changes the brightness levels. Following the advice I have tried all combinations of acpi_backlight and acpi_osi kernel parameters to no effect. Backlisting the classmate_laptop module isn't an option because it controls other things. The problem appears to be with the gsd_backlight_helper_get_best_backlight() function in gnome-settings-daemon/gsd-backlight-helper.c. The backlight_interfaces array lists a seemingly arbitrary hard coded list of backlight interfaces from various vendors. The two interfaces on my device (cmpc_bl and intel_backlight) do not appear in this list so they are not recognised. The fallback is to use the first device alphabetically, which in my case is the wrong device (cmpc_bl). Would it be possible to add some logic to this function to lookup a dconf setting (if present) indicating the preferred backlight device to use? Perhaps an experienced Gnome developer can suggest a more elegant solution? It seems that in the move to Wayland the flexibility of the X configuration files has been sacrificed. Can we have a similar mechanism to replace it? I am willing to help code the fix if someone can provide me some direction. Many thanks.
Hi Barry, Gnome developers won't accept configuration options or related to make backlights work when they don't work by default (bug 750184). By the way, https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gsd-backlight-linux.c#n49 doesn't contain vendor specific code, it just prioritizes the backlight interfaces by their sysfs "type" attribute. I guess that in your case the broken one takes priority. It should be fixed at the kernel level. The first thing I would try is to see if that's fixed with a recent kernel. The easiest way to do it is perhaps to boot a live Fedora 23 image. If that's still broken, you should open a bug to fix it at the kernel level (and check if there isn't already one open). Hans gives a procedure on his blog: http://hansdegoede.livejournal.com/13889.html. For instance, Hans added a quirk for my laptop which had a similar issue: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/acpi_video.c#n443
As some have already pointed, this should be fixed in the kernel. Closing