Many/most (maybe all?) Arrandale laptops (including at least the Dell 1558 and L501x) fail to work with the default acpi_video0 backlight device. Instead, the 3.1 kernel has merged a patch that exposes their backlight control via a /sys/class/backlight/intel_backlight device instead. Gnome doesn't recognize this, however, still attempting to use the broken device. I can't find anywhere this is configured; I suspect it may be hard coded. Ideally it should detect intel_backlight and prefer it where it exists, but at the very least it should be possible to configure the correct device as a workaround.
I have a similar situation on my MacBookPro. I have two backlight devices: [dwmw2@shinybook backlight]$ grep ^ */type gmux_backlight/type:platform intel_backlight/type:raw The intel_backlight device doesn't work; it has two levels 0 and 1, and toggling it makes no difference. If I use gsd-backlight-helper, it chooses the *correct* backlight; the gmux one: [dwmw2@shinybook backlight]$ /usr/libexec/gsd-backlight-helper --get-brightness 50000 But gnome-settings-daemon itself is using the wrong one: gdbus call --session --dest org.gnome.SettingsDaemon --object-path /org/gnome/SettingsDaemon/Power --method org.gnome.SettingsDaemon.Power.Screen.GetPercentage (uint32 100,) How does this happen?
After killing and restarting gsd, it doesn't offer the backlight setting at all: $ gdbus call --session --dest org.gnome.SettingsDaemon --object-path /org/gnome/SettingsDaemon/Power --method org.gnome.SettingsDaemon.Power.Screen.GetPercentage Error: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface `org.gnome.SettingsDaemon.Power.Screen' on object at path /org/gnome/SettingsDaemon/Power
It turns out it's not using gsd-backlight-helper. It's using gnome_rr_output_set_backlight() etc. instead, using the X server's backlight support. In dmesg I see this: [ 19.253013] i915: fixme: max PWM is zero The i915 driver *knows* that it doesn't have a valid backlight, but it sets it up anyway, and configures it with a bogus max brightness of 1. This is a kernel bug. For now I've hacked the sanity check in gnome-settings-daemon to check for a max brightness >1 instead of >0. Now it uses the gmux backlight correctly.
(In reply to comment #3) > The i915 driver *knows* that it doesn't have a valid backlight, but it sets > it up anyway, and configures it with a bogus max brightness of 1. This is a > kernel bug. Have you filed this at kernel.org? I'm not super happy adding workarounds to g-s-d for drm drivers that need fixing. Thanks.
gsd-backlight-helper will already choose the correct backlight, because it'll prefer the 'platform' backlight to the 'raw' one. But gsd-backlight-helper doesn't get used at all if X offers a backlight. Perhaps we should only use the backlight provided by X if there's no other choice, rather than favouring it over all others?
(In reply to comment #5) > Perhaps we should only use the backlight provided by X if there's no other > choice, rather than favouring it over all others? IIRC, Ajax wanted it the other way round, on the assumption the DDX would want to know about changes, rather than just making changes in the DRM/ACPI level. Richard
Then X needs to start getting it right... Intel driver fixed at http://lists.freedesktop.org/archives/intel-gfx/2012-September/020147.html FWIW. As noted in my response which didn't make it to the broken closed list, that leaves me with only *two* unwanted backlight devices at boot time; both ACPI devices, which disappear when I unload and reload the apple-gmux module.
Okay, good to hear the x driver got fixed. I'll close this now, thanks for doing the digging.