[Xevie] Re: my last response to Keith

[Keith Packard]

Around 10 o'clock on Sep 24, Deron Johnson wrote:

> In your last mail, you were wondering why it is necessary to do grab 
> processing in the LG display server. I sent you a response. Have you
> had time to think about this yet?  Thanks.

Sorry, I missed it when it arrived.

> When the DS encounters an event destined for an X window, it is sent
> back to the X server. Lets say the X server searches for passive grabs
> on this event and lets say it finds one. The passive grab triggers
> into an active grab. Now that an active grab is in effect, all device
> input events for the grabbed device must go to the grab window.

Ok, the possible races do look bad...

However, if we consider nested event redirection as part of the plan, I 
don't see how we can possibly fix this in an asynchronous world -- there's 
no way for the DS to compute the entire sprite trace at the time it sees 
the event.  

Even in a non-nested world, the DS would have to share the entire window
hierarchy and all of the grab state within the X server for this to be
doable.  In a non shared-memory environment (which seems rather desirable
to me), we're talking about adding a huge number of events to the protocol
so that the DS can shadow the state of the X server within its address
space.

Let's see if we can't do this in a less complicated fashion.

Here's a short sketch of one idea:

For a given hiearchy, the X server can compute the set of events which
'might' trigger a grab.  We could 'flag' those events before delivering
them to the DS, then the DS would process the event and if it ended up
sending the event back to the X server, it would use a synchronous request
to enqueue the event which returned the current grab state of the various
input devices.

Heck, we might just *always* do this for button and key events; that would 
certainly be an easy way to give this notion a try.

With that event processed synchronously, it could then carry on processing 
other events, knowing the state of grabs within the X server.

> This scenario illustrates that all grab processing in a 3D window
> system must be atomic with respect to the event queue; we can't have X
> grab processing occuring asynchronously from the rest of the input
> processing. This is why I believe we must do all of the grab processing
> in the Display Server and no grab processing should occur in the X server.

Yes, I agree that the processing of events which can activate a passive 
grab must be done synchronously; let's try to find a way which doesn't 
duplicate the bulk of the window system state within another process.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xevie/attachments/20040924/257aa211/attachment.pgp