Mailinglist Archive: opensuse-kernel (110 mails)
| < Previous | Next > |
Re: [opensuse-kernel] sysfs vs. xrandr support for manipulating display backlight brightness
- From: Takashi Iwai <tiwai@xxxxxxx>
- Date: Thu, 20 Oct 2011 16:44:56 +0200
- Message-id: <s5h8vofvi1j.wl%tiwai@suse.de>
At Thu, 20 Oct 2011 15:59:32 +0200,
Guido Berhoerster wrote:
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
battery device.
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().
Takashi
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-kernel+owner@xxxxxxxxxxxx
Guido Berhoerster wrote:
* Greg KH <gregkh@xxxxxxx> [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
use)?
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
battery device.
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().
Takashi
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-kernel+owner@xxxxxxxxxxxx
| < Previous | Next > |