On 02/08/2011 05:53 AM, Daniel Stone wrote: > Hi, > Attached is the diff between the last multitouch spec posted to the > list, and what I've just pushed to my p.fd.o repository. This takes in > a lot of stuff I discussed with Peter during LCA, including: > > Pointer emulation: We'd hoped it'd be simpler, but as soon as Peter > pointed out that we need to support WMs grabbing pointer events on their > frame windows to raise the window, I knew we were in trouble. The new > approach is to consider both touch and pointer events as delivery > candidates at every level. So, constructing the window tree, we first > look for a touch grab on each window, then a pointer grab; after the > grabs are done, we look for the first touch or pointer selection. 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. > > Splitting touch rejection into two modes: RejectEnd with the same > behaviour as previously, and RejectContinue which passes ownership to > the next client in line, but does not remove that client from the > delivery set. The usecase here was for window managers and global > gesture managers that want to continue providing feedback to the user > (e.g. a visual trace of the path the gesture is taking, or an indication > of the touch location to show you that you've actually just missed the > button you were trying to press). > > New TouchBeginInert grab mode: As with above, will deliver events to > that grab but never grant it ownership.
This functionality isn't actually discussed anywhere. Also, TouchBeginInert events are mentioned but not defined. Do we really need a different type of event for an inert grab? I think either we assume the client knows it's inertially receiving events, or we should bring back the touch ownership flag. I'd be fine with either. > Add to and clarify usecases. > > Cosmetic cleanups: renaming PendingFinish to PendingEnd, TouchPointer to > PointerEmulated, et al. Should reduce confusion a little - I certainly > mixed up TouchOwnerAccept and TouchOwnerAccepted a couple of times. > > Comments welcome! > > Cheers, > Daniel > > diff --git a/XI2.h b/XI2.h > index 3f4d2c3..40c9ca6 100644 > --- a/XI2.h > +++ b/XI2.h > @@ -67,6 +67,7 @@ > #define XIGrabtypeEnter 2 > #define XIGrabtypeFocusIn 3 > #define XIGrabtypeTouchBegin 4 > +#define XIGrabtypeTouchBeginInert 5 > > /* Passive grab modifier */ > #define XIAnyModifier (1U << 31) > @@ -83,8 +84,8 @@ > > /* XIAllowTouchEvents bitmask event-modes */ > #define XITouchOwnerAccept (1 << 0) > -#define XITouchOwnerReject (1 << 1) > -#define XITouchNoPointerEmulation (1 << 2) > +#define XITouchOwnerRejectEnd (1 << 1) > +#define XITouchOwnerRejectContinue (1 << 2) > > /* DeviceChangedEvent change reasons */ > #define XISlaveSwitch 1 > @@ -132,11 +133,11 @@ > /* Device event flags (key events only) */ > #define XIKeyRepeat (1 << 16) > /* Device event flags (pointer events only) */ > -#define XITouchPointer (1 << 16) > +#define XIPointerEmulated (1 << 16) > /* Device event flags (touch events only) */ > -#define XITouchOwner (1 << 16) > -#define XITouchOwnerAccepted (1 << 17) > -#define XITouchPendingFinish (1 << 18) > +#define XITouchPendingEnd (1 << 16) > +/* Device event flags (touch end events only) */ > +#define XITouchAccepted (1 << 17) XITouchAccepted isn't mentioned anywhere else. What is it's purpose? Is it a left over from the reason field of an Ownership event? I *think* the rest looks good. Thanks! -- Chase _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
