[Xevie] Re: Invitation to a discussion about an External Event Manager

[Keith Packard]

Around 11 o'clock on Sep 15, Deron Johnson wrote:

> I don't see a need to change the grab semantics. However, it my environment
> it is necessary to implement the grab semantics (according to the normal
> X11 rules) in my redirection client (aka the Display Server).  I need to do
> this because not only do I need to provide a comparable grabbing mechanism
> for LG-aware clients (which the X server doesn't know about) but I also
> need to ensure that X and LG-aware client grabs intermix properly.

Hmm.  I've read through the section on the Event Controller and I still can't
see why X grab processing must be duplicated within the LG Display 
Server.

Let me start by asserting a few things about passive grabs:

 a) The working space for event redirection is just the parent window and the
    set of children.  Ancestors above the parent and descendants below the 
    children aren't involved here.  This is necessary to ensure that
    'nesting' of event redirection works properly.

 b) Passive Grabs within the child windows aren't involved.  Once an event is
    sent off to a child window, the X server can process grabs in whatever way
    it chooses.

 c) Therefore, the only relevant passive grabs are those associated with the
    parent window.

In a "normal" LG environment, the 'parent' window is the Root window of the
screen, so the only passive grabs we need be concerned with are those on
the root window.  But, the window manager 'owns' mouse events delivered to
the root window, so it seems like this isn't a problem.  Just having the 
display server fail to deliver whatever events are grabbed in LG-aware 
applications seems like it will work.  It will prevent X applications from 
pre-emptively grabbing keys which LG-aware applications would like to use, 
but I don't see that as a huge problem.

Once a grab is active, I think the situation is a bit more complicated.
Essentially, we need the redirection client to rewrite the position wrt 
the grab window but otherwise not touch the event.  That means the X 
server needs to propogate events down the tree looking for redirection 
until it reaches the grab window, then it needs to deliver that event to 
any redirection client along with an indication of which child the event 
is being delivered to and that it is directed there because a grab is 
active.

However, thinking about active grabs has made it clear that event 
redirection is not just a simple test run before grab processing, we 
really need to traverse the tree looking for redirection even while a grab 
is active and ensure that the window and position information reflect 
whatever window geometry is presented by the redirection server.

-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/20040915/09e5e6ad/attachment.pgp