Merge branch 'multitouch-devel'

Conflicts:
	configure.ac
	specs/XI2proto.txt

1 files changed, 681 insertions, 97 deletions

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index f220557..0455ed3 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1,17 +1,28 @@
-The X Input Extension
-=====================
+The X Input Extension 2.x
+=========================
+:toc:
+:numbered:
 
-                                Version 2.0
-                                Version 2.1
+.This is a work in progress!
 
-                              Peter Hutterer
-                         peter.hutterer@redhat.com
-                               Red Hat, Inc.
+Authors:
 
+- Peter Hutterer (Red Hat) <peter.hutterer@redhat.com>
+- Daniel Stone (Collabora Ltd.) <daniel@fooishbar.org>
+- Chase Douglas (Canonical, Ltd.) <chase.douglas@canonical.com>
 
+[[history]]
+History 
+-------
 
-1. Introduction
----------------
+- v2.2, ??: Multitouch support added
+- v2.1, December 2011: new raw event behaviour, smooth scrolling support
+  added
+- v2.0, October 2009: Initial release of XI2 protocol
+
+[[intro-xi20]]
+Introduction
+------------
 
 The X Input Extension version 2.0 (XI2) is the second major release of the X
 Input Extension.
@@ -42,6 +53,44 @@ Changes introduced by version 2.1
 - RawEvents are sent regardless of the grab state.
 - Addition of the ScrollClass for smooth scrolling
 
+2.2 Changes
+-----------
+Changes introduced by version 2.2
+
+XI 2.2 introduces support for multi-touch devices. The traditional
+pointer/keyboard approach enforced by XI 2.0 with the master/slave device
+hierarchy is not always suitable for multi-touch devices that can provide a
+dynamic number of touchpoints per physical device; it is not known without
+client-specific interpretation whether the touchpoints must be considered
+separately or grouped together.
+
+The additions in XI 2.2 aim to:
+
+- support a dynamic number of simultaneous touch points,
+- support devices that are both multi-touch and traditional pointer devices,
+- allow touchpoints to be either grouped together or handled separately,
+- while supporting pre-XI 2.2 clients through emulation of XI 2.x/XI 1.x and core
+- be backwards-compatible to pre-XI 2.2 clients through emulation of XI 2.x/XI 1.x and core
+  pointer events.
+
+XI 2.2 caters for two modes of touch input devices:
+
+- 'Direct' multi-touch input devices such as touchscreens. These devices
+  provide independent touchpoints that can occur anywhere on the screen;
+  "direct" here refers to the user manipulating objects at their screen
+  location, e.g. touching an object and physically moving it.
+- 'Dependent' touch input devices such as multi-touch trackpads and mice with
+  additional touch surfaces. These devices provide independent touchpoints that
+  often need to be interpreted relative to the current position of the cursor
+  on that same device. Such interactions are usually the result of a gesture
+  performed on the device, rather than direct manipulation.
+
+Touch events are only available to clients supporting version 2.2 or later of
+the X Input Extension. Clients must use the XIQueryVersion request to announce
+support for this version. Touch devices may generate emulated pointer events
+alongside XI 2.2 touch events to support older clients; see Section
+<<multitouch-processing,Touch event delivery>>.
+
 //                            ❧❧❧❧❧❧❧❧❧❧❧
 
 2. Notations used in this document
@@ -85,8 +134,9 @@ There is little interaction between 1.x and 2.x versions of the X Input
 Extension. Clients are requested to avoid mixing XI1.x and XI2 code as much as
 possible. Several direct incompatibilities are observable:
 
-3.1 Limitations resulting from different variable ranges
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[interop-xi1-limitations]]
+Limitations resulting from different variable ranges
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 XI2 provides a larger range for some fields than XI1. As a result, XI1 clients
 may not receive data an XI2 client receives.
@@ -100,8 +150,9 @@ These fields include:
   will not receive events until the pixel boundary is crossed.
 
 
-3.2 Blocking of grabs
-~~~~~~~~~~~~~~~~~~~~~
+[[interop-xi1-grabs]]
+Blocking of grabs
+~~~~~~~~~~~~~~~~~
 
 XI1 grabs are different to XI2 grab and a device may not be grabbed through an
 XI2 grab if an XI1 grab is currently active on this device or vice versa.
@@ -109,13 +160,14 @@ Likewise, a keycode or button already grabbed by an XI 1.x or XI2 client may
 not be grabbed with the same modifier combination by an XI2 or XI 1.x client,
 respectively.
 
-3.3 Invisibility of Master Devices
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[interop-xi1-device-list]]
+Invisibility of Master Devices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-XI 1.x was not designed with support for multiple master devices (see Section
-4). As a result, only the first master pointer and master keyboard are visible
-to XI 1.x clients, all other master devices are invisible and cannot be
-accessed from XI 1.x calls.
+XI 1.x was not designed with support for multiple master devices. As a
+result, only the first master pointer and master keyboard are visible to XI
+1.x clients; all other master devices are invisible and cannot be accessed
+from XI 1.x calls.
 
 3.4 Smooth scrolling
 ~~~~~~~~~~~~~~~~~~~~
@@ -156,14 +208,16 @@ marked Preferred or more than one valuator is marked with Preferred for this
 scroll direction, this should be considered a driver bug and the behaviour
 is implementation-dependent.
 
-4. The Master/Slave device hierarchy
-------------------------------------
+[[hierachy]]
+The Master/Slave device hierarchy
+---------------------------------
 
 XI2 introduces a device hierarchy split up into so-called Master Devices (MD)
 and Slave Devices (SD).
 
