gtk+ and randr

[Graeme Gill]

Adam Jackson wrote:
> So basically the upshot is you can't treat EDID fetch as cheap, and thus
> any information derived from it should not be in APIs expected to be
> called a lot.  Now as far as I can tell, gtk really just wants the
> active screen topology, so it can know where the borders of the glass
> are for placement and where to maximize presentations to.  _That_ we can
> know cheaply.

For maintaining color display calibration, an event notifying the
calibration upload daemon is needed whenever a display is connected.
It will be looking for the EDID to match it with the appropriate
calibration and/or ICC profile, so ideally the output EDID property
should be updated by the server, and a property change event generated,
which the daemon can monitor.

This hasn't been the case with X11 versions I've tested, and polling
by calling XRRGetScreenResources() every couple of seconds seems the
only workaround.

Graeme Gill.