[PATCH v6 inputproto 1/1] Multitouch updates for pointer emulation

Chase Douglas chase.douglas at canonical.com
Thu Feb 10 14:59:16 PST 2011


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


More information about the xorg-devel mailing list