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.
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.