x11proto-input: Changes to 'upstream-unstable'
Rebased ref, commits from common ancestor:
commit 8640944f4ff193027ce0f21622918b88da910e72
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Dec 16 11:06:13 2011 +1000
inputproto 2.1
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
diff --git a/configure.ac b/configure.ac
index c755917..8e2bb0d 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], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
commit 019a252a59c1d076b07a0162cb3ee6af42ceea14
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Dec 2 15:03:46 2011 +1000
specs: typo fix
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 6c1ccbe..f220557 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -218,7 +218,7 @@ event processing stops.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Many core protocol and some extension requests are ambiguous when multiple
-master devices are available (e.g. QueryPointer does not specfy which pointer).
+master devices are available (e.g. QueryPointer does not specify which pointer).
The X server does not have the knowledge to chose the contextually correct
master device. For each client, one master pointer is designated as this
clients's "ClientPointer". Whenever a client sends an ambiguous request (e.g.
commit a9fcea66eb18fab330f3b27b3daedef2b5c9210a
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Nov 11 14:33:34 2011 +1000
specs: smooth scrolling was added in 2.1, say so
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 2a25c4e..6c1ccbe 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -40,6 +40,7 @@ device information in each event (with the exception of core events).
Changes introduced by version 2.1
- RawEvents are sent regardless of the grab state.
+- Addition of the ScrollClass for smooth scrolling
// ❧❧❧❧❧❧❧❧❧❧❧
commit 279524b089c7b42871ee072cfc03a1fad7421b7b
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue Nov 8 15:36:02 2011 +1000
specs: scroll events have no specific event type, state so.
This wasn't clear enough in the current spec.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index b6707b3..2a25c4e 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -128,13 +128,14 @@ simply dragging your finger along a designated strip along the side of the
touchpad.
Newer X servers may provide scrolling information through valuators to
-provide scroll events with more precision than the button events. Valuators
-for axes sending scrolling information must have one ScrollClass for each
-scrolling axis.
-
-If scrolling valuators are present on a device, the server must provide
-two-way emulation between these valuators and the legacy button events for
-each delta unit of scrolling.
+provide clients with more precision than the legacy button events. This
+scrolling information is part of the valuator data in device events.
+Scrolling events do not have a specific event type.
+
+Valuators for axes sending scrolling information must have one
+ScrollClass for each scrolling axis. If scrolling valuators are present on a
+device, the server must provide two-way emulation between these valuators
+and the legacy button events for each delta unit of scrolling.
One unit of scrolling in either direction is considered to be equivalent to
one button event, e.g. for a unit size of 1.0, -2.0 on an valuator type
commit 9f2b1a33063b139756e08951affe802e8af39a76
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue Nov 8 15:29:24 2011 +1000
specs: We're up to version 2.1 now, say so
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 1a93c8d..b6707b3 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2,6 +2,7 @@ The X Input Extension
=====================
Version 2.0
+ Version 2.1
Peter Hutterer
peter.hutterer@redhat.com
commit 463ffaabab506ad6ddb3b55c5781ae91fcccfd04
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Sep 23 08:41:18 2011 +1000
specs: clarify that Preferred scroll valuators are per scroll direction
Reported-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 2b13845..1a93c8d 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -147,10 +147,11 @@ with the XIPointerEmulated flag for DeviceEvents, and the XIRawEmulated flag
for raw events, to hint at applications which event is a hardware event.
If more than one scroll valuator of the same type is present on a device,
-the valuator marked with Preferred is used to convert legacy button events
-into scroll valuator events. If no valuator is marked Preferred or more than
-one valuator is marked with Preferred, this should be considered a driver
-bug and the behaviour is implementation-dependent.
+the valuator marked with Preferred for the same scroll direction is used to
+convert legacy button events into scroll valuator events. If no valuator is
+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
------------------------------------
commit 9cfdeedd16e96c0e67e70537e97a8f8dd0358244
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Thu Jun 2 16:09:23 2011 +1000
inputproto 2.0.99.1 (first snapshot of 2.1)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
diff --git a/configure.ac b/configure.ac
index 3c8719a..c755917 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.0.99], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.0.99.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
commit 7d5a303cd8976a7eac1b96897c70d5d25c57ecf1
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Mon Aug 15 12:33:04 2011 +1000
Move scroll information into a new class.
Using labels only to mark smooth scrolling axes disallows scrolling from
hardware events (e.g. a mouse wheel). If those axes are marked as scrolling
axes instead, the clients lose information which hardware axis this event
corresponds to.
For example, on Wacom devices, the client can benefit from smooth scrolling
on the strip or wheel event but may still require the knowledge whether the
axis is a vertical strip (e.g. Intuos3) or a absolute scrolling wheel (e.g.
Intuos4).
Thus, add a new class to XIQueryDevice that represents scrolling information
on a valuator. One of these ScrollClass may exist for each ValuatorClass if
that valuator is a scrolling valuator. The increment field of this class
removes the requirement for 1.0 == 1 unit of scrolling.
This isn't true in most cases, especially where physical scroll axes are
involved. Wacom Intuos4 scroll rings have a unit size of 3.0 and the driver
historically sent one scroll event per 3.0 increment or decrement. Mapping
one scroll event to 1.0 makes the ring mostly unusable through legacy
button events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
diff --git a/XI2.h b/XI2.h
index 29ffdd1..18dd172 100644
--- a/XI2.h
+++ b/XI2.h
@@ -141,6 +141,15 @@
#define XIKeyClass 0
#define XIButtonClass 1
#define XIValuatorClass 2
+#define XIScrollClass 3
+
+/* Scroll class types */
+#define XIScrollTypeVertical 1
+#define XIScrollTypeHorizontal 2
+
+/* Scroll class flags */
+#define XIScrollFlagNoEmulation (1 << 0)
+#define XIScrollFlagPreferred (1 << 1)
/* Device event flags (common) */
/* Device event flags (key events only) */
diff --git a/XI2proto.h b/XI2proto.h
index 8977e87..adcd0f3 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -188,6 +188,21 @@ typedef struct {
uint16_t pad2;
} xXIValuatorInfo;
+/***
+ * Denotes a scroll valuator on a device.
+ * One XIScrollInfo describes exactly one scroll valuator that must have a
+ * XIValuatorInfo struct.
+ */
+typedef struct {
+ uint16_t type; /**< Always ValuatorClass */
+ uint16_t length; /**< Length in 4 byte units */
+ uint16_t sourceid; /**< source device for this class */
+ uint16_t number; /**< Valuator number */
+ uint16_t scroll_type; /**< ::XIScrollTypeVertical, ::XIScrollTypeHorizontal */
+ uint16_t pad0;
+ uint32_t flags; /**< ::XIScrollFlagEmulate, ::XIScrollFlagPreferred */
+ FP3232 increment; /**< Increment for one unit of scrolling */
+} xXIScrollInfo;
/**
* Used to select for events on a given window.
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 4acb5a8..2b13845 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -126,20 +126,31 @@ are able to provide scrolling events through multi-finger drag gestures, or
simply dragging your finger along a designated strip along the side of the
touchpad.
-Newer X servers may provide 'Rel Vert Scroll' and 'Rel Horiz Scroll' valuators
-to provide scroll events with more precision than the button events. If these
-valuators are present on a device, the server must provide two-way emulation
-between these valuators and the legacy button events. A cumulative value of
-1.0 in either magnitude is considered to be equivalent to one button event for
-the legacy events, e.g., -2.0 on 'Rel Vert Scroll' sends two button
-press/release events for button 4. Likewise, a button press event for
-button 7 generates a Rel Horiz Scroll valuator event with a value of +1.0.
-
-Any server providing this behaviour marks all button 4/5/6/7 events with the
-XIPointerEmulated flag for DeviceEvents, and the XIRawEmulated flag for raw
-events, to hint that applications should be using the new valuators in
-preference to the buttons.
-
+Newer X servers may provide scrolling information through valuators to
+provide scroll events with more precision than the button events. Valuators
+for axes sending scrolling information must have one ScrollClass for each
+scrolling axis.
+
+If scrolling valuators are present on a device, the server must provide
+two-way emulation between these valuators and the legacy button events for
+each delta unit of scrolling.
+
+One unit of scrolling in either direction is considered to be equivalent to
+one button event, e.g. for a unit size of 1.0, -2.0 on an valuator type
+Vertical sends two button press/release events for button 4. Likewise, a
+button press event for button 7 generates an event on the Horizontal
+valuator with a value of +1.0. The server may accumulate deltas of less than
+one unit of scrolling.
+
+Any server providing this behaviour marks emulated button or valuator events
+with the XIPointerEmulated flag for DeviceEvents, and the XIRawEmulated flag
+for raw events, to hint at applications which event is a hardware event.
+
+If more than one scroll valuator of the same type is present on a device,
+the valuator marked with Preferred is used to convert legacy button events
+into scroll valuator events. If no valuator is marked Preferred or more than
+one valuator is marked with Preferred, this should be considered a driver
+bug and the behaviour is implementation-dependent.
4. The Master/Slave device hierarchy
------------------------------------
@@ -329,7 +340,7 @@ If major_version is less than 2, a BadValue error occurs.
name: LISTofCHAR8
classes: LISTofCLASS }
- CLASS { BUTTONCLASS, KEYCLASS, AXISCLASS }
+ CLASS { BUTTONCLASS, KEYCLASS, AXISCLASS, SCROLLCLASS }
BUTTONCLASS { type: ButtonClass
length: CARD16
@@ -355,6 +366,20 @@ If major_version is less than 2, a BadValue error occurs.
resolution: CARD32
mode: CARD8 }
+ SCROLLCLASS* {type: ScrollClass
+ length: CARD16
+ sourceid: CARD16
+ axisnumber: CARD16
+ scroll_type: SCROLLTYPE
+ flags: SETofSCROLLFLAGS
+ increment: FP3232 }
+
+ * since XI 2.1
+
+ SCROLLTYPE { Vertical, Horizontal }
+
+ SCROLLFLAGS { NoEmulation, Preferred }
+
XIQueryDevice details information about the requested input devices.
devices
@@ -457,6 +482,32 @@ The following classes may occur only once: ButtonClass, KeyClass
An axis in Relative mode may specify min and max as a hint to the
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.
+ scroll_type:
+ Vertical for a vertical scrolling axis, Horizontal for a horizontal
+ scrolling axis.
+ flags:
+ A set of flags that apply to this scroll axis.
+ NoEmulation: no legacy scroll button events are generated for events
+ on this scrolling axis.
+ Preferred: This axis is the preferred axis for emulating valuator
+ events from legacy scroll button events.
+ increment:
+ The valuator delta equivalent to one positive unit of scrolling.
+
+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.
+
┌───
XISelectEvents
window: Window
commit 186aa20619d1720bde49fd92d2834c8f9eadf49b
Author: Daniel Stone <daniel@fooishbar.org>
Date: Wed Feb 23 17:37:29 2011 +0000
Document smooth-scrolling support
Two new axes are added to support smooth scrolling: Rel Vert Scroll and
Rel Horiz Scroll. Cumulative values of 1.0 with either magnitude on
these axes are considered to be equivalent to one legacy ButtonPress
event on the scroll buttons.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 5d50b45..4acb5a8 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -115,7 +115,31 @@ XI 1.x was not designed with support for multiple master devices (see Section
to XI 1.x clients, all other master devices are invisible and cannot be
accessed from XI 1.x calls.
-// ❧❧❧❧❧❧❧❧❧❧❧
+3.4 Smooth scrolling
+~~~~~~~~~~~~~~~~~~~~
+
+Historically, X implemented scrolling events by using button press events:
+button 4 was one “click” of the scroll wheel upwards, button 5 was downwards,
+button 6 was one unit of scrolling left, and button 7 was one unit of scrolling
+right. This was sufficient for scroll wheel mice, but not for touchpads which
+are able to provide scrolling events through multi-finger drag gestures, or
+simply dragging your finger along a designated strip along the side of the
+touchpad.
+
+Newer X servers may provide 'Rel Vert Scroll' and 'Rel Horiz Scroll' valuators
+to provide scroll events with more precision than the button events. If these
+valuators are present on a device, the server must provide two-way emulation
+between these valuators and the legacy button events. A cumulative value of
+1.0 in either magnitude is considered to be equivalent to one button event for
+the legacy events, e.g., -2.0 on 'Rel Vert Scroll' sends two button
+press/release events for button 4. Likewise, a button press event for
+button 7 generates a Rel Horiz Scroll valuator event with a value of +1.0.
+
+Any server providing this behaviour marks all button 4/5/6/7 events with the
+XIPointerEmulated flag for DeviceEvents, and the XIRawEmulated flag for raw
+events, to hint that applications should be using the new valuators in
+preference to the buttons.
+
4. The Master/Slave device hierarchy
------------------------------------
@@ -1573,7 +1597,10 @@ KeyRelease, ButtonPress, ButtonRelease, Motion.
valid for KeyPress events.
PointerEmulated signals that the event has been emulated from another
XI 2.x event for legacy client support, and that this event should
- be ignored if the client listens for these events.
+ 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.
Modifier state in mods is detailed as follows:
commit 53b58e679f977550301130794c8cb19391ecceb7
Author: Daniel Stone <daniel@fooishbar.org>
Date: Tue Feb 15 14:27:53 2011 +0000
Add XIPointerEmulated for emulated events
The XIPointerEmulated flag on pointer events means that the event was
emulated from a smooth-scroll or touch event to support legacy events,
and the client may ignore this if it is listening to the other events.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
diff --git a/XI2.h b/XI2.h
index 40a9faf..29ffdd1 100644
--- a/XI2.h
+++ b/XI2.h
@@ -146,6 +146,7 @@
/* Device event flags (key events only) */
#define XIKeyRepeat (1 << 16)
/* Device event flags (pointer events only) */
+#define XIPointerEmulated (1 << 16)
/* XI2 event mask macros */
#define XISetMask(ptr, event) (((unsigned char*)(ptr))[(event)>>3] |= (1 << ((event) & 7)))
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 8736b18..5d50b45 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1526,7 +1526,7 @@ For a detailed description of classes, see the XIQueryDevice request.
DEVICEEVENTFLAGS (all events): none
DEVICEEVENTFLAGS (key events only): { KeyRepeat }
- DEVICEEVENTFLAGS (pointer events only): none
+ DEVICEEVENTFLAGS (pointer events only): { PointerEmulated }
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
@@ -1571,6 +1571,9 @@ KeyRelease, ButtonPress, ButtonRelease, Motion.
KeyRepeat means that this event is for repeating purposes, and
the physical state of the key has not changed. This is only
valid for KeyPress events.
+ PointerEmulated signals that the event has been emulated from another
+ XI 2.x event for legacy client support, and that this event should
+ be ignored if the client listens for these events.
Modifier state in mods is detailed as follows:
commit af1fb609beece899188469a81ac9d8c5e07bfa4a
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Jul 29 10:09:02 2011 +1000
Add sourceid to RawEvents (#34420)
RawEvents in XI2 do not provide the source ID. The libXi headers however do
and it is currently always 0. Given that the sourceid may be useful for
some clients, send it down the wire.
This has no effect on the wire size of the struct, we can re-use a pad byte
here.
X.Org Bug 34420 <http://bugs.freedesktop.org/show_bug.cgi?id=34420>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
diff --git a/XI2proto.h b/XI2proto.h
index 84574a5..8977e87 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -902,7 +902,7 @@ typedef struct
uint16_t deviceid;
Time time;
uint32_t detail;
- uint16_t pad0;
+ uint16_t sourceid; /**< The source device (XI 2.1) */
uint16_t valuators_len; /**< Length of trailing valuator
mask in 4 byte units */
uint32_t flags; /**< ::XIKeyRepeat */
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 9ec9515..8736b18 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1593,6 +1593,7 @@ Modifier state in mods is detailed as follows:
RawEvent
EVENTHEADER
detail: CARD32
+ sourceid*: DEVICEID
flags: DEVICEEVENTFLAGS
valuators_len: CARD16
valuators: SETofVALUATORMASK
@@ -1600,6 +1601,8 @@ Modifier state in mods is detailed as follows:
axisvalues_raw: LISTofFP3232
└───
+ * since XI 2.1
+
A RawEvent provides the information provided by the driver to the
client. RawEvent provides both the raw data as supplied by the driver and
transformed data as used in the server. Transformations include, but are
@@ -1613,10 +1616,14 @@ grabbed by another client.
Clients supporting XI 2.1 or later receive raw events at all times, even
when the device is grabbed by another client.
+
eventtype
The type of event that occured on the device.
detail
The button number or keycode.
+ sourceid
+ The source device that originally generated the event. The sourceid
+ is undefined for clients not supporting XI 2.1.
flags
Flags as described in DeviceEvent.
valuators_len
commit 1e63d01d041108db6fe5be32d033e80419a6ab05
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue Apr 12 13:07:53 2011 +1000
XI2.1: send RawEvents at all times.
When a client grabbed a device, XI 2.0 only sends RawEvents to that client.
This behaviour is problematic and cannot be worked around for many
applications that need to continue receiving events.
On the other hand, no client seems to rely on this behaviour or use it to
its advantage. For XI 2.1, disable this behaviour and continue to send raw
events regardless of the grab state of the device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index bf8ca90..9ec9515 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -34,6 +34,12 @@ used on applications employing the core protocol. XI2 addresses both of these
issues by enabling devices to be both extended and core devices and providing
device information in each event (with the exception of core events).
+2.1 Changes
+-----------
+Changes introduced by version 2.1
+
+- RawEvents are sent regardless of the grab state.
+
// ❧❧❧❧❧❧❧❧❧❧❧
2. Notations used in this document
@@ -1600,8 +1606,12 @@ transformed data as used in the server. Transformations include, but are
not limited to, axis clipping and acceleration.
Transformed valuator data may be equivalent to raw data. In this case,
both raw and transformed valuator data is provided.
-RawEvents are sent exclusively to all root windows or to the client
-that grabbed the device only.
+RawEvents are sent exclusively to all root windows.
+Clients supporting XI 2.0 receive raw events when the device is not grabbed,
+or when the device is grabbed by the client but not when the device is
+grabbed by another client.
+Clients supporting XI 2.1 or later receive raw events at all times, even
+when the device is grabbed by another client.
eventtype
The type of event that occured on the device.
commit b35f20b7bd9620710a7a6b63e39758fe83b4dec8
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Apr 8 13:26:27 2011 +1000
Announce 2.1 availability through the XI_2_Major and XI_2_Minor defines
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
diff --git a/XI2.h b/XI2.h
index 4affaea..40a9faf 100644
--- a/XI2.h
+++ b/XI2.h
@@ -36,7 +36,7 @@
See commit libXi-1.4.2-21-ge8531dd */
#define XI_2_Major 2
-#define XI_2_Minor 0
+#define XI_2_Minor 1
/* Property event flags */
#define XIPropertyDeleted 0
commit 47a2cc250398648732ba2086ca6ecb21e7dabdc0
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Apr 8 12:59:17 2011 +1000
Bump to 2.0.99
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
diff --git a/configure.ac b/configure.ac
index bd5f046..3c8719a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.0.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.0.99], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
commit 94b21b47b51c2c66aa0372dfc323d6aedf12b549
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue Aug 23 15:28:50 2011 +1000
specs: fix two typos in XI2proto.txt
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index e3c8196..bf8ca90 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -87,7 +87,7 @@ These fields include:
- devices with a deviceid of greater than 127 are invisible to XI1 clients.
- key events and key grabs featuring larger than 255 can only be sent to XI2
clients.
-- no subpixel information is avialable to XI1 clients. If motion events are in
+- no subpixel information is available to XI1 clients. If motion events are in
a subpixel range only, the server may omit these events and an XI 1.x client
will not receive events until the pixel boundary is crossed.
@@ -1482,7 +1482,7 @@ master device, or by a physical device changing capabilities at runtime.
Details the available classes provided by the device. The order the
classes are provided in is undefined.
-For a detailed description of classes, see the XQueryDevice request.
+For a detailed description of classes, see the XIQueryDevice request.
┌───
DeviceEvent:
commit 9f33733fffddd166c64f0bfd293c3de385cf4411
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Wed Aug 17 16:02:39 2011 +1000
specs: ValuatorClass includes a mode
Documented in the description, but missing in the definition.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 302be65..e3c8196 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -322,7 +322,8 @@ If major_version is less than 2, a BadValue error occurs.
min: FP3232
max: FP3232
value: FP3232
- resolution: CARD32 }
+ resolution: CARD32
+ mode: CARD8 }
XIQueryDevice details information about the requested input devices.
commit 2ba875f4f2907bb9735ee3317b7e07c5b9d1304b
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue Aug 2 10:20:53 2011 +1000
Put a warning in about not adding any further libXi defines
The matching commit in libXi is
e8531dd6a981c6cf19a1d256c29e886e34e8f51a
libXi-1.4.2-21-ge8531ddp
Add XI2 library-internal array offsets to XIint.h
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
diff --git a/XI2.h b/XI2.h
index 783e22f..4affaea 100644
--- a/XI2.h
+++ b/XI2.h
@@ -32,7 +32,8 @@
#define Dont_Check 0
#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 */
#define XI_2_Major 2
#define XI_2_Minor 0
commit ee91dcda461513cdca45160df580841daa6f50e2
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Thu Mar 17 16:29:08 2011 +1000
specs: add a linebreak for asciidoc parsing
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 1e3adbe..302be65 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -598,6 +598,7 @@ Change a master pointer's cursor on the specified window.
Whenever device enters a window W, the cursor shape is selected in the
following order:
+
- if the current window has a device cursor C(d) defined for device,
display this cursor C(d).
- otherwise, if the current window has a cursor C(w) defined in the core
commit 2cd2adb7a454072954704e1a215df49ce9dac410
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Jun 3 15:56:21 2011 +1000
Provide convenience defines for owner_events.
No functional effect, just to improve readability of code.
It's not obvious what "True" or "False" stands for in a function with 11
arguments. Compare
XIGrabButton(dpy, deviceid, button, grab_window, cursor,
GrabModeAsync, GrabModeSync, True,
event_mask, num_modifiers, &modifiers);
vs.
XIGrabButton(dpy, deviceid, button, grab_window, cursor,
GrabModeAsync, GrabModeSync, XIOwnerEvents,
event_mask, num_modifiers, &modifiers);
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
diff --git a/XI2.h b/XI2.h
index 43338a1..783e22f 100644
--- a/XI2.h
+++ b/XI2.h
@@ -79,6 +79,10 @@
#define XIGrabNotViewable 3
#define XIGrabFrozen 4
+/* Grab owner events values */
+#define XIOwnerEvents True
+#define XINoOwnerEvents False
+
/* Passive grab types */
#define XIGrabtypeButton 0
#define XIGrabtypeKeycode 1
commit bef7648827a0696debdd629472a45508a30144b1
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Jun 3 15:13:12 2011 +1000
Add XI2-specific defines for grab and property requests
XI 2.0 headers forced clients to mix XI2 specific constants with defines for
core input. Most notable here are the grab code which required GrabModeAsync
or GrabModeSync from core, but _not_ AnyModifier (XIAnymodifier !=
AnyModifier). This is a hard-to-debug cause for bugs.
Add defines for grab modes, grab return codes and property modes as well as
a define for the AnyPropertyType. These defines are identical to the ones
defined in core but stop the use of input-related defines from either core
or XI 1.x.
Clients must use the core defines None and CurrentTime where applicable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
diff --git a/XI2.h b/XI2.h
index 3c39946..43338a1 100644
--- a/XI2.h
+++ b/XI2.h
@@ -42,6 +42,14 @@
#define XIPropertyCreated 1
#define XIPropertyModified 2
+/* Property modes */
+#define XIPropModeReplace 0
+#define XIPropModePrepend 1
+#define XIPropModeAppend 2
+
+/* Special property type used for XIGetProperty */
+#define XIAnyPropertyType 0L
+
/* Enter/Leave and Focus In/Out modes */
#define XINotifyNormal 0
#define XINotifyGrab 1
@@ -60,6 +68,17 @@
#define XINotifyPointerRoot 6
#define XINotifyDetailNone 7
+/* Grab modes */
+#define XIGrabModeSync 0
+#define XIGrabModeAsync 1
+
+/* Grab reply status codes */
+#define XIGrabSuccess 0
+#define XIAlreadyGrabbed 1
+#define XIGrabInvalidTime 2
+#define XIGrabNotViewable 3
+#define XIGrabFrozen 4
+
/* Passive grab types */
#define XIGrabtypeButton 0
#define XIGrabtypeKeycode 1
commit b1149ab782619eaeadf70affd94239184e082d03
Author: Alexandre Julliard <julliard@winehq.org>
Date: Tue Apr 12 22:39:25 2011 +0200
XI2.h: Fix off-by-one error in the XIMaskLen definition.
The previous definition would give the wrong result for events that are
a multiple of 8.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
diff --git a/XI2.h b/XI2.h
index 6ba1377..3c39946 100644
--- a/XI2.h
+++ b/XI2.h
@@ -127,7 +127,7 @@
#define XISetMask(ptr, event) (((unsigned char*)(ptr))[(event)>>3] |= (1 << ((event) & 7)))
#define XIClearMask(ptr, event) (((unsigned char*)(ptr))[(event)>>3] &= ~(1 << ((event) & 7)))
#define XIMaskIsSet(ptr, event) (((unsigned char*)(ptr))[(event)>>3] & (1 << ((event) & 7)))
-#define XIMaskLen(event) (((event + 7) >> 3))
+#define XIMaskLen(event) (((event) >> 3) + 1)
/* Fake device ID's for event selection */
#define XIAllDevices 0
commit ab930a51047f48c7befd4316a9b116f37075697f
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Wed Mar 23 13:27:02 2011 +1000
specs: enable asciidoc parsing for XIproto.txt
The vast majority of this patch are indentation changes, removing preceding
spaces from text.
Header lines and some linebreaks to enable list parsing were added.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Gaetan Nadon <memsize@videotron.ca>
diff --git a/specs/Makefile.am b/specs/Makefile.am
index ad51453..a83cf40 100644
--- a/specs/Makefile.am
+++ b/specs/Makefile.am
@@ -2,15 +2,13 @@
if ENABLE_SPECS
if HAVE_ASCIIDOC
-doc_DATA = XI2proto.html
-dist_doc_DATA = XI2proto.txt
+doc_DATA = XI2proto.html XIproto.html
+dist_doc_DATA = XI2proto.txt XIproto.txt
%.html: %.txt
$(AM_V_GEN)$(ASCIIDOC) -o $@ $<
CLEANFILES = $(doc_DATA)
-EXTRA_DIST = XIproto.txt
-
endif
endif
diff --git a/specs/XIproto.txt b/specs/XIproto.txt
index 35ab1c9..1095a26 100644
--- a/specs/XIproto.txt
+++ b/specs/XIproto.txt
@@ -1,4 +1,6 @@
- X11 Input Extension Protocol Specification
+X11 Input Extension Protocol Specification
+==========================================
+
Version 1.0
X Consortium Standard
X Version 11, Release 6.8
@@ -72,154 +74,160 @@
OTHER DEALINGS IN THE SOFTWARE.
1. Input Extension Overview
-
- This document defines an extension to the X11 protocol to
- support input devices other than the core X keyboard and
- pointer. An accompanying document defines a corresponding
- extension to Xlib (similar extensions for languages other than
- C are anticipated). This first section gives an overview of the
- input extension. The next section defines the new protocol
- requests defined by the extension. We conclude with a
- description of the new input events generated by the additional
- input devices.
-
- This document only describes the behaviour of servers supporting
- up to the X Input Extension 1.5. For servers supporting the X
- Input Extensions 2.0, see XI2proto.txt. New clients are discouraged
- from using this protocol specification. Instead, the use of XI 2.x
- is recommended.
+---------------------------
+
+This document defines an extension to the X11 protocol to
+support input devices other than the core X keyboard and
+pointer. An accompanying document defines a corresponding
+extension to Xlib (similar extensions for languages other than
+C are anticipated). This first section gives an overview of the
+input extension. The next section defines the new protocol
+requests defined by the extension. We conclude with a
+description of the new input events generated by the additional
+input devices.
+
+This document only describes the behaviour of servers supporting
+up to the X Input Extension 1.5. For servers supporting the X
+Input Extensions 2.0, see XI2proto.txt. New clients are discouraged
+from using this protocol specification. Instead, the use of XI 2.x
+is recommended.
1.1 Design Approach
+~~~~~~~~~~~~~~~~~~~
- The design approach of the extension is to define requests and
- events analogous to the core requests and events. This allows
- extension input devices to be individually distinguishable from
- each other and from the core input devices. These requests and
- events make use of a device identifier and support the
- reporting of n-dimensional motion data as well as other data
- that is not reportable via the core input events.
+The design approach of the extension is to define requests and
+events analogous to the core requests and events. This allows
+extension input devices to be individually distinguishable from
+each other and from the core input devices. These requests and
+events make use of a device identifier and support the
+reporting of n-dimensional motion data as well as other data
+that is not reportable via the core input events.
1.2 Core Input Devices
-
- The X server core protocol supports two input devices: a
- pointer and a keyboard. The pointer device has two major
- functions. First, it may be used to generate motion information
- that client programs can detect. Second, it may also be used to
- indicate the current location and focus of the X keyboard. To
- accomplish this, the server echoes a cursor at the current
- position of the X pointer. Unless the X keyboard has been
- explicitly focused, this cursor also shows the current location
- and focus of the X keyboard. The X keyboard is used to generate
- input that client programs can detect.
-
- In servers supporting XI 1.4 and above, the core pointer and
- the core keyboard are virtual devices that do not represent a
- physical device connected to the host computer.
- In servers supporting XI 2.0 and above, there may be multiple
- core pointers and keyboards. Refer to XI2proto.txt for more
- information.
-
- The X keyboard and X pointer are referred to in this document
- as the core devices, and the input events they generate
- (KeyPress, KeyRelease, ButtonPress, ButtonRelease, and
- MotionNotify) are known as the core input events. All other
- input devices are referred to as extension input devices and
- the input events they generate are referred to as extension
- input events.
-
Reply to: