Xrandr loop with gnome-settings-daemon [WAS: Re: Intel GM45: Loop of continuously triggered output detections]

[Peter Clifton]

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!)