Bug 752595

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>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	16	CC:	dwmw2, hughsient, mt-ml, rhughes
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-09-03 15:44:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Andy Ross 2011-11-09 23:02:10 UTC

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 22:15:07 UTC

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 22:20:02 UTC

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 23:31:27 UTC

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 08:08:21 UTC

(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 11:30:17 UTC

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 13:39:17 UTC

(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 13:43:17 UTC

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 15:44:00 UTC

Okay, good to hear the x driver got fixed. I'll close this now, thanks for doing the digging.