GNOME Bugzilla – Bug 750184
power: udev property for ignoring broken backlight devices
Last modified: 2015-06-04 19:10:13 UTC
Created attachment 304327 [details] [review] power: udev property for ignoring broken backlight devices Some older Toshiba laptops with Intel graphic card expose several backlight devices (platform, raw). The platform device is broken (doesn't work after resume), but that's the one picked up by gsd-backlight-helper. I opened a bug 9 months ago to have it fixed at the kernel level (https://bugs.freedesktop.org/show_bug.cgi?id=82634), but it doesn't look like Intel developers are seriously looking at fixing it. When gsd was controlling the backlight through xorg, a workaround was possible (Option "Backlight" "intel_backlight" in the Device section), but that's no longer the case. So I propose to use a udev property for ignoring broken backlight devices. For this specific model, this is the udev rule that can be used with the patch: sudo tee /etc/udev/rules.d/40-backlight.rules > /dev/null <<EOF # On Toshiba Portege R830 laptop, the acpi_vide0 backlight device doesn't work after suspend and resume # (https://bugs.freedesktop.org/show_bug.cgi?id=82634). # Ignore it in order to fall back to the intel_backlight device which always works. KERNEL=="acpi_video0", SUBSYSTEM=="backlight", ATTR{[dmi/id]product_name}=="PORTEGE R830", ENV{ID_BACKLIGHT_IGNORE}="1" EOF sudo udevadm control --reload
(In reply to Sylvain Pasche from comment #0) > Created attachment 304327 [details] [review] [review] > power: udev property for ignoring broken backlight devices > > Some older Toshiba laptops with Intel graphic card expose several backlight > devices (platform, raw). The platform device is broken (doesn't work after > resume), but that's the one picked up by gsd-backlight-helper. > > I opened a bug 9 months ago to have it fixed at the kernel level > (https://bugs.freedesktop.org/show_bug.cgi?id=82634), but it doesn't look > like Intel developers are seriously looking at fixing it. Why would the intel developers be interested in fixing a bug in the platform driver, which only talks to the firmware? > When gsd was controlling the backlight through xorg, a workaround was > possible (Option "Backlight" "intel_backlight" in the Device section), but > that's no longer the case. > > So I propose to use a udev property for ignoring broken backlight devices. Really not interested in that. In the worst case, the toshiba_acpi kernel driver developers would blacklist the backlight device for that model of laptop, and we wouldn't need any changes in gnome-settings-daemon or udev.
(In reply to Bastien Nocera from comment #1) > Why would the intel developers be interested in fixing a bug in the platform > driver, which only talks to the firmware? They triaged the issue as DRI > DRM/Intel so I assumed it was on their side, but maybe not. > Really not interested in that. In the worst case, the toshiba_acpi kernel > driver developers would blacklist the backlight device for that model of > laptop, and we wouldn't need any changes in gnome-settings-daemon or udev. With the help of Hans de Goede, we tried something like that (blacklisting the broken backlight device), but it didn't work (it created other issues). Anyway, Hans came up today with another fix which works this time. So, let's thank him and forget this hack :-)