[RFC XI 2.1 - inputproto] Various fixes in response to Peter Hutterer's review

[Chase Douglas]

---
Normally I'd just squash this in and make a v2 patch, but this is the most
important part of the MT work and it's easier to review separately :). I'll
squash later.

 XI2.h        |    3 +++
 XI2proto.txt |   39 ++++++++++++++++++++++++++++++++-------
 2 files changed, 35 insertions(+), 7 deletions(-)

diff --git a/XI2.h b/XI2.h
index 5d407ea..4995c43 100644
--- a/XI2.h
+++ b/XI2.h
@@ -193,4 +193,7 @@
 #define XI_TouchEndMask                  (1 << XI_TouchEnd)
 #define XI_TouchMotionMask               (1 << XI_TouchMotion)
 
+/* Convenience compound masks */
+#define XI_TouchMask                     (XI_TouchBegin | XI_TouchEnd | XI_TouchMotion)
+
 #endif /* _XI2_H_ */
diff --git a/XI2proto.txt b/XI2proto.txt
index fd47643..6976683 100644
--- a/XI2proto.txt
+++ b/XI2proto.txt
@@ -197,11 +197,29 @@ stage is optional. Within this document, the term "touch sequence" is used to
 describe the above chain of events. A client wishing to receive touch events
 must register for all three touch events simultaneously.
 
-Touch events are sent to all clients registered for them on any window in the
-window tree from the root window to the child window directly under the touch.
-
 A touch event is not delivered according to the device hierarchy. All touch
-events are sent only through their originating slave devices.
+events are sent only through their originating slave devices. However,
+dependent touch devices will only emit touch events if they are attached to a
+master device. This is due to the touch delivery being dependent on the
+location of a cursor.
+
+Touch events are broadcast to all clients registered for touch events on a
+set of windows. The window set is determined at the beginning of each touch
+and depend on whether the touch device is a direct or dependent device.
+
+Direct device window sets contain the windows from the root to the child
+in which the touch originated.
+
+Dependent device window sets depend on whether other touches are active. If
+other touches are active, the window set of the other touches is used. In this
+manner, all dependent device touch events are sent to the same set of windows.
+If no other touches are active, a new window set is created for the touch. The
+set is formed in the same manner as direct devices, but location used is the
+cursor position of the attached master device. If the touch device is floating
+it will not emit any touch events for the new touch.
+
+The delivery of touch events is not changed by any modifications to the window
+hierarchy after the window set has been determined for the touch.
 
 A device that sends touch events may also generate pointer events on demand.
 The decision of which touch events are converted into pointer events is
@@ -1696,9 +1714,9 @@ EVENTHEADER { type:                       BYTE
     selection of the hotspot of a touchpoint is implementation dependent and
     may not be the logical center of the touch.
 
-    Touch tracking IDs are always provided through one of the touch axis
-    valuators. Its value is always provided in every touch event. Tracking IDs
-    are represented as unsigned 32-bit values and are required to increase in
+    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 are required to increase in
     value for each new touch. Values will wrap back to 0 upon reaching the
     numerical limit of IDs.
 
@@ -1860,3 +1878,10 @@ require the client to announce XI 2.1 support in the XIQueryVersion request.
     ⊳ 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.
+     
+
+                              ❧❧❧❧❧❧❧❧❧❧❧
+
+Appendix B: Known Missing Features
+
+∙  Any form of grabbing or grab-like semantics for touch events
-- 
1.7.1