Hi, On Tue, Feb 08, 2011 at 10:12:19AM -0800, Keith Packard wrote: > On Tue, 8 Feb 2011 10:53:19 +0000, Daniel Stone <[email protected]> wrote: > > This > > means that one touch event may be simultaneously sending touch events > > through to touch clients, and enqueuing emulated pointer events as the > > device is frozen for a grab. Fun times. > > Does this mean the WM cannot consume the 'click to raise' event and that > the client will always see a touch event at that time? So we essentially > have two completely independent devices, one pointer and one touch that > happen to get events from the same underlying hardware?
Yes and no. I should've been more explicit here. The activated pointer
grab counts as the owner of the touch, so if you have the WM grabbing
for pointer events on a frame window and the app listening for touch
events on the child, the app will get TouchUpdateUnowned until the WM
decides what to do with it.
If the WM consumes the event and indicates so to the server with
Sync{Pointer,Both}, this is treated the same as a client calling
XIAllowTouchEvents with XITouchOwnerAccept: the app gets a TouchEnd
event indicating that the owner accepted the event.
If, however, the WM is disinterested and punts down the stack with
Replay{Pointer,Both}, this is treated the same as a client calling
XIAllowTouchEvents with XITouchOwnerReject: the app gets a
TouchOwnership event indicating that it is now the owner of the touch.
Either way, the end result is (should be?) indistinguishable from the WM
having a touch grab instead of a pointer grab, to everyone else in the
stack.
Should probably clarify that in the spec ...
Cheers,
Daniel
signature.asc
Description: Digital signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
