Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Desktop uses wrong backlight device w/o tunable/workaround|
|Product:||[Fedora] Fedora||Reporter:||Andy Ross <andy>|
|Component:||gnome-desktop3||Assignee:||Richard Hughes <hughsient>|
|Status:||CLOSED UPSTREAM||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||16||CC:||dwmw2, hughsient, mt-ml, rhughes|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-09-03 11:44:00 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Andy Ross 2011-11-09 18:02:10 EST
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.
Comment 1 David Woodhouse 2012-08-28 18:15:07 EDT
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?
Comment 2 David Woodhouse 2012-08-28 18:20:02 EDT
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
Comment 3 David Woodhouse 2012-08-28 19:31:27 EDT
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.
Comment 4 Richard Hughes 2012-09-03 04:08:21 EDT
(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.
Comment 5 David Woodhouse 2012-09-03 07:30:17 EDT
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?
Comment 6 Richard Hughes 2012-09-03 09:39:17 EDT
(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
Comment 7 David Woodhouse 2012-09-03 09:43:17 EDT
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.
Comment 8 Richard Hughes 2012-09-03 11:44:00 EDT
Okay, good to hear the x driver got fixed. I'll close this now, thanks for doing the digging.