Event redirection issue: determining the type of triggered grabs

[Keith Packard]

On Thu, 2006-01-12 at 16:54 -0800, Deron Johnson wrote:
> LG currently uses a scheme for handling 3D grabs which I would like to
> change. Keith has suggested that for every 3D object which has a 3D
> grab registered for it via the LG client API that we define a
> corresponding "3D proxy window" and register the grab information on
> that. This seems to me like it will work. However, in order for this
> to work completely, the LG Display Server (DS) will need to know when
> grabs trigger.

You'll get an X event when the grab fires. Is this insufficient in some
manner?

>  Furthermore, the DS will need to know the TYPE of grab
> which triggered (i.e. whether the grab was from a user-defined passive
> grab, a default button passive grab, or an active grab).  The DS needs
> this information in order to determine the specific 3D object to which
> the grab corresponds.

I'm sure I don't understand this part; if there is a simple mapping from
window to object. You can also use the intra-window position, which of
course you have complete control over with event redirection.

> The problem is that these mappings depend on knowing what type of grab
> triggered and with the current X protocol I have know way of knowing
> this.

Given that you specify the grabs yourself, you can do all kinds of
per-window tricks to identify which grab fired. I think there are plenty
of fields in the X events for you to uniquely identify every possible
grab.

>     State 1: Grab was triggered due to an active grab
>     State 2: Grab was triggered due to a user-defined passive grab
>     State 3: Grab was triggered due to a default button passive grab

If this is all you need, I suspect we can figure out a way to encode
this in existing events; we've got lots of unused fields (including
sub-window, X/Y position, etc.). Note that the passive grab will also
include the button press which causes the grab while active grabs will
not have an associated button press.

Is the event redirector already aware of what kind of object the cursor
is over? That would let it program information into the redirected event
which would come back to the display manager when the event is
delivered. Position and subwindow information can encode this even for
EnterNotify events.  

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-arch/attachments/20060112/cb88e73f/attachment-0003.pgp