-4.1 Master devices
-~~~~~~~~~~~~~~~~~~
+[[hierachy-master]]
+Master devices
+~~~~~~~~~~~~~~
 An MD is a virtual device created and managed by the server. MDs may send core
 events and XI events. However, an MD does not represent a physical device and
 relies on SDs for event generation. MDs come in two forms: as master pointers
@@ -175,8 +229,9 @@ versa, and this pairing is constant for the lifetime of both input devices.
 Clients can use this pairing behaviour to implement input paradigms that
 require pointer and keyboard interation (e.g. SHIFT + Click).
 
-4.2 Slave devices
-~~~~~~~~~~~~~~~~~
+[[hierachy-slave]]
+Slave devices
+~~~~~~~~~~~~~
 An SD is usually a physical device configured in the server. SDs are not
 represented by a cursor or keyboard focus and may be attached to a master
 pointer or master keyboard. SDs can only be attached to any master of the same
@@ -194,8 +249,9 @@ If an event is generated by an SD
   Both the sprite and the focus must be managed explicitly by the client
   program.
 
-4.3 Event processing for attached slave devices
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[hierachy-dcce]]
+Event processing for attached slave devices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Whenever an SD changes its logical state,
 
@@ -214,8 +270,9 @@ to P is only attempted if neither the XI event, nor the core event has been
 delivered on W. Once an event has been delivered as either XI or core event,
 event processing stops.
 
-4.4. The ClientPointer principle
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[clientpointer]]
+The ClientPointer principle
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Many core protocol and some extension requests are ambiguous when multiple
 master devices are available (e.g. QueryPointer does not specify which pointer).
@@ -235,10 +292,253 @@ If the master pointer currently set as ClientPointer for one or more clients is
 removed, the server may either unset the ClientPointer setting or change the
 ClientPointer to a different master pointer.
 
