Comment 22 for bug 307306

Tracked this down with some of the ubuntu-x team..

The code in question is gnome-desktop / gnome-settings-daemon / gnome-power-manager / gdk.

g-p-m is sending a load of brightness change requests to produce a dimming effect when it chanes the backlight brighness.

For each change, we get an output property notification which is picked up by several listening clients.

gnome-settings-daemon listens to the Xrandr notifications directly, and reprobes information on recieving each backlight change notification.

gnome-power-manager's code-paths to listen directly to the Xrandr notifications seem to be disabled (if (FALSE)), however code _is_ called to attach to GDK's "monitors-changed" signal. When that is triggered, g-p-m probes Xrandr for events.

GDK is emitting a "monitors-changed" event for every Xrandr event encountered. As an _untested_ theory.. I'm wondering if the bug relating to the "window" property on some Xrandr notifications - (fixed in the noted libxrandr update), might have previously been causing GDK to drop some of those events?

Alberto Milone has worked up patches to g-s-d and g-p-m following my discovery that Xrandr 1.3 now supports an API to query for the "Current" data, rather than triggering a re-probe of the hardware.

I'm also a little suspicious that GDK's "monitors-changed" event is triggering rather more often than it needs to be, given the description of that event.) Alberto wonders if any TV-out output property changes are relevant to that though. My local fix to workaround the problem patches GDK to ignore Xrandr notifications for changes to output properties.