[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