Re: A possible problem with an external compositing manager

Around 22 o'clock on Nov 12, Keith Whitwell wrote:

> It really is a terrible way to synchronize with the hardware...

Yes, as it requires the X server stall the hardware and wait until it's 
idle.  It doesn't request stalling the network protocol as a good library 
implementation (aka XCB) will encourage you to avoid blocking in this case.

> I remember working out once apon a time a trick that somehow provoked the X 
> server to send be back an asynchronous notification that a certain point in 
> the protocol stream had been reached - maybe somehow by provoking an event? 
> That code is long gone, though others have probably done the same thing a 
> dozen times.

The traditional way is with a ChangeProperty request; that sends an event. 
There's no fundemental difference between this and an other request that 
generates a reply (like GetInputFocus), except that Xlib makes it hard to 
avoid blocking while awaiting the reply.

> That was the closest I was able to get to non-blocking synchronization - only 
> at the protocol level, though, there was no way to extend it to be equivalent 
> to the getimage hack.

Sounds like we'd need some kind of breadcrumb technique for the X server; 
something I've never thought of before.  I think the XSync extension could 
probably provide this kind of mechanism at the protocol level; essentially 
a counter that tracked the request ID completed by the graphics hardware 
for each client.  Then you'd be able to get an event back when the 
hardware passed a specific request, without blocking the world.

-keith