.gitignore | 78 +
COPYING | 22
Makefile.am | 13
README | 30
XI.h | 11
XI2.h | 76 +
XI2proto.h | 59 +
XI2proto.txt | 1677 ----------------------------------
XIproto.txt | 2542 ----------------------------------------------------
configure.ac | 24
specs/.gitignore | 1
specs/Makefile.am | 14
specs/XI2proto.txt | 2410 +++++++++++++++++++++++++++++++++++++++++++++++++
specs/XIproto.txt | 2576 +++++++++++++++++++++++++++++++++++++++++++++++++++++
14 files changed, 5271 insertions(+), 4262 deletions(-)
New commits:
commit 02eadf00f07abb9b0f19a05728b70e42eac08adb
Author: Chase Douglas <chase.doug...@canonical.com>
Date: Tue Dec 13 10:35:18 2011 -0800
inputproto 2.1.99.3
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
diff --git a/configure.ac b/configure.ac
index f34bda0..d2b1c3c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.1.99.2],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.1.99.3],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
commit 84c049b6603e370afcd267ce4c53a566f842fd69
Author: Chase Douglas <chase.doug...@canonical.com>
Date: Mon Dec 12 10:50:58 2011 -0800
State that future touch IDs are indeterminate
This just makes it absolutely clear that clients should not make any
assumptions about future touch ID values.
I also added "strictly monotonically" increasing to the definition of
touch IDs. It's a more precise definition of the protocol.
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index ba5f7b7..6082166 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2149,9 +2149,11 @@ 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 in value for each new
-touch, wrapping back to 0 upon reaching the numerical limit of IDs. IDs are
-globally unique.
+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.
Touch events do not generate enter/leave events.
commit 7d20c9bf38d3d47adc7fb1a70faa370dda1a390c
Author: Chase Douglas <cndougla@cndougla.(none)>
Date: Fri Dec 9 13:32:35 2011 -0800
Touch IDs must be globally unique
XIAllowEvents with a master device and a touch ID must uniquely identify
a touch sequence. If touch IDs were unique per slave device, multiple
slave devices could have valid sequences with the same touch ID, and the
sequences may both be grabbed through the same master device grab.
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index c467bb1..ba5f7b7 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2151,7 +2151,7 @@ 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 in value for each new
touch, wrapping back to 0 upon reaching the numerical limit of IDs. IDs are
-unique per each slave touch device.
+globally unique.
Touch events do not generate enter/leave events.
commit c4703fd9d97c962d5c599a7f826a9a11fc91ee70
Author: Peter Hutterer <peter.hutte...@who-t.net>
Date: Mon Dec 12 10:26:20 2011 +1000
Remove XI2.1 and XI2.2 warnings and errors
This is too much of a pain, anyone who includes XI headers needs to define
this. And that affects input and output drivers as well as legacy clients
that don't even need the new stuff.
Removing the need for defines would be enough but then the warnings clog up
the output and hide real warnings. Just ditch them and laugh at those that
use an experimental branch and expect it to work.
Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
Reviewed-by: Chase Douglas <chase.doug...@canonical.com>
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
diff --git a/XI2.h b/XI2.h
index 5a8afb7..4368006 100644
--- a/XI2.h
+++ b/XI2.h
@@ -25,16 +25,6 @@
#ifndef _XI2_H_
#define _XI2_H_
-#warning "XI 2.1 is not stable yet."
-#warning "Applications relying on this header will break as the protocol sees
updates."
-#ifndef XINPUT2_1_USE_UNSTABLE_PROTOCOL
-#error "Define XINPUT2_1_USE_UNSTABLE_PROTOCOL to disable this error"
-#endif
-#warning "XI 2.2 is not stable yet."
-#warning "Applications relying on this header will break as the protocol sees
updates."
-#ifndef XINPUT2_2_USE_UNSTABLE_PROTOCOL
-#error "Define XINPUT2_2_USE_UNSTABLE_PROTOCOL to disable this error"
-#endif
#define XInput_2_0 7
/* DO NOT ADD TO THIS LIST. These are libXi-specific defines.
See commit libXi-1.4.2-21-ge8531dd */
commit c9c4e13e8a3eb90b45c5ef65f729089b7f742e6a
Author: Peter Hutterer <peter.hutte...@who-t.net>
Date: Fri Nov 11 14:22:08 2011 +1000
inputproto 2.1.99.2
Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
diff --git a/configure.ac b/configure.ac
index df72ca6..f34bda0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.1.99.1],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.1.99.2],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
commit b289b1c039e36a9440c238ff09dfa3eb67e141e4
Author: Peter Hutterer <peter.hutte...@who-t.net>
Date: Thu Oct 20 15:55:54 2011 +1000
XI2: Use touchid, not touch_id in XIAllowEvents
Be consistent with other usages of touchid.
Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
Reviewed-by: Chase Douglas <chase.doug...@canonical.com>
diff --git a/XI2proto.h b/XI2proto.h
index 2460cf5..56df401 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -647,7 +647,7 @@ typedef struct {
uint16_t deviceid;
uint8_t mode;
uint8_t pad;
- uint32_t touch_id; /**< Since XI 2.2 */
+ uint32_t touchid; /**< Since XI 2.2 */
Window grab_window; /**< Since XI 2.2 */
} xXIAllowEventsReq;
#define sz_xXIAllowEventsReq 20 /**< Was 12 before XI 2.2 */
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index b0607a1..c467bb1 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1372,7 +1372,7 @@ active device grab becomes not viewable.
AsyncPairedDevice, SyncPairedDevice,
ReplayDevice, AsyncPair, SyncPair, AcceptTouch*,
RejectTouch* }
- touch_id*: CARD32
+ touchid*: CARD32
grab_window*: Window
└───
@@ -1389,7 +1389,7 @@ ownership processing.
event_mode
Specifies whether a device is to be thawed and events are to be
replayed, or how to handle a grabbed touch sequence.
- touch_id
+ 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
commit 86ce2d05e86852d52f5b135ad03288e4cb16d5df
Author: Peter Hutterer <peter.hutte...@who-t.net>
Date: Thu Nov 3 09:30:20 2011 +1000
XI2: swap (Raw)TouchUpdate and (Raw)TouchEnd
Not having the event codes in the order begin/update/end does my head in
when debugging. It also means there's no symmetry between raw and normal
touch events as the ownership event is wedged in between.
Rearrange event codes to be Begin/Update/End for both, with the
OwnershipEvent being in between.
Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
Reviewed-by: Chase Douglas <chase.doug...@canonical.com>
Reviewed-by: Jeremy Huddleston <jerem...@apple.com>
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
diff --git a/XI2.h b/XI2.h
index e66751c..5a8afb7 100644
--- a/XI2.h
+++ b/XI2.h
@@ -202,13 +202,13 @@
#define XI_RawButtonRelease 16
#define XI_RawMotion 17
#define XI_TouchBegin 18 /* XI 2.2 */
-#define XI_TouchEnd 19
-#define XI_TouchOwnership 20
-#define XI_TouchUpdate 21
+#define XI_TouchUpdate 19
+#define XI_TouchEnd 20
+#define XI_TouchOwnership 21
#define XI_RawTouchBegin 22
-#define XI_RawTouchEnd 23
-#define XI_RawTouchUpdate 24
-#define XI_LASTEVENT XI_RawTouchUpdate
+#define XI_RawTouchUpdate 23
+#define XI_RawTouchEnd 24
+#define XI_LASTEVENT XI_RawTouchEnd
/* NOTE: XI2LASTEVENT in xserver/include/inputstr.h must be the same value
* as XI_LASTEVENT if the server is supposed to handle masks etc. for this
* type of event. */
commit cec7567863c3d363b6b75c707540cfe524f849ba
Author: Chase Douglas <chase.doug...@canonical.com>
Date: Wed Sep 14 22:09:28 2011 -0500
Revert addition of active_touches to device events
I can't remember why it's there, and I don't see how it may be useful.
If a client really wants to know how many touches are on the device,
they can listen to raw events and count the number of active touches.
(Real reason: extending events is hard :)
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
diff --git a/XI2proto.h b/XI2proto.h
index 9e2c63c..2460cf5 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -936,7 +936,6 @@ typedef struct
uint32_t flags; /**< ::XIKeyRepeat */
xXIModifierInfo mods;
xXIGroupInfo group;
- uint32_t active_touches; /**< Number of touches on source
device (XI 2.1 only) */
} xXIDeviceEvent;
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 73aa52b..b0607a1 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2031,11 +2031,8 @@ For a detailed description of classes, see the
XIQueryDevice request.
buttons: SETofBUTTONMASK
valuators: SETofVALUATORMASK
axisvalues: LISTofFP3232
- active_touches*: CARD32
└───
- * since XI 2.2
-
BUTTONBIT { (1 << Button1), (1 << Button2), ... , (1 << ButtonN) }
VALUATORBIT { (1 << 1), ( 1 << 2), ... ( 1 << n) }
@@ -2114,9 +2111,6 @@ KeyRelease, ButtonPress, ButtonRelease, Motion.
accepted or passed on ownership. The touch will not generate any
further TouchUpdate events once an event with TouchPendingEnd has been
received.
- active_touches
- Only in XI 2.2 and later. Only valid for TouchBegin, TouchUpdate, and
- TouchEnd events.
The active_touches value denotes the number of touches in contact with
the source touch device surface when the event occurred. The value
commit 22c06a5ddb1d3be2743a79b78eff3844f457dc5e
Author: Chase Douglas <chase.doug...@canonical.com>
Date: Wed Sep 14 20:15:49 2011 -0500
Fix Xi 2.x version comment in XI2.h
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
diff --git a/XI2.h b/XI2.h
index 2514d55..e66751c 100644
--- a/XI2.h
+++ b/XI2.h
@@ -201,7 +201,7 @@
#define XI_RawButtonPress 15
#define XI_RawButtonRelease 16
#define XI_RawMotion 17
-#define XI_TouchBegin 18 /* XI 2.1 */
+#define XI_TouchBegin 18 /* XI 2.2 */
#define XI_TouchEnd 19
#define XI_TouchOwnership 20
#define XI_TouchUpdate 21
commit 88410aa51d03dbb5599e979998137ba6558ff677
Author: Chase Douglas <chase.doug...@canonical.com>
Date: Tue Sep 13 16:59:54 2011 -0500
inputproto 2.1.99.1 (first snapshot of 2.2)
Note that this is built on top of 2.0.99.1, which is a development
snapshot of 2.1.
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
diff --git a/configure.ac b/configure.ac
index b3acba5..df72ca6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.1.99],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.1.99.1],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
commit fa16231f0e5244cdcf77e262647525716f507bdd
Author: Chase Douglas <chase.doug...@canonical.com>
Date: Wed Sep 14 10:10:14 2011 -0500
Allow grabbing clients to accept or reject touches any time
This is potentially both a performance and client complexity
improvement. An example is a gesture recognizer using touch grabs on
each window with a subscription. If events on a child window are known
to not match any subscription on the child window, then the client
should be able to reject the touch grab even if the parent window hasn't
accepted any of the touches, perhaps because the parent window
gesture hasn't timed out or crossed other thresholds yet.
As an inverse example, the events may match a child window subscription
before the root window has rejected ownership. The child window should
be able to accept the touch proactively. This allows for further clients
to receive a TouchEnd event earlier, and means the client may be able to
reduce state being tracked. If this were not allowed, the client would
need to wait until it received ownership before accepting the sequence.
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
diff --git a/XI2proto.h b/XI2proto.h
index 3315f1e..9e2c63c 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -648,8 +648,9 @@ typedef struct {
uint8_t mode;
uint8_t pad;
uint32_t touch_id; /**< Since XI 2.2 */
+ Window grab_window; /**< Since XI 2.2 */
} xXIAllowEventsReq;
-#define sz_xXIAllowEventsReq 16 /**< Was 12 before XI 2.2 */
+#define sz_xXIAllowEventsReq 20 /**< Was 12 before XI 2.2 */
/**
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 9bd586a..73aa52b 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1373,6 +1373,7 @@ active device grab becomes not viewable.
ReplayDevice, AsyncPair, SyncPair, AcceptTouch*,
RejectTouch* }
touch_id*: CARD32
+ grab_window*: Window
└───
* since XI 2.2
@@ -1391,13 +1392,17 @@ ownership processing.
touch_id
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 or RejectTouch, a BadValue error occurs if the
-touch ID is invalid. A BadAccess error occurs if this client is not the current
+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
@@ -1470,13 +1475,16 @@ you pass to the event-mode argument:
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.
+ 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. Ownership will be passed on to the next
- listener.
+ 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]]
┌───
commit 2ea2f99f4fe1dcd3b8e539ca41c482fc40a0533d
Author: Chase Douglas <chase.doug...@canonical.com>
Date: Wed Sep 14 09:46:18 2011 -0500
Extend XIAllowEvents for handling touch grab processing
This removes the XIAllowTouchEvents request, which was the only new
request added for multitouch.
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
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
commit 3c400af4f98740debd7916ad711cf91124a0f994
Author: Chase Douglas <chase.doug...@canonical.com>
Date: Tue Sep 13 15:47:15 2011 -0500
Add event windows to ownership events
Also, match device event structure to make things easy.
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
diff --git a/XI2proto.h b/XI2proto.h
index 023acc8..8117767 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -909,9 +909,13 @@ typedef struct
uint16_t evtype; /**< XI_TouchOwnership */
uint16_t deviceid; /**< Device that has changed */
Time time;
+ uint32_t touchid;
+ Window root;
+ Window event;
+ Window child;
+/* └──────── 32 byte boundary ────────┘ */
uint16_t sourceid; /**< Source of the new classes */
uint16_t pad0;
- uint32_t touchid;
uint32_t flags;
uint32_t pad1;
uint32_t pad2;
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 6a5345c..3eea2f5 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2328,8 +2328,11 @@ Events introduced in version 2.2
┌───
TouchOwnershipEvent (since XI 2.2):
EVENTHEADER
- sourceid: DEVICEID
touchid: CARD32
+ root: Window
+ event: Window
+ child: Window
+ sourceid: DEVICEID
flags: SETofTOUCHOWNERSHIPFLAGS
└───
@@ -2338,10 +2341,15 @@ Events introduced in version 2.2
A TouchOwnershipEvent indicates that ownership has changed, and the client
is now the owner of the touch sequence specified by touchid.
- sourceid
- The source device that originally generated the event.
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.
commit dd9e4bc5f5f2e0eb87b08199ce417849070249ab
Author: Chase Douglas <chase.doug...@canonical.com>
Date: Tue Sep 13 15:30:34 2011 -0500
Really kill touch valuators
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
diff --git a/XI2.h b/XI2.h
index 3c1f4a5..2e19e03 100644
--- a/XI2.h
+++ b/XI2.h
@@ -154,7 +154,6 @@
#define XIValuatorClass 2
#define XIScrollClass 3
#define XITouchClass 8
-#define XITouchValuatorClass 9
/* Scroll class types */
#define XIScrollTypeVertical 1
commit 05fc509fdca8d8b414a20f1359b9cb80caf5240a
Author: Peter Hutterer <peter.hutte...@who-t.net>
Date: Wed Sep 14 05:46:43 2011 +1000
specs: if a sequence ends, all clients get TouchPendingEnd
Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
Reviewed-by: Chase Douglas <chase.doug...@canonical.com>
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 2bc9d30..6a5345c 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -374,11 +374,11 @@ 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, the client receives a
-TouchUpdate event with the TouchPendingEnd flag set, but 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.
+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
commit 94fecdf129d8ab5bece049a26eed03d24affb549
Author: Peter Hutterer <peter.hutte...@who-t.net>
Date: Wed Sep 14 05:26:54 2011 +1000
specs: remove broken asciidoc link to XIAllowTouchEvents
Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
Reviewed-by: Chase Douglas <chase.doug...@canonical.com>
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index e473a05..2bc9d30 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -361,7 +361,7 @@ 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
-<<request-allowtouchevents,XIAllowTouchEvents>> request. If a touch sequence is
+XIAllowTouchEvents 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
commit 4782a76b6e679493f130a53afe158a13628fa504
Author: Peter Hutterer <peter.hutte...@who-t.net>
Date: Wed Sep 14 05:25:15 2011 +1000
specs: remove comment about overlapping selections, not true
There are no overlapping selections for touch events.
Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
Reviewed-by: Chase Douglas <chase.doug...@canonical.com>
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index f495812..e473a05 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -353,9 +353,7 @@ and must decide what to do with it, as per Section
<<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,
-although some overlapping selections are allowed (see Section
-<<multitouch-processing,Touch event delivery>>).
+Only one client may select for touch events from a given device on a window.
[[multitouch-ownership]]
Ownership of touch sequences
commit dd32802d2e6134cf9c4efd49c56c118ed02e6a2b
Author: Peter Hutterer <peter.hutte...@who-t.net>
Date: Wed Sep 14 05:21:31 2011 +1000
specs: misc typos, rewording, etc.
Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
Reviewed-by: Chase Douglas <chase.doug...@canonical.com>
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 18ae599..f495812 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -79,14 +79,15 @@ The additions in XI 2.2 aim to:
- 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 as they appear,
- e.g. touching an object and physically moving it.
+ "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
@@ -303,9 +304,9 @@ Touch device support
--------------------
Touch event processing differs from normal event processing in a few ways.
-The most notable are that touch events are processed partially out-of-band from
-pointer and keyboard events, and in that touch events may be sent to multiple
-clients simultaneously; for more details see Section
+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]]
@@ -319,7 +320,7 @@ Touch input follows a three-stage cycle:
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 chain of events.
+"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
@@ -327,7 +328,7 @@ 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 used to focus the event for delivery, as well as the
+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
@@ -336,8 +337,7 @@ 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 (usually new touch
-co-ordinates).
+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
@@ -367,18 +367,20 @@ Once a grabbing client becomes the owner of a touch, it
must either “accept”
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 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 instead accepted by its
-owner, all other clients receive TouchEnd events, and the touch sequence is
-exclusively delivered to the owner from that point on.
+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 accepted or rejected ownership, the client receives a TouchUpdate event
-with the TouchPendingEnd flag set, but 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.
+has not yet accepted or rejected ownership, the client receives a
+TouchUpdate event with the TouchPendingEnd flag set, but 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
@@ -422,8 +424,8 @@ following device modes are defined for this protocol:
'DirectTouch':
These devices map their input region to a subset of the screen region.
Touch
- focus is determined according to where the touch occurs in the mapped
screen
- region. An example of a DirectTouch device is a touchscreen.
+ 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
@@ -432,8 +434,8 @@ following device modes are defined for this protocol:
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, a
-DeviceChangedEvent is generated.
+the touch mode may change at any time. If a device's touch mode changes, an
+XIDeviceChangedEvent is generated.
[[multitouch-processing]]
Touch event delivery
commit cfa06b98d50d6892e5961e86f6223b6b096d9ef4
Author: Chase Douglas <chase.doug...@canonical.com>
Date: Tue Sep 13 15:09:57 2011 -0500
Bump version to 2.1.99 for XI 2.2 multitouch changes
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
diff --git a/configure.ac b/configure.ac
index d3e2bc2..b3acba5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.0.99.1],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.1.99],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
commit 24e7dac91fb919c1668736f6e4309ae522a96d86
Author: Chase Douglas <chase.doug...@canonical.com>
Date: Tue Sep 13 14:27:13 2011 -0500
Switch multitouch additions to XI 2.2
Signed-off-by: Chase Douglas <chase.doug...@canonical.com>
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1rbjvj-0003tx...@vasks.debian.org
