gtk+ and randr

[Adam Jackson]

On Mon, 2008-07-21 at 18:43 -0400, Ben Gamari wrote:
> On Mon, 2008-07-21 at 09:54 -0400, Adam Jackson wrote:
> > Caching doesn't solve anything.  Caching just means you get two
> > requests, one for "tell me a configuration you had some time in the
> > past" and one for "tell me how you're configured right now", and you end
> > up always calling the latter.
> 
> Someone really needs to tell the GTK+ folks that. Judging from some of
> the documents I mentioned in my original email, they seem pretty
> convinced that caching is the solution. I quote from [3] below,
> 
>         - X server work:
>         
>         	X server needs to poll for whether a monitor is plugged
>                 in. Whenever it detects a change, it should do an EDID query,
>                 and cache the resulting information. That way XRRGetScreenResources()
>         	can be the speed of a normal roundtrip. It's desirable that 
>         	normal client requests can still be processed during the EDID
>                 querying, but only a nice-to-have.

Polling for when the monitor is plugged means waking up at least 10
times a second or so.  Your battery won't be happy.  Yes, we can fix
this for some drivers, but not all.

Of course, now that I say this, I wonder if you couldn't get away with
only probing if you hit wakeup and it's been more than (say) a second
since the last probe time.  Clearly if the server's idle then the user
doesn't care about configuration so much...

But that still relies on output probe being cheap.  On Intel kit this is
apparently not the case; doing DDC requires turning the pipe on (!),
which is both kinda expensive and may require turning other pipes _off_
to handle topology weirdness.  Which means blinking, which means bad.

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.

I hacked up a proof-of-concept addition to the protocol along these
lines:

http://people.freedesktop.org/~ajax/patches/randrproto-1.3.patch

I'm not completely happy with it, but it's at least a starting point.
What API _do_ you want?

(GetScreenResources is clearly an example of generalizing from too few
examples.  Let this be a lesson to you.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20080723/5c5f77ea/attachment.pgp>