-//                            ❧❧❧❧❧❧❧❧❧❧❧
+[[multitouch]]
+Touch device support
+--------------------
+
+Touch event processing differs from normal event processing in a few ways.
+The most notable differences are that touch events are processed partially
+out-of-band from pointer and keyboard events, and that touch events may be
+sent to multiple clients simultaneously. For more details see Section
+<<multitouch-processing, Touch event delivery>>.
+
+[[multitouch-lifecycle]]
+Touch event sequences
+~~~~~~~~~~~~~~~~~~~~~
+
+Touch input follows a three-stage cycle:
+
+        begin - update - update - ... - end
+
+i.e. “begin” the sequence by touching the device, “update” the current
+touch location or properties any number of times, and finally “end” the
+sequence by ceasing to touch the device.  Within this document, the term
+"touch sequence" is used to describe the above sequence of events.
+In the protocol, the three stages are represented with the event
+types TouchBegin, TouchUpdate, and TouchEnd, respectively. A touch sequence
+always generates TouchBegin and TouchEnd events, and may also generate
+TouchUpdate events.  Clients must select for all three of these events
+simultaneously.
+
+When a touch starts, clients are sent a TouchBegin event
+detailing the position of the touchpoint, as well as the
+initial properties of the touchpoint.  Note that the logical state of the
+device (as seen through the input protocol) may lag the physical state if event
+processing is affected by grabs.  Multiple touchpoints may be active on the
+same device at any time, potentially owned by and/or delivered to a different
+set of clients.
+
+Whenever the touch position or any other property of the touchpoint changes,
+a TouchUpdate event is sent to all clients listening
+to events for that touchpoint with the updated information.
+
+When the touch has physically ended, or a client will otherwise not receive
+any more events for a given touchpoint, a TouchEnd event will be sent to
+that client.
+
+Passive touch grabs are similar to standard input event grabs in that they
+take precedence over event selections and are searched from the root window
+to the child window (as opposed to selections, which start their search at the
+child window and continue up to the root window).  When a touch grab activates,
+the client whose grab activates becomes the “owner” of this touch sequence,
+and must decide what to do with it, as per Section
+<<multitouch-ownership,Ownership of touch sequences>>.  See the
+<<requests-passivegrabdevice,XIPassiveGrabDevice>> request
+documentation for more information on passive grab activation.
+
+Only one client may select for touch events from a given device on a window.
+
+[[multitouch-ownership]]
+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 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
+the final child window with a matching grab), or to the first applicable
+event selection if there are no more grabs.
+
+If a touch sequence is accepted by its owner, all other clients receive
+TouchEnd events, and the touch sequence is exclusively delivered to the
+owner from that point on.
+
+If the touch sequence physically ends while the owner of the touch sequence
+has not yet accepted or rejected ownership, all clients receive a
+TouchUpdate event with the TouchPendingEnd flag set. The owner must still
+accept or reject the sequence nonetheless. If the owner rejects the touch
+sequence, the server will still attempt to exhaust all other passive grabs
+and/or event selections looking for a final owner.
+
+Clients may opt for touch events to be delivered before they become the
+owner of the touch sequence. In this case, the logical state of the device (as
+seen by means of the protocol) always matches the physical state of the device.
+Clients must use caution if they opt for this feature; any action taken must be
+undone if the touch sequence ends without the client becoming the owner.
+
+To select for touch events regardless of ownership, a client must set the
+TouchOwnership event mask in addition to the
+TouchBegin, TouchUpdate and TouchEnd mask. When selected, a client will receive
+touch events as they occur on the device without delay. If and when the client
+becomes the owner of a touch sequence, a TouchOwnership event is sent to the
+client. If the client is the initial owner of the sequence, the TouchBegin is
+immediately followed by the TouchOwnership event. Otherwise, TouchUpdate events
+may preceed a TouchOwnership event. A client is not guaranteed to become the
+owner of any given touch sequence.
+
+The server delivers touch events to all clients that have selected for
+TouchOwnership and to the current owner of the sequence in parallel.
+
+If a client has selected for TouchOwnership and is not the current owner of
+the sequence and the current owner accepts the sequence, the client receives
+a TouchEnd event and no further events from this sequence are sent to this
+client.
+
+If a client has selected for TouchOwnership and the physical touch ends
+before the current owner has accepted or rejected the sequence, the client
+receives a TouchUpdate event with the TouchPendingEnd flag set. No further
+TouchUpdate events will be sent for this sequence. If the current owner
+accepts the sequence, the client receives a TouchEnd event. Otherwise, if
+the current owner rejects the sequence, the client may become 
+the owner of the touch sequence and receive a TouchOwnership event and a
+TouchEnd event.
+
+[[multitouch-device-modes]]
+Touch device modes
+~~~~~~~~~~~~~~~~~~
+
+Touch devices come in many different forms with varying capabilities. The
+following device modes are defined for this protocol:
+
+'DirectTouch':
+    These devices map their input region to a subset of the screen region. Touch
+    events are delivered to window at the location of the touch. An example
+    of a DirectTouch device is a touchscreen.
+
+'DependentTouch':
+    These devices do not have a direct correlation between a touch location and
+    a position on the screen. Touch events are delivered according to the
+    location of the device's cursor. An Example of a DependentTouch device is a
+    trackpad.
+
+A device is identified as only one of the device modes above at any time, and
+the touch mode may change at any time. If a device's touch mode changes, an
+XIDeviceChangedEvent is generated.
+
+[[multitouch-processing]]
+Touch event delivery
+~~~~~~~~~~~~~~~~~~~~
+
+For direct touch devices, the window set for event propagation is the set of
+windows from the root window to the topmost window lying at the co-ordinates
+of the touch.
+
+For dependent devices, the window set for event propagation is the set of
+windows from the root window to the window that contains the device's
+pointer. A dependent device may only have one window set at a time, for all
+touches. Any future touch sequence will use the same window set. The window set
+is cleared when all touch sequences on the device end.
+
+A window set is calculated on TouchBegin and remains constant until the end
+of the sequence. Modifications to the window hierarchy, new grabs or changed
+event selection do not affect the window set.
+
+
+[[multitouch-emulation]]
+Pointer emulation from multitouch events
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Touch sequences from direct touch devices may emulate pointer events. Only one
+touch sequence from a device may emulate pointer events at a time; which touch
+sequence emulates pointer events is implementation dependent.
+
+Pointer events are emulated as follows:
+
+- A TouchBegin event generates a pointer motion event to the location of the
+  touch with the same axis values of the touch event, followed by a button press
+  event for button 1.
+- A TouchUpdate event generates a pointer motion event to the location of the
+  touch and/or to update axis values of the pointer device. The button state
+  as seen from the protocol includes button 1 set.
+- A TouchEnd event generates a pointer motion event to the location of the touch
+  and/or to update the axis values if either have changed, followed by a button
+  release event for button 1. The button state as seen from the protocol
+  includes button 1 set.
+
+If a touch sequence emulates pointer events and an emulated pointer event
+triggers the activation of a passive grab, the grabbing client becomes the
+owner of the touch sequence.
+
+The touch sequence is considered to have been accepted if
+
+- the grab mode is asynchronous, or
+- the grab mode is synchronous and the device is thawed as a result of
+  AllowEvents with AsyncPointer or AsyncDevice
+
+Otherwise, if the button press is replayed by the client, the touch sequence
+is considered to be rejected.
+
+Touch event delivery precedes pointer event delivery. A touch event emulating
+pointer events is delivered:
+
+- as a touch event to the top-most window of the current window set if a
+  client has a touch grab on this window,
+- otherwise, as a pointer event to the top-most window of the current window
+  set if a client has a pointer grab on this window,
+- otherwise, to the next child window in the window set until a grab has been
+  found.
+
+If no touch or pointer grab on any window is active and the last window in the
+window set has been reached, the event is delivered:
+
+- as a touch event to the window if a client has selected for touch events
+  on this window
+- otherwise, as a pointer event to the window if a client has selected for
+  pointer events.
+- otherwise, to the next parent window in the window set until a selection has
+  been found.
 
-5. Data types
--------------
+Emulated pointer events will have the PointerEmulated flag set.
+
+[[glossary-notations]]
+Notations used in this document
+-------------------------------
+
+Notation for requests:
+
+    ┌───
+        Name of request
+            name of request field:       type of request field
+            name of request field:       type of request field
+            ▶
+            name of reply field:         type of reply field
+    └───
+
+Notation for events:
+
+    ┌───
+        Name of event
+            name of field:               type of field
+            name of field:               type of field
+    └───
+
+Complex fields are specified in the following notation:
+
+          name of field:                  COMPLEXFIELDTYPE
+
+or, if multiple of these fields exist:
+
+          name of field:                  LISTofCOMPLEXFIELDTYPE
+
+    COMPLEXFIELDTYPE:  { name of subfield:   type of subfield,
+                         name of subfield:   type of subfield }
+
+
+[[glossary-datatypes]]
+Data types
+----------
 
     BUTTONMASK
             A binary mask defined as (1 << button number).
@@ -278,20 +578,20 @@ ClientPointer to a different master pointer.
             A binary mask defined as (1 << valuator number).
             A SETofVALUATORMASK is a binary OR of zero or more VALUATORMASK.
 
-//                            ❧❧❧❧❧❧❧❧❧❧❧
 
-6. Errors
----------
+[[errors]]
+Errors
+------
 
 Errors are sent using core X error reports.
 
     Device
             A value for a DEVICE argument does not specify a valid DEVICE.
 
-//                            ❧❧❧❧❧❧❧❧❧❧❧
 
-7. Requests:
-------------
+[[requests]]
+Requests:
+---------
 
 The server does not guarantee that the length of a reply remains constant in
 future revisions of XI2. A client must always retrieve the exact length of the
@@ -301,9 +601,11 @@ Additional bytes in a request may include data supported in later versions of
 XI2. Clients should ignore this data. Padding bytes in XI2 protocol requests
 are required to be 0.
 
-7.1 Requests introduced in version 2.0
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[requests-xi20]]
+Requests introduced in version 2.0
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+[[requests-queryversion]]
     ┌───
         XIQueryVersion
         major_version:          CARD16
@@ -327,6 +629,7 @@ server supports a version which is compatible with its expectations.
 
 If major_version is less than 2, a BadValue error occurs.
 
+[[requests-querydevice]]
     ┌───
         XIQueryDevice
         DEVICE                  deviceid
@@ -344,7 +647,7 @@ If major_version is less than 2, a BadValue error occurs.
                  name:                  LISTofCHAR8
                  classes:               LISTofCLASS }
 
-    CLASS { BUTTONCLASS, KEYCLASS, AXISCLASS, SCROLLCLASS }
+    CLASS { BUTTONCLASS, KEYCLASS, AXISCLASS, SCROLLCLASS, TOUCHCLASS }
 
     BUTTONCLASS { type:                 ButtonClass
                   length:               CARD16
@@ -378,12 +681,23 @@ If major_version is less than 2, a BadValue error occurs.
                   flags:                SETofSCROLLFLAGS
                   increment:            FP3232 }
 
-    * since XI 2.1
-
     SCROLLTYPE { Vertical, Horizontal }
 
     SCROLLFLAGS { NoEmulation, Preferred }
 
+    TOUCHCLASS† { type:                 TouchClass
+                  length:               CARD16
+                  sourceid:             CARD16
+                  mode:                 TOUCHMODE
+                  num_touches:          CARD16
+                  num_props:            CARD16
+                  props:                LISTofATOM }
+
+    TOUCHMODE { DirectTouch, DependentTouch }
+
+    * since XI 2.1
+    † since XI 2.2
+
 XIQueryDevice details information about the requested input devices.
 
     devices
@@ -489,10 +803,6 @@ client. If no min and max information is available, both must be 0.
     ScrollClass:
     type
         Always ScrollClass.
-    length
-        Length in 4 byte units.
-    sourceid
-        The device this class originates from.
     axisnumber
         Axis number that is referred to. This axis number must be listed in
         the ValuatorClassInfo.
@@ -512,6 +822,28 @@ A ScrollClass may only exist if the device has at least one ValuatorClass
 and each axisnumber listed in any ScrollClass. Only one ScrollClass may
 exist per ValuatorClass.
 
+    TouchClass:
+    type
+        Always TouchClass.
+    length
+        Length in 4 byte units.
+    sourceid
+        The device this class originates from.
+    mode
+        The device type of the touch device.  This mode may change at runtime.
+    num_touches
+        The maximum number of simultaneous touchpoints the device may send.
+        If num_touches is 0, the number of supported touches is unknown or
+        unlimited.
+    num_props:
+        The number of elements in props.
+    props
+        A list of properties to denote extra information about the device.
+
+Devices with a TouchClass emit touch events with the same axes as pointer
+events.
+
+[[requests-selectevents]]
     ┌───
         XISelectEvents
             window:         Window
@@ -554,6 +886,15 @@ If mask_len is 0, the event mask for the given device is cleared.
 The mask for XIHierarchyEvents may only be selected for XIAllDevices.
 Setting it for any other device results in a BadValue error.
 
+A client selecting for any of XI_TouchBegin, XI_TouchUpdate, or XI_TouchEnd
+must select for all three events at the same time, else a BadValue error
+will be generated. A client selecting for XI_TouchOwnership must select for
+all three of the other touch events. If the selection for these touch events
+overlaps a current selection by another client (e.g. selecting for a
+specific device when another client has a selection for XIAllDevices), a
+BadAccess error occurs.
+
+[[requests-getselectedevents]]
     ┌───
         XIGetSelectedEvents
             window:         Window
@@ -577,6 +918,7 @@ AllMasterDevices and the device-specific mask.
 If num_masks is 0, no events have been selected by this client on the
 given window.
 
+[[requests-querypointer]]
     ┌───
         XIQueryPointer
             window:         Window
@@ -621,6 +963,7 @@ Query a master pointer device for its current position.
 If the device is not a master pointer device or not a floating slave
 pointer, a BadDevice error results.
 
+[[requests-warppointer]]
     ┌───
         XIWarpPointer
             src_win:         Window
@@ -666,6 +1009,7 @@ far as the closest edge of the confine-to window.
 This request will generate events just as if the user had instantaneously
 moved the pointer.
 
+[[requests-changecursor]]
     ┌───
         XIChangeCursor
             win:             Window
@@ -697,6 +1041,7 @@ or the device is removed, whichever comes earlier.
 If deviceid does not specify a master pointer, a BadDevice error
 is returned.
 
+[[requests-changehierachy]]
     ┌───
         XIChangeHierarchy
             num_changes:     CARD8
