Running Ubuntu jaunty on an i915 laptop, I've recently upgraded to libxrandr2 184.108.40.206. Upon login in the the first new X session after that, my screen started flickering constantly. Analysis of the xserver log showed that it was requesting the EDID lots of times. libxrandr 1.2.3 didn't show that problem, and downgrading to it returns sanity.
*** Bug 19047 has been marked as a duplicate of this bug. ***
my 965 isn't affected, but apparently 945 is:
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 220.127.116.11 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 18.104.22.168 server, however there are a number of randr fixes in the git tree for the 1.6 branch subsequent to this version:
randr: clear primaryOutput when the output is deleted
randr: use primary output for RRFirstOutput()
randr: Mangle GetScreenResources sort order based on primary output
randr: Mangle compat Xinerama reply based on primary output
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.
Author: Eric Anholt <firstname.lastname@example.org>
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).
(confirmed that with this patch I can xrandr --current --props without hitting the re-query)