*** Bug 19047 has been marked as a duplicate of this bug. ***

my 965 isn't affected, but apparently 945 is:

https://bugs.launchpad.net/ubuntu/+source/libxrandr/+bug/307306

My i965 (PCI ID 8086:2a02/8086:2a03) is affected. Downgrading libxrandr to 1.2.3 is awkward (I'm running Ubuntu Jaunty and a bunch of other stuff depends on it, which I don't really want to downgrade), but I looked through the changes between 1.2.3 and 1.2.99.2 and made a guess: forcing XRRGetCrtcTransform to think it's talking to a pre-1.3 server seems to be helping so far.

In my case, it was a little bit sluggish to start with although not hugely, but the EDID request storm really took off after unplugging my laptop from power and Ethernet and taking it away from my desk.

Ubuntu is currently using the 1.5.99.3 server, however there are a number of randr fixes in the git tree for the 1.6 branch subsequent to this version:

commit a82f10c5dd9fa74ff18759ab288bbd9c8b7ac4de
    randr: clear primaryOutput when the output is deleted

commit 2bc53ce66828b6c177e3298fa2f326c77c93e136
    randr: use primary output for RRFirstOutput()

commit f0234a9eb88ed103bca7db73a833c472ab95b48f
    randr: Mangle GetScreenResources sort order based on primary output

commit 2ef02833d614c42693e019a444560e84f501b5dc
    randr: Mangle compat Xinerama reply based on primary output

commit 0bdfdaa7df8105c7ffc3248a4fdd5f64da67103c
    randr: Add [GS]etOutputPrimary

Looking at the diffs, none jump out at me as obvious fixes for this problem, but especially the first two sound to me like potentially relevant.

I confirm the behaviour that Colin describes on my GM945: As long as I have the laptop docked (no battery) or undocked with power, it works reasonably, and I "only" get some 30 EDID detects in Xorg.0.log. But as soon as I unplug the power (I guess it's any change to power source which triggers this), the flood starts and the desktop becomes mostly unusable.

I tested Bryce's proposed workaround (http://launchpadlibrarian.net/20825929/disable_transform.patch) and it didn't work. No noticeable change.

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.

So is there any evidence of the server actually doing anything wrong?  It sounds like we have at least some instances of common clients misbehaving.

keithp pointed out that in fact the server *was* doing the wrong thing.

commit 10f26957f8392eb7913172f482f66eb71252761d
Author: Eric Anholt <eric@anholt.net>
Date:   Fri Jan 30 19:06:17 2009 -0800

    randr: Avoid re-querying the configuration on everything but GetScreenResources.
    
    The new path should only re-query on the other requests when we haven't
    gathered the information from the DDX yet (such as with a non-RandR 1.2 DDX).
    
    Bug #19037.

(confirmed that with this patch I can xrandr --current --props without hitting the re-query)