@@ -732,8 +1077,8 @@ is returned.
                   length:     CARD16
                   deviceid:   DEVICEID }
 
-XIChangeHierarchy allows a client to modify the MD/SD device
-hierarchy (see Section 4).
+XIChangeHierarchy allows a client to modify the
+<<hierachy,Master/Slave device hierarchy>>.
 
     num_changes
         The number of changes to apply to the current hierarchy.
@@ -793,6 +1138,9 @@ versa.
     master
         The new master device to attach this slave device to.
 
+If any clients are selecting for touch events from the slave device, their
+selection will be canceled.
+
     DETACHSLAVE detaches a slave device from its current master device.
     type
         Always ChangeAttachment.
@@ -801,6 +1149,7 @@ versa.
     deviceid
         Deviceid of the slave device.
 
+[[requests-setclientpointer]]
     ┌───
         XISetClientPointer
             win:             Window
@@ -832,6 +1181,7 @@ BadDevice error is returned.
 If window does not specify a valid window or client ID and is not None, a
 BadWindow error is returned.
 
+[[requests-getclientpointer]]
     ┌───
         XIGetClientPointer
             win:             Window
@@ -853,6 +1203,7 @@ No difference is made between a ClientPointer set explicitly through
 XISetClientPointer and a ClientPointer implicitly assigned by the server
 in response to an ambiguous request.
 
+[[requests-setfocus]]
     ┌───
         XISetFocus
             focus:           Window
@@ -883,6 +1234,7 @@ This request has no effect if the specified time is earlier than the
 current last-focus-change time or is later than the current X server time.
 Otherwise, the last-focus-change time is set to the specified time.
 
+[[requests-getfocus]]
     ┌───
         XIGetFocus
             deviceid:        DEVICEID
@@ -892,6 +1244,7 @@ Otherwise, the last-focus-change time is set to the specified time.
 
 Return the current focus window for the given device.
 
+[[requests-grabdevice]]
     ┌───
         XIGrabDevice
             deviceid:        DEVICEID
@@ -910,7 +1263,8 @@ Return the current focus window for the given device.
 This request actively grabs control of the specified input device. Further
 input events from this device are reported only to the grabbing client.
 This request overides any previous active grab by this client for this
-device.
+device.  This request does not, however, affect the processing of XI 2.2
+touch events.
 
     deviceid
         The device to grab.
@@ -981,6 +1335,7 @@ This request fails and returns:
 
 To release a grab of a device, use XIUngrabDevice.
 
+[[requests-ungrabdevice]]
     ┌───
         XIUngrabDevice
             deviceid:        DEVICEID
@@ -1003,17 +1358,24 @@ This request generates FocusIn and FocusOut events.
 An XIUngrabDevice is performed automatically if the event window for an
 active device grab becomes not viewable.
 
+[[requests-allowevents]]
     ┌───
         XIAllowEvents:
             deviceid:        DEVICEID
             time:            TIMESTAMP or CurrentTime
             event_mode:      { AsyncDevice, SyncDevice,
                                AsyncPairedDevice, SyncPairedDevice,
-                               ReplayDevice, AsyncPair, SyncPair }
+                               ReplayDevice, AsyncPair, SyncPair, AcceptTouch*,
+                               RejectTouch* }
+            touchid*:        CARD32
+            grab_window*:    Window
     └───
 
+* 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.
@@ -1021,11 +1383,22 @@ 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.
+    touchid
+        The ID of the touch sequence to accept or reject. The value is undefined
+        for event modes other than AcceptTouch and RejectTouch.
+    grab_window
+        The window on which to accept or reject a touch sequence grab. 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.
+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. The time parameter must be CurrentTime for
+requests with event modes of AcceptTouch and RejectTouch.
+
+When event-mode is AcceptTouch, a BadValue error occurs if the touch ID is
+invalid. A BadAccess error occurs if this client is not the current or potential
+owner of the specified touch ID.
 
 The following describes the processing that occurs depending on what constant
 you pass to the event-mode argument:
@@ -1096,7 +1469,19 @@ 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 once it
+        owns the sequence. TouchEnd events will be sent to all clients listening
+        to the touch sequence that have either grabbed the touch sequence on a
+        child window of the grab_window or have received events for the touch
+        sequence through event selection. These clients will no longer receive
+        any TouchUpdate events.
+     RejectTouch
+        The client is no longer interested in the touch sequence, and will
+        receive a TouchEnd event. If the client is the current owner of the
+        sequence, ownership will be passed on to the next listener.
+
+[[requests-passivegrabdevice]]
     ┌───
         XIPassiveGrabDevice
             deviceid:        DEVICE
@@ -1105,7 +1490,7 @@ you pass to the event-mode argument:
             grab_window:     Window
             cursor:          Cursor
             owner_events:    Bool
-            grab_mode:       { Synchronous, Asynchronous }
+            grab_mode:       { Synchronous, Asynchronous, Touch* }
             paired_device_mode: { Synchronous, Asynchronous }
             num_modifiers:   INT16
             mask_len:        CARD16
@@ -1117,11 +1502,13 @@ you pass to the event-mode argument:
     └───
 
         GRABTYPE         { GrabtypeButton, GrabtypeKeycode, GrabtypeEnter,
-                           GrabtypeFocusIn}
+                           GrabtypeFocusIn, GrabtypeTouchBegin }
 
         GRABMODIFIERINFO {   status:    Access
                              modifiers: CARD32 }
 
+* since XI 2.2
+
 Establish an explicit passive grab for a button or keycode
 on the specified input device.
 
