Xrandr loop with gnome-settings-daemon [WAS: Re: Intel GM45: Loop of continuously triggered output detections]
pcjc2 at cam.ac.uk
Sat Jan 17 06:10:58 PST 2009
Ok, it looks like I was off-base on my diagnosis of an infinite loop.
It seems that gnome-power-manager may have been emitting a series of
very small changes in backlight brightness to cause a fading effect. The
fact that each triggered one (or more!) output probes meant that the
process took a very long time indeed!
Each change caused a notification from Xrandr, which all GDK using
applications then translated to a "monitors-changed" signal.
Interestingly, some people seeing the looping behaviour have reported it
as only occurring after an upgrade from libXrandr 1.2.3 to 18.104.22.168.
I've not had a lot of luck figuring out why this might be, but wonder if
the bug fixed during that period relating to a corrupt / unset "window"
property on the wire for some events, might have caused GTK to drop some
of those events in the past without handling them. (Just an untested
gnome-power-manager handles the "monitors-changed" signal by retrieving
information from Xrandr, causing a re-probe of outputs.
Patching GDK not to emit "monitors-changed" for output property
notifications causes the problem to go away as far as I can tell.
Now Xrandr 1.3 is available, on systems which have it,
gnome-power-manager should probably be calling
XRRGetScreenResourcesCurrent () in retaliation to notified events - at
the very least. (Not XRRGetScreenResources () as it currently uses)
Arguably, GDK shouldn't be generating a "monitors-changed" signal for an
output property change. The description of that signal states:
"The ::monitors-changed signal is emitted when the number, size or
position of the monitors attached to the screen change."
I presume output properties don't reflect any of the above changes?
Electrical Engineering Division,
University of Cambridge,
9, JJ Thomson Avenue,
Tel: +44 (0)7729 980173 - (No signal in the lab!)
More information about the xorg