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 1.2.99.2. 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 idea). 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? -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