@@ -1133,7 +1520,8 @@ on the specified input device.
             AllMasterDevices.
         detail
             The button number, or key symbol to grab for.
-            Must be 0 for GrabtypeEnter and GrabtypeFocusIn.
+            Must be 0 for GrabtypeEnter, GrabtypeFocusIn, and
+            GrabtypeTouchBegin.
         grab_type
             The type of grab to establish.
         grab_window
@@ -1147,7 +1535,8 @@ on the specified input device.
             generated by the server until the grabbing client issues a
             releasing XIAllowEvents request or until the device grab is
             released. Actual device input events are not lost while the device
-            is frozen; they are simply queued for later processing.
+            is frozen; they are simply queued for later processing. If grab_type
+            is GrabtypeTouchBegin, grab_mode must be set to Touch.
         mask_len
             Length of mask in 4 byte units.
         mask
@@ -1203,10 +1592,25 @@ device is actively grabbed if:
         - the grab_type is GrabtypeEnter and the device's pointer has moved
           into grab_window or a descendant of grab_window, or the grab_type is
           GrabtypeFocusIn and the device's focus has been set to the
-          grab_window or a descendant of grab_window,
+          grab_window or a descendant of grab_window, and
         - a passive grab of the same grab_type + modifier combination does not
           does not exist on an ancestor of grab_window.
 
+Otherwise, if grab_type is GrabtypeTouchBegin, a touch grab begins if:
+
+        - the device is not actively grabbed, and
+        - the specified modifier keys are down
+        - a touch begins in grab_window or a descendant of grab_window, and
+        - a passive grab of the same grab_type + modifier combination does not
+          does not exist on an ancestor of grab_window.
+
+Ownership of the touch sequence is granted to the grabbing client if:
+
+        - a TouchBegin or pointer grab for an emulated touch sequence of a
+          direct touch device with the same modifier set does not exist on
+          an ancestor of grab_window, or all applicable grabs have released
+          ownership.
+
 A modifier of GrabAnyModifier is equivalent to issuing the request for
 all possible modifier combinations (including no modifiers). A client
 may request a grab for GrabAnyModifier and explicit modifier
@@ -1217,6 +1621,8 @@ or keycode are released, independent of the state of modifier keys.
 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 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.
@@ -1229,10 +1635,11 @@ If some other client already has issued a XIPassiveGrabDevice request
 with the same button or keycode and modifier combination, the
 failed modifier combinations is returned in modifiers_return. If some
 other client already has issued an XIPassiveGrabDevice request of
-grab_type  XIGrabtypeEnter or XIGrabtypeFocusIn with the same
-grab_window and the same modifier combination, the failed modifier
-combinations are returned in modifiers_return. If num_modifiers_return
-is zero, all passive grabs have been successful.
+grab_type XIGrabtypeEnter, XIGrabtypeFocusIn, XIGrabtypeTouchBegin, or
+XIGrabtypeTouchBeginInert with the same grab_window and the same
+modifier combination, the failed modifier combinations are returned
+in modifiers_return. If num_modifiers_return is zero, all passive
+grabs have been successful.
 
 If a button grab or enter grab activates, EnterNotify and LeaveNotify
 events with mode Grab are generated as if the pointer were to suddenly
@@ -1253,6 +1660,15 @@ grab deactivates, addional LeaveNotify events with mode
 XIPassiveUngrabNotify are generated and sent to the grabbing client
 before the grab deactivates.
 
+For GrabtypeTouchBegin, grab_mode must be Touch or a BadValue error
+is generated.
+
+See section 4.4 for additional notes on touch grabs, as they do not
+behave like traditional grabs: in particular, they do not freeze the
+device, and delivery of touch events continues even if the device is
+frozen due to a grab by another client.
+
+[[requests-passiveungrabdevice]]
     ┌───
         XIPassiveUngrabDevice
             deviceid:        DEVICEID
@@ -1269,7 +1685,8 @@ Release an explicit passive grab on the specified input device.
             The device to establish the passive grab on.
         detail
             The button number or key symbol to ungrab.
-            Must be 0 for GrabtypeEnter and GrabtypeFocusIn.
+            Must be 0 for GrabtypeEnter, GrabtypeFocusIn, and
+            GrabtypeTouchBegin.
         grab_type
             The type of grab to establish.
         grab_window
@@ -1283,6 +1700,7 @@ This request has no effect if the client does not have a passive grab
 of the same type, same button or keycode (if applicable) and modifier
 combination on the grab_window.
 
+[[requests-listproperties]]
     ┌───
         XIListProperties
             deviceid:        DEVICEID
@@ -1300,6 +1718,7 @@ List the properties associated with the given device.
         atoms
             All properties on the device.
 
+[[requests-changeproperty]]
     ┌───
         XIChangeProperty
             deviceid:        DEVICEID
@@ -1347,6 +1766,7 @@ property, use XIDeleteProperty.
 
 This request generates an XIPropertyEvent.
 
+[[requests-deleteproperty]]
     ┌───
         XIDeleteProperty
             deviceid:        DEVICEID
@@ -1363,6 +1783,7 @@ Deletes the given property on the given device.
 If the property is deleted, an XIPropertyEvent is generated on the device.
 If the property does not exist, this request does nothing.
 
+[[requests-getproperty]]
     ┌───
         XIGetProperty
             deviceid:        DEVICEID
@@ -1414,25 +1835,23 @@ either AnyPropertyType is specified or the specified type matches the actual
 type of the property, then the return type is the actual type of the property,
 the format is the actual format of the property
 (never zero), and the bytes-after and value are as follows, given:
