Bug 752595 - Desktop uses wrong backlight device w/o tunable/workaround
Desktop uses wrong backlight device w/o tunable/workaround
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: gnome-desktop3 (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-09 18:02 EST by Andy Ross
Modified: 2012-09-03 11:44 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-03 11:44:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
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.

Note You need to log in before you can comment on or make changes to this bug.