At Thu, 20 Oct 2011 15:59:32 +0200,
Guido Berhoerster wrote:
* Greg KH <gregkh(a)suse.de> [2011-10-20 15:37]:
> On Thu, Oct 20, 2011 at 02:59:05PM +0200, Guido Berhoerster wrote:
> > Hi,
> > can anyone give me a rough estimation of the level of sysfs
> > support for setting backlight brightness on common hardware
> > compared to xrandr?
> They are two totally different things.
> > Basically, xfce4-power-manager has a bug in the xrandr backend
> > making it crash on resume
> > (https://bugzilla.novell.com/show_bug.cgi?id=707127
> > https://bugzilla.xfce.org/show_bug.cgi?id=7851
) and since
> > upstream is unresponsive I'm wondering what the cost/benefit of
> > temporarily disabling the xrandr backend would be, ie. whether
> > disabling the xrandr backend and relying exclusively on the sysfs
> > backend would break brightness manipulation for a large number
> > of users.
> xrandr should be using the sysfs interface the kernel exposes, if it is
> present, otherwise, it might try to use some other interface, but it
> should always be trying to use the sysfs one if it is there.
Thanks for the explanation, x-p-m can instead of xrandr use a
privileged helper binary to manipulate sysfs directly. How
prevalent is the kernel support for manipulating brightness via
sysfs (relative to any of the "other interfaces" xrandr might
Well, are you sure that the culprit is really xrandr? To me, the bug
looks like a problem in the battery handler itself.
In the recent kernels, the battery sysfs entry is once removed and
re-added at each time upon suspend/resume (don't ask me why). This
will trigger udev, and xfm-pm would react to delete and add the object
accordingly. Meanwhile, it calls the notification via X idle
mechanism, so the crashing path might be called after removing the
If this is the case, a workaround would be to cancel the pending
idle call via g_idle_remove_by_data() in xfpm_battery_finalize().