-
          N = actual length of the stored property in bytes
             (even if the format is 16 or 32)
          I = 4 * long-offset
          T = N−I
          L = MINIMUM(T, 4 * long-length)
          A = N − (I + L)
-
 The returned value starts at byte index I in the property (indexing
 from 0), and its length in bytes is L. However, it is a Value error if
 offset is given such that L is negative. The value of bytes_after is A,
 giving the number of trailing unread bytes in the stored property. If
 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.
-
-
-8. Events:
-----------
+the device.  
+     
+[[events]]
+Events
+------
 
 An event specifies its length in 4-byte units after the initial 32 bytes.
 Future versions of the protocol may provide additional information
@@ -1444,23 +1863,34 @@ event they may have been compiled against.
 The following event types are available in XI2.
 
 Version 2.0:
-        HierarchyChanged
-        DeviceChanged
-        KeyPress
-        KeyRelease
-        ButtonPress
-        ButtonRelease
-        Motion
-        RawKeyPress
-        RawKeyRelease
-        RawButtonPress
-        RawButtonRelease
-        RawMotion
-        Enter
-        Leave
-        FocusIn
-        FocusOut
-        PropertyEvent
+
+        - HierarchyChanged
+        - DeviceChanged
+        - KeyPress
+        - KeyRelease
+        - ButtonPress
+        - ButtonRelease
+        - Motion
+        - RawKeyPress
+        - RawKeyRelease
+        - RawButtonPress
+        - RawButtonRelease
+        - RawMotion
+        - Enter
+        - Leave
+        - FocusIn
+        - FocusOut
+        - PropertyEvent
+
+Version 2.2:
+
+        - TouchBegin
+        - TouchUpdate
+        - TouchOwnership
+        - TouchEnd
+        - RawTouchBegin
+        - RawTouchUpdate
+        - RawTouchEnd
 
 All events have a set of common fields specified as EVENTHEADER.
 
@@ -1486,9 +1916,14 @@ All events have a set of common fields specified as EVENTHEADER.
     deviceid
         Numerical device id for a device.
     time
-        Time in ms.
+        Time in ms when the event occurred.
 
 
+[[events-xi20]]
+Events introduced in version 2.0
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+[[events-hierachyevent]]
     ┌───
         HierarchyEvent:
             EVENTHEADER
@@ -1536,6 +1971,7 @@ Note: Multiple devices may be affected in one hierarchy change,
 deviceid in an XIHierarchyEvent is always the first affected
 device. Clients should ignore deviceid and instead use the devices list.
 
+[[events-devicechangedevent]]
     ┌───
         DeviceChangedEvent:
             EVENTHEADER
@@ -1569,6 +2005,7 @@ master device, or by a physical device changing capabilities at runtime.
 
 For a detailed description of classes, see the XIQueryDevice request.
 
+[[events-deviceevent]]
     ┌───
         DeviceEvent:
             EVENTHEADER
@@ -1605,15 +2042,18 @@ For a detailed description of classes, see the XIQueryDevice request.
 
     DEVICEEVENTFLAGS (all events): none
     DEVICEEVENTFLAGS (key events only): { KeyRepeat }
-    DEVICEEVENTFLAGS (pointer events only): { PointerEmulated }
+    DEVICEEVENTFLAGS (pointer and touch events only): { PointerEmulated }
+    DEVICEEVENTFLAGS (touch events only): { TouchPendingEnd }
 
 An XIDeviceEvent is generated whenever the logical state of a device
 changes in response to a button press, a button release, a motion, a key
 press or a key release. The event type may be one of KeyPress,
 KeyRelease, ButtonPress, ButtonRelease, Motion.
 
+    XI 2.2: The event type may also be TouchBegin, TouchUpdate, or TouchEnd.
+
     detail
-        The button number or key code, or 0.
+        The button number, key code, touch ID, or 0.
     root
     event
     child
@@ -1655,7 +2095,17 @@ KeyRelease, ButtonPress, ButtonRelease, Motion.
         be ignored if the client listens for these events.  This flag is
         set on scroll ButtonPress and RawButtonPress events (buttons 4, 5, 6
         and 7) if a smooth-scrolling event on the Rel Vert Scroll or
-        Rel Horiz Scroll axes was also generated.
+        Rel Horiz Scroll axes was also generated. It is also set on Motion,
+        ButtonPress, and ButtonRelease events generated by direct touch devices.
+        TouchAccepted (for TouchEnd events only) means that the current owner
+        of the touch stream has “accepted” it, and this client will not receive
+        any further events from that touch sequence.
+        TouchPendingEnd (for touch events only) means that the touch
+        has physically ended, however another client still holds a grab, so the
+        touch should be considered alive until all grabbing clients have
+        accepted or passed on ownership.  The touch will not generate any
+        further TouchUpdate events once an event with TouchPendingEnd has been
+        received.
 
 Modifier state in mods is detailed as follows:
 
@@ -1674,6 +2124,33 @@ Modifier state in mods is detailed as follows:
     locked_group
         XKB locked group state.
 
