[PATCH 1/2] Extend XIAllowEvents for handling touch grab processing

Peter Hutterer peter.hutterer at who-t.net
Wed Sep 14 09:57:21 PDT 2011


On Wed, Sep 14, 2011 at 10:22:35AM -0500, Chase Douglas wrote:
> This removes the XIAllowTouchEvents request, which was the only new
> request added for multitouch.
> 
> Signed-off-by: Chase Douglas <chase.douglas at canonical.com>

Reviewed-by: Peter Hutterer <peter.hutterer at who-t.net>

> ---
>  XI2.h              |    6 +--
>  XI2proto.h         |   20 ++----------
>  specs/XI2proto.txt |   87 +++++++++++++++++++--------------------------------
>  3 files changed, 38 insertions(+), 75 deletions(-)
> 
> diff --git a/XI2.h b/XI2.h
> index 2e19e03..2514d55 100644
> --- a/XI2.h
> +++ b/XI2.h
> @@ -108,10 +108,8 @@
>  #define XIAsyncPairedDevice                     3
>  #define XIAsyncPair                             4
>  #define XISyncPair                              5
> -
> -/* XIAllowTouchEvents bitmask event-modes */
> -#define XITouchAccept                           (1 << 0)
> -#define XITouchReject                           (1 << 1)
> +#define XIAcceptTouch                           6
> +#define XIRejectTouch                           7
>  
>  /* DeviceChangedEvent change reasons */
>  #define XISlaveSwitch                           1
> diff --git a/XI2proto.h b/XI2proto.h
> index 8117767..3315f1e 100644
> --- a/XI2proto.h
> +++ b/XI2proto.h
> @@ -92,10 +92,9 @@
>  #define X_XIDeleteProperty              58
>  #define X_XIGetProperty                 59
>  #define X_XIGetSelectedEvents           60
> -#define X_XIAllowTouchEvents            61
>  
>  /** Number of XI requests */
> -#define XI2REQUESTS (X_XIAllowTouchEvents - X_XIQueryPointer + 1)
> +#define XI2REQUESTS (X_XIGetSelectedEvents - X_XIQueryPointer + 1)
>  /** Number of XI2 events */
>  #define XI2EVENTS   (XI_LASTEVENT + 1)
>  
> @@ -648,8 +647,9 @@ typedef struct {
>      uint16_t    deviceid;
>      uint8_t     mode;
>      uint8_t     pad;
> +    uint32_t    touch_id;               /**< Since XI 2.2 */
>  } xXIAllowEventsReq;
> -#define sz_xXIAllowEventsReq                   12
> +#define sz_xXIAllowEventsReq                   16 /**< Was 12 before XI 2.2 */
>  
>  
>  /**
> @@ -799,20 +799,6 @@ typedef struct {
>  } xXIGetPropertyReply;
>  #define sz_xXIGetPropertyReply               32
>  
> -/**
> - * Accept or reject a grabbed touch sequence.
> - */
> -typedef struct {
> -    uint8_t     reqType;
> -    uint8_t     ReqType;        /**< Always ::X_XIAllowTouchEvents */
> -    uint16_t    length;         /**< Length in 4 byte units */
> -    uint32_t    touchid;
> -    uint16_t    deviceid;
> -    uint8_t     mode;           /**< bitmask */
> -    uint8_t     pad;
> -} xXIAllowTouchEventsReq;
> -#define sz_xXIAllowTouchEventsReq                   12
> -
>  /*************************************************************************************
>   *                                                                                   *
>   *                                      EVENTS                                       *
> diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
> index 3eea2f5..9bd586a 100644
> --- a/specs/XI2proto.txt
> +++ b/specs/XI2proto.txt
> @@ -360,9 +360,8 @@ Ownership of touch sequences
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  
>  Once a grabbing client becomes the owner of a touch, it must either “accept” or
> -"reject" the touch sequence using the
> -XIAllowTouchEvents request. If a touch sequence is
> -rejected, a TouchEnd event is sent to the rejecting client, and it will not
> +"reject" the touch sequence using the XIAllowEvents request. If a touch sequence
> +is rejected, a TouchEnd event is sent to the rejecting client, and it will not
>  receive any more events for this touch.  The server then looks to the next
>  window in the stack for another passive grab, and attempts to pass ownership
>  on to the next candidate for a passive grab (i.e. the next window towards
> @@ -1371,11 +1370,16 @@ active device grab becomes not viewable.
>              time:            TIMESTAMP or CurrentTime
>              event_mode:      { AsyncDevice, SyncDevice,
>                                 AsyncPairedDevice, SyncPairedDevice,
> -                               ReplayDevice, AsyncPair, SyncPair }
> +                               ReplayDevice, AsyncPair, SyncPair, AcceptTouch*,
> +                               RejectTouch* }
> +            touch_id*:       CARD32
>      └───
>  
> +* since XI 2.2
> +
>  The XIAllowEvents request releases some queued events if the client
> -has caused a device to freeze.
> +has caused a device to freeze. It also is used to handle touch grab and
> +ownership processing.
>  
>      deviceid
>          The device to grab.
> @@ -1383,12 +1387,19 @@ has caused a device to freeze.
>          A valid server time or CurrentTime.
>      event_mode
>          Specifies whether a device is to be thawed and events are to be
> -        replayed.
> +        replayed, or how to handle a grabbed touch sequence.
> +    touch_id
> +        The ID of the touch sequence to accept or reject. The value is undefined
> +        for event modes other than AcceptTouch and RejectTouch.
>  
>  The request has no effect if the specified time is earlier than the
>  last-grab time of the most recent active grab for the client, or if the
>  specified time is later than the current X server time.
>  
> +When event-mode is AcceptTouch or RejectTouch, a BadValue error occurs if the
> +touch ID is invalid. A BadAccess error occurs if this client is not the current
> +owner of the specified touch ID.
> +
>  The following describes the processing that occurs depending on what constant
>  you pass to the event-mode argument:
>  
> @@ -1458,6 +1469,14 @@ you pass to the event-mode argument:
>          thaws for both. AsyncPair has no effect unless both the device and the
>          paired master device frozen by the client.
>          AsyncPair has no effect if deviceid specifies a slave device.
> +     AcceptTouch
> +        The client is deemed to have taken control of the touch sequence.
> +        TouchEnd events will be sent to all other clients listening to the touch
> +        sequence, and they will no longer receive any TouchUpdate events.
> +     RejectTouch
> +        The client is no longer interested in the touch sequence, and will
> +        receive a TouchEnd event. Ownership will be passed on to the next
> +        listener.
>  
>  [[requests-passivegrabdevice]]
>      ┌───
> @@ -1600,7 +1619,7 @@ A GrabtypeEnter or GrabtypeFocusIn grab is released when the
>  pointer or focus leaves the window and all of its descendants,
>  independent of the state of modifier keys.
>  A GrabtypeTouchBegin grab is released when the touch sequence ends or
> -the client uses XIAllowTouchEvents with mode TouchReject.
> +the client uses XIAllowEvents with mode RejectTouch.
>  Note that the logical state of a device (as seen by means of the
>  protocol) may lag the physical state if device event processing is
>  frozen.
> @@ -1827,46 +1846,6 @@ delete is True and the bytes_after is zero, the property is also
>  deleted from the device, and a XIPropertyNotify event is generated on
>  the device.  
>       
> -[[requests-xi22]]
> -Requests introduced in version 2.2
> -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> -
> -[[requests-allowtouchevents]]
> -    ┌───
> -        XIAllowTouchEvents:
> -            deviceid:        DEVICEID
> -            touchid:         CARD32
> -            event_mode:      ALLOWTOUCHMODE
> -            flags:           SETofALLOWTOUCHFLAGS
> -    └───
> -
> -    ALLOWTOUCHMODE  { TouchAccept, TouchReject }
> -    ALLOWTOUCHFLAGS (none currently defined)
> -
> -The XIAllowTouchEvents request allows the current owner of a touch
> -sequence to direct further delivery.
> -
> -    deviceid
> -        The device ID for a grabbed touch sequence.
> -    touchid
> -        The ID of the touch sequence to modify.
> -    event_mode
> -        Given TouchAccept, the client is deemed to have taken control of the
> -        touch sequence; TouchEnd events will be sent to all other clients
> -        listening to the touch sequence, and they will no longer receive any
> -        TouchUpdate events.
> -        Given TouchReject, the client is no longer interested in the touch
> -        sequence, and will receive a TouchEnd event; ownership will be passed
> -        on to the next listener.
> -    flags
> -        A bitmask of applicable flags.
> -
> -A BadValue error occurs if the touch ID is invalid, or BadAccess if this
> -client is not the current owner of the specified touch ID.  BadValue errors
> -also occur if an invalid value is given for event_mode.  Any flags not
> -understood by the server will be ignored.
> -
> -
>  [[events]]
>  Events
>  ------
> @@ -2384,17 +2363,17 @@ require the client to announce XI 2.2 support in the XIQueryVersion request.
>     TouchUpdate event.  I may process the event to determine if it is going to
>     accept or reject the touch, whereas C may perform reversible processing.
>  ** If I decides it is going to claim the touch sequence for its exclusive
> -   processing, it calls XIAllowTouchEvents with the XITouchAccept flag set; at
> +   processing, it calls XIAllowEvents with an event mode of XIAcceptTouch; at
>     this point, C receives a TouchEnd event, and undoes any processing it has
>     already performed due to the touch sequence.  Further TouchUpdate events are
>     delivered only to I.
>  ** Alternatively, if I decides it does not want to receive further events
> -   from this touch sequence, it calls XIAllowTouchEvents with the XITouchReject
> -   flag set; at this point, I receives a TouchEnd event confirming that it has
> -   rejected the touch.  C receives a TouchOwnership event confirming that it is
> -   now the new owner of the touch, and further TouchUpdate events are delivered
> -   only to C.  As C now owns the touch, it is free to perform irreversible
> -   processing of the sequence.
> +   from this touch sequence, it calls XIAllowEvents with an event mode of
> +   XIRejectTouch; at this point, I receives a TouchEnd event confirming that it
> +   has rejected the touch.  C receives a TouchOwnership event confirming that it
> +   is now the new owner of the touch, and further TouchUpdate events are
> +   delivered only to C.  As C now owns the touch, it is free to perform
> +   irreversible processing of the sequence.
>  ** When the touch physically ceases, a TouchEnd event is sent to C.
>  
>  * Client C wants to pre-process touch events from a direct touch device D on
> -- 
> 1.7.4.1
> 
Cheers,
  Peter


More information about the xorg-devel mailing list