+    XI 2.2:
+
+A TouchBegin event is generated whenever a new touch sequence initializes
+A TouchEnd event is generated whenever a touch sequence ceases. A
+TouchUpdate event is generated whenever a valuator value changes, or a flag
+flag (e.g. pending end) has changed for that touch sequence; this may result
+in a TouchUpdate event being sent with zero valuators. A TouchOwnership event
+is sent when a client becomes the owner of a touch.
+
+The average finger size is significantly larger than one pixel. The
+selection of the hotspot of a touchpoint is implementation dependent and
+may not be the logical center of the touch.
+
+Touch tracking IDs are provided in the detail field of touch events. Its
+value is always provided in every touch event. Tracking IDs are
+represented as unsigned 32-bit values and increase strictly monotonically in
+value for each new touch, wrapping back to 0 upon reaching the numerical limit
+of IDs. The increment between two touch IDs is indeterminate. Clients may not
+assume that any future touches will have specific touch IDs. IDs are globally
+unique.
+
+The button state in touch events represents the state of the device's
+physical buttons only, even if that sequence is emulating pointer events.
+
+Touch events do not generate enter/leave events.
+
+[[events-rawevent]]
     ┌───
         RawEvent
             EVENTHEADER
@@ -1705,7 +2182,7 @@ when the device is grabbed by another client.
     eventtype
         The type of event that occured on the device.
     detail
-        The button number or keycode.
+        The button number, keycode or touch ID*.
     sourceid
         The source device that originally generated the event. The sourceid
         is undefined for clients not supporting XI 2.1.
@@ -1720,6 +2197,9 @@ when the device is grabbed by another client.
     axisvalues_raw
         Untransformed valuator data in device-native resolution.
 
+* since XI 2.2
+
+[[events-enterleave]]
     ┌───
         Enter or Leave or FocusIn or FocusOut
             EVENTHEADER
@@ -1800,6 +2280,7 @@ zero if the device is a floating slave device.
     buttons
         Button state before the event.
 
+[[events-propertyevent]]
     ┌───
         XIPropertyEvent
             EVENTHEADER
@@ -1814,6 +2295,109 @@ modified by a client.
         The property that has been created, deleted, or modified
     what
         Specifies what has been changed.
+     
+[[events-xi22]]
+Events introduced in version 2.2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+[[events-touchownershipevent]]
+    ┌───
+        TouchOwnershipEvent (since XI 2.2):
+            EVENTHEADER
+            touchid:                    CARD32
+            root:                       Window
+            event:                      Window
+            child:                      Window
+            sourceid:                   DEVICEID
+            flags:                      SETofTOUCHOWNERSHIPFLAGS
+    └───
 
-//                            ❧❧❧❧❧❧❧❧❧❧❧
+    TOUCHOWNERSHIPFLAGS:    (none currently defined)
+
+A TouchOwnershipEvent indicates that ownership has changed, and the client
+is now the owner of the touch sequence specified by touchid.
+
+    touchid
+        The identifier of the touch sequence.
+    root
+    event
+    child
+        The root window, event window, and child window, respectively. See the
+        core protocol specification for more detail.
+    sourceid
+        The source device that originally generated the event.
+    flags
+        A bitmask of flags for this event.
+
+
+// FIXME: why do we get '11. Appendix A:' rather than just 'Appendix A:'?!
+[[xi22-usecases]]
+[appendix]
+XI 2.2 Use-cases
+----------------
+
+All use-cases that include the receiving and processing of touch events
+require the client to announce XI 2.2 support in the XIQueryVersion request.
+
+* Client C wants to process touch events from a device D on window W.
+** C calls XISelectEvent for XI_Touch{Begin|Update|End} from D on W.
+** C receives TouchBegin whenever a touch sequence starts within W's borders.
+** C receives TouchUpdate events whenever an axis valuator value changes for a
+   touch sequence it received a TouchBegin event for.
+** C receives TouchEnd whenever a touch it received a TouchBegin event for
+   ceases.
+
+* Client C wants to pre-process touch events from a device D on window W, while
+  client I wants to pre-process touch events from device D on the parent window
+  of W.
+** C calls XISelectEvent for XI_Touch{Begin|Update|Ownership|End} from D on W.
+** I calls XIPassiveGrab for XI_Touch{Begin|Update|Ownership|End} from D on a
+   parent window of W.
+** I receives TouchBegin whenever a touch begins within window W, as well as a
+   TouchOwnership event indicating that it currently owns the touch sequence.
+   C receives a TouchBegin event as well, but without TouchOwnership.
+** When an axis valuator changes in this touch sequence, both I and C receive a
+   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 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 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
+  window W, while client I wants to process pointer events on window W's parent,
+  window Y.
+** I calls XIPassiveGrab for XI_{ButtonPress,MotionNotify,ButtonRelease} to
+   create a synchronous pointer grab from D on Y.
+** C calls XISelectEvent for XI_Touch{Begin|Update|Ownership|End} from D on W.
+** I receives a ButtonPress event whenever a touch begins within W, and is
+   considered the owner of the event.  C receives a TouchBegin event, but does
+   not receive a TouchOwnership event.
+** When the touchpoint moves, C will receive a TouchUpdate event.  Event
+   delivery to I is subject to the synchronous delivery mechanism. The
+   emulated motion notify event is queued in the server while the device is
+   frozen.
+** I may assert ownership by calling XIAllowEvents on Y with any mode other
+   than ReplayDevice, which will cause all further events to be sent only to I,
+   with a TouchEnd event being sent to C.
+** Alternatively, I may reject the touch sequence by calling XIAllowEvents on
+   Y with mode ReplayDevice, which will cause no further events from that touch
+   to be sent to I, and a TouchOwnership event to be sent to C, with subsequent
+   motion events being sent as TouchUpdate events.
+
+*  Driver DRV provides touch support from tracked device D:
+** DRV initializes a TouchClass for the device.
+** DRV parses D's device protocol and selects one touch sequence to be emulated
+   as pointer event.
+** DRV calls the respective input driver API with the touch sequence data. The
+   touch sequence emulating a pointer has the respective flag set. DRV does not
+   submit pointer data for any touchpoint.