From 51468f1607f0b88576628c89e85d159afbb4628e Mon Sep 17 00:00:00 2001 From: Kaleb Keithley Date: Fri, 14 Nov 2003 15:54:35 +0000 Subject: [PATCH 001/388] R6.6 is the Xorg base-line --- XI.h | 268 ++++++++++ XInput.h | 1209 ++++++++++++++++++++++++++++++++++++++++++ XIproto.h | 1513 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 2990 insertions(+) create mode 100644 XI.h create mode 100644 XInput.h create mode 100644 XIproto.h diff --git a/XI.h b/XI.h new file mode 100644 index 0000000..bb4cec1 --- /dev/null +++ b/XI.h @@ -0,0 +1,268 @@ +/* $Xorg: XI.h,v 1.4 2001/02/09 02:03:23 xorgcvs Exp $ */ + +/************************************************************ + +Copyright 1989, 1998 The Open Group + +Permission to use, copy, modify, distribute, and sell this software and its +documentation for any purpose is hereby granted without fee, provided that +the above copyright notice appear in all copies and that both that +copyright notice and this permission notice appear in supporting +documentation. + +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN +AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + +Except as contained in this notice, the name of The Open Group shall not be +used in advertising or otherwise to promote the sale, use or other dealings +in this Software without prior written authorization from The Open Group. + +Copyright 1989 by Hewlett-Packard Company, Palo Alto, California. + + All Rights Reserved + +Permission to use, copy, modify, and distribute this software and its +documentation for any purpose and without fee is hereby granted, +provided that the above copyright notice appear in all copies and that +both that copyright notice and this permission notice appear in +supporting documentation, and that the name of Hewlett-Packard not be +used in advertising or publicity pertaining to distribution of the +software without specific, written prior permission. + +HEWLETT-PACKARD DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING +ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL +HEWLETT-PACKARD BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR +ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, +WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS +SOFTWARE. + +********************************************************/ + +/* Definitions used by the server, library and client */ + +#ifndef _XI_H_ + +#define _XI_H_ + +#define sz_xGetExtensionVersionReq 8 +#define sz_xGetExtensionVersionReply 32 +#define sz_xListInputDevicesReq 4 +#define sz_xListInputDevicesReply 32 +#define sz_xOpenDeviceReq 8 +#define sz_xOpenDeviceReply 32 +#define sz_xCloseDeviceReq 8 +#define sz_xSetDeviceModeReq 8 +#define sz_xSetDeviceModeReply 32 +#define sz_xSelectExtensionEventReq 12 +#define sz_xGetSelectedExtensionEventsReq 8 +#define sz_xGetSelectedExtensionEventsReply 32 +#define sz_xChangeDeviceDontPropagateListReq 12 +#define sz_xGetDeviceDontPropagateListReq 8 +#define sz_xGetDeviceDontPropagateListReply 32 +#define sz_xGetDeviceMotionEventsReq 16 +#define sz_xGetDeviceMotionEventsReply 32 +#define sz_xChangeKeyboardDeviceReq 8 +#define sz_xChangeKeyboardDeviceReply 32 +#define sz_xChangePointerDeviceReq 8 +#define sz_xChangePointerDeviceReply 32 +#define sz_xGrabDeviceReq 20 +#define sz_xGrabDeviceReply 32 +#define sz_xUngrabDeviceReq 12 +#define sz_xGrabDeviceKeyReq 20 +#define sz_xGrabDeviceKeyReply 32 +#define sz_xUngrabDeviceKeyReq 16 +#define sz_xGrabDeviceButtonReq 20 +#define sz_xGrabDeviceButtonReply 32 +#define sz_xUngrabDeviceButtonReq 16 +#define sz_xAllowDeviceEventsReq 12 +#define sz_xGetDeviceFocusReq 8 +#define sz_xGetDeviceFocusReply 32 +#define sz_xSetDeviceFocusReq 16 +#define sz_xGetFeedbackControlReq 8 +#define sz_xGetFeedbackControlReply 32 +#define sz_xChangeFeedbackControlReq 12 +#define sz_xGetDeviceKeyMappingReq 8 +#define sz_xGetDeviceKeyMappingReply 32 +#define sz_xChangeDeviceKeyMappingReq 8 +#define sz_xGetDeviceModifierMappingReq 8 +#define sz_xSetDeviceModifierMappingReq 8 +#define sz_xSetDeviceModifierMappingReply 32 +#define sz_xGetDeviceButtonMappingReq 8 +#define sz_xGetDeviceButtonMappingReply 32 +#define sz_xSetDeviceButtonMappingReq 8 +#define sz_xSetDeviceButtonMappingReply 32 +#define sz_xQueryDeviceStateReq 8 +#define sz_xQueryDeviceStateReply 32 +#define sz_xSendExtensionEventReq 16 +#define sz_xDeviceBellReq 8 +#define sz_xSetDeviceValuatorsReq 8 +#define sz_xSetDeviceValuatorsReply 32 +#define sz_xGetDeviceControlReq 8 +#define sz_xGetDeviceControlReply 32 +#define sz_xChangeDeviceControlReq 8 +#define sz_xChangeDeviceControlReply 32 + +#define INAME "XInputExtension" + +#define XI_KEYBOARD "KEYBOARD" +#define XI_MOUSE "MOUSE" +#define XI_TABLET "TABLET" +#define XI_TOUCHSCREEN "TOUCHSCREEN" +#define XI_TOUCHPAD "TOUCHPAD" +#define XI_BARCODE "BARCODE" +#define XI_BUTTONBOX "BUTTONBOX" +#define XI_KNOB_BOX "KNOB_BOX" +#define XI_ONE_KNOB "ONE_KNOB" +#define XI_NINE_KNOB "NINE_KNOB" +#define XI_TRACKBALL "TRACKBALL" +#define XI_QUADRATURE "QUADRATURE" +#define XI_ID_MODULE "ID_MODULE" +#define XI_SPACEBALL "SPACEBALL" +#define XI_DATAGLOVE "DATAGLOVE" +#define XI_EYETRACKER "EYETRACKER" +#define XI_CURSORKEYS "CURSORKEYS" +#define XI_FOOTMOUSE "FOOTMOUSE" + +#define Dont_Check 0 +#define XInput_Initial_Release 1 +#define XInput_Add_XDeviceBell 2 +#define XInput_Add_XSetDeviceValuators 3 +#define XInput_Add_XChangeDeviceControl 4 + +#define XI_Absent 0 +#define XI_Present 1 + +#define XI_Initial_Release_Major 1 +#define XI_Initial_Release_Minor 0 + +#define XI_Add_XDeviceBell_Major 1 +#define XI_Add_XDeviceBell_Minor 1 + +#define XI_Add_XSetDeviceValuators_Major 1 +#define XI_Add_XSetDeviceValuators_Minor 2 + +#define XI_Add_XChangeDeviceControl_Major 1 +#define XI_Add_XChangeDeviceControl_Minor 3 + +#define DEVICE_RESOLUTION 1 + +#define NoSuchExtension 1 + +#define COUNT 0 +#define CREATE 1 + +#define NewPointer 0 +#define NewKeyboard 1 + +#define XPOINTER 0 +#define XKEYBOARD 1 + +#define UseXKeyboard 0xFF + +#define IsXPointer 0 +#define IsXKeyboard 1 +#define IsXExtensionDevice 2 + +#define AsyncThisDevice 0 +#define SyncThisDevice 1 +#define ReplayThisDevice 2 +#define AsyncOtherDevices 3 +#define AsyncAll 4 +#define SyncAll 5 + +#define FollowKeyboard 3 +#ifndef RevertToFollowKeyboard +#define RevertToFollowKeyboard 3 +#endif + +#define DvAccelNum (1L << 0) +#define DvAccelDenom (1L << 1) +#define DvThreshold (1L << 2) + +#define DvKeyClickPercent (1L<<0) +#define DvPercent (1L<<1) +#define DvPitch (1L<<2) +#define DvDuration (1L<<3) +#define DvLed (1L<<4) +#define DvLedMode (1L<<5) +#define DvKey (1L<<6) +#define DvAutoRepeatMode (1L<<7) + +#define DvString (1L << 0) + +#define DvInteger (1L << 0) + +#define DeviceMode (1L << 0) +#define Relative 0 +#define Absolute 1 + +#define ProximityState (1L << 1) +#define InProximity (0L << 1) +#define OutOfProximity (1L << 1) + +#define AddToList 0 +#define DeleteFromList 1 + +#define KeyClass 0 +#define ButtonClass 1 +#define ValuatorClass 2 +#define FeedbackClass 3 +#define ProximityClass 4 +#define FocusClass 5 +#define OtherClass 6 + +#define KbdFeedbackClass 0 +#define PtrFeedbackClass 1 +#define StringFeedbackClass 2 +#define IntegerFeedbackClass 3 +#define LedFeedbackClass 4 +#define BellFeedbackClass 5 + +#define _devicePointerMotionHint 0 +#define _deviceButton1Motion 1 +#define _deviceButton2Motion 2 +#define _deviceButton3Motion 3 +#define _deviceButton4Motion 4 +#define _deviceButton5Motion 5 +#define _deviceButtonMotion 6 +#define _deviceButtonGrab 7 +#define _deviceOwnerGrabButton 8 +#define _noExtensionEvent 9 + +#define XI_BadDevice 0 +#define XI_BadEvent 1 +#define XI_BadMode 2 +#define XI_DeviceBusy 3 +#define XI_BadClass 4 + +/* Make XEventClass be a CARD32 for 64 bit servers. Don't affect client + * definition of XEventClass since that would be a library interface change. + * See the top of X.h for more _XSERVER64 magic. + */ +#ifdef _XSERVER64 +typedef CARD32 XEventClass; +#else +typedef unsigned long XEventClass; +#endif + +/******************************************************************* + * + * Extension version structure. + * + */ + +typedef struct { + int present; + short major_version; + short minor_version; +} XExtensionVersion; + +#endif /* _XI_H_ */ diff --git a/XInput.h b/XInput.h new file mode 100644 index 0000000..2470377 --- /dev/null +++ b/XInput.h @@ -0,0 +1,1209 @@ +/* $Xorg: XInput.h,v 1.4 2001/02/09 02:03:23 xorgcvs Exp $ */ + +/************************************************************ + +Copyright 1989, 1998 The Open Group + +Permission to use, copy, modify, distribute, and sell this software and its +documentation for any purpose is hereby granted without fee, provided that +the above copyright notice appear in all copies and that both that +copyright notice and this permission notice appear in supporting +documentation. + +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN +AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + +Except as contained in this notice, the name of The Open Group shall not be +used in advertising or otherwise to promote the sale, use or other dealings +in this Software without prior written authorization from The Open Group. + +Copyright 1989 by Hewlett-Packard Company, Palo Alto, California. + + All Rights Reserved + +Permission to use, copy, modify, and distribute this software and its +documentation for any purpose and without fee is hereby granted, +provided that the above copyright notice appear in all copies and that +both that copyright notice and this permission notice appear in +supporting documentation, and that the name of Hewlett-Packard not be +used in advertising or publicity pertaining to distribution of the +software without specific, written prior permission. + +HEWLETT-PACKARD DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING +ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL +HEWLETT-PACKARD BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR +ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, +WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS +SOFTWARE. + +********************************************************/ + +/* Definitions used by the library and client */ + +#ifndef _XINPUT_H_ +#define _XINPUT_H_ + +#ifndef _XLIB_H_ +#include +#endif + +#ifndef _XI_H_ +#include "XI.h" +#endif + +#define _deviceKeyPress 0 +#define _deviceKeyRelease 1 + +#define _deviceButtonPress 0 +#define _deviceButtonRelease 1 + +#define _deviceMotionNotify 0 + +#define _deviceFocusIn 0 +#define _deviceFocusOut 1 + +#define _proximityIn 0 +#define _proximityOut 1 + +#define _deviceStateNotify 0 +#define _deviceMappingNotify 1 +#define _changeDeviceNotify 2 + +#define FindTypeAndClass(d,type,_class,classid,offset) \ + { int _i; XInputClassInfo *_ip; \ + type = 0; _class = 0; \ + for (_i=0, _ip= ((XDevice *) d)->classes; \ + _i< ((XDevice *) d)->num_classes; \ + _i++, _ip++) \ + if (_ip->input_class == classid) \ + {type = _ip->event_type_base + offset; \ + _class = ((XDevice *) d)->device_id << 8 | type;}} + +#define DeviceKeyPress(d,type,_class) \ + FindTypeAndClass(d, type, _class, KeyClass, _deviceKeyPress) + +#define DeviceKeyRelease(d,type,_class) \ + FindTypeAndClass(d, type, _class, KeyClass, _deviceKeyRelease) + +#define DeviceButtonPress(d,type,_class) \ + FindTypeAndClass(d, type, _class, ButtonClass, _deviceButtonPress) + +#define DeviceButtonRelease(d,type,_class) \ + FindTypeAndClass(d, type, _class, ButtonClass, _deviceButtonRelease) + +#define DeviceMotionNotify(d,type,_class) \ + FindTypeAndClass(d, type, _class, ValuatorClass, _deviceMotionNotify) + +#define DeviceFocusIn(d,type,_class) \ + FindTypeAndClass(d, type, _class, FocusClass, _deviceFocusIn) + +#define DeviceFocusOut(d,type,_class) \ + FindTypeAndClass(d, type, _class, FocusClass, _deviceFocusOut) + +#define ProximityIn(d,type,_class) \ + FindTypeAndClass(d, type, _class, ProximityClass, _proximityIn) + +#define ProximityOut(d,type,_class) \ + FindTypeAndClass(d, type, _class, ProximityClass, _proximityOut) + +#define DeviceStateNotify(d,type,_class) \ + FindTypeAndClass(d, type, _class, OtherClass, _deviceStateNotify) + +#define DeviceMappingNotify(d,type,_class) \ + FindTypeAndClass(d, type, _class, OtherClass, _deviceMappingNotify) + +#define ChangeDeviceNotify(d,type,_class) \ + FindTypeAndClass(d, type, _class, OtherClass, _changeDeviceNotify) + +#define DevicePointerMotionHint(d,type,_class) \ + { _class = ((XDevice *) d)->device_id << 8 | _devicePointerMotionHint;} + +#define DeviceButton1Motion(d,type,_class) \ + { _class = ((XDevice *) d)->device_id << 8 | _deviceButton1Motion;} + +#define DeviceButton2Motion(d,type,_class) \ + { _class = ((XDevice *) d)->device_id << 8 | _deviceButton2Motion;} + +#define DeviceButton3Motion(d,type,_class) \ + { _class = ((XDevice *) d)->device_id << 8 | _deviceButton3Motion;} + +#define DeviceButton4Motion(d,type, _class) \ + { _class = ((XDevice *) d)->device_id << 8 | _deviceButton4Motion;} + +#define DeviceButton5Motion(d,type,_class) \ + { _class = ((XDevice *) d)->device_id << 8 | _deviceButton5Motion;} + +#define DeviceButtonMotion(d,type, _class) \ + { _class = ((XDevice *) d)->device_id << 8 | _deviceButtonMotion;} + +#define DeviceOwnerGrabButton(d,type,_class) \ + { _class = ((XDevice *) d)->device_id << 8 | _deviceOwnerGrabButton;} + +#define DeviceButtonPressGrab(d,type,_class) \ + { _class = ((XDevice *) d)->device_id << 8 | _deviceButtonGrab;} + +#define NoExtensionEvent(d,type,_class) \ + { _class = ((XDevice *) d)->device_id << 8 | _noExtensionEvent;} + +#define BadDevice(dpy,error) _xibaddevice(dpy, &error) + +#define BadClass(dpy,error) _xibadclass(dpy, &error) + +#define BadEvent(dpy,error) _xibadevent(dpy, &error) + +#define BadMode(dpy,error) _xibadmode(dpy, &error) + +#define DeviceBusy(dpy,error) _xidevicebusy(dpy, &error) + +/*************************************************************** + * + * DeviceKey events. These events are sent by input devices that + * support input class Keys. + * The location of the X pointer is reported in the coordinate + * fields of the x,y and x_root,y_root fields. + * + */ + +typedef struct + { + int type; /* of event */ + unsigned long serial; /* # of last request processed */ + Bool send_event; /* true if from SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; /* "event" window reported relative to */ + XID deviceid; + Window root; /* root window event occured on */ + Window subwindow; /* child window */ + Time time; /* milliseconds */ + int x, y; /* x, y coordinates in event window */ + int x_root; /* coordinates relative to root */ + int y_root; /* coordinates relative to root */ + unsigned int state; /* key or button mask */ + unsigned int keycode; /* detail */ + Bool same_screen; /* same screen flag */ + unsigned int device_state; /* device key or button mask */ + unsigned char axes_count; + unsigned char first_axis; + int axis_data[6]; + } XDeviceKeyEvent; + +typedef XDeviceKeyEvent XDeviceKeyPressedEvent; +typedef XDeviceKeyEvent XDeviceKeyReleasedEvent; + +/******************************************************************* + * + * DeviceButton events. These events are sent by extension devices + * that support input class Buttons. + * + */ + +typedef struct { + int type; /* of event */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; /* "event" window reported relative to */ + XID deviceid; + Window root; /* root window that the event occured on */ + Window subwindow; /* child window */ + Time time; /* milliseconds */ + int x, y; /* x, y coordinates in event window */ + int x_root; /* coordinates relative to root */ + int y_root; /* coordinates relative to root */ + unsigned int state; /* key or button mask */ + unsigned int button; /* detail */ + Bool same_screen; /* same screen flag */ + unsigned int device_state; /* device key or button mask */ + unsigned char axes_count; + unsigned char first_axis; + int axis_data[6]; + } XDeviceButtonEvent; + +typedef XDeviceButtonEvent XDeviceButtonPressedEvent; +typedef XDeviceButtonEvent XDeviceButtonReleasedEvent; + +/******************************************************************* + * + * DeviceMotionNotify event. These events are sent by extension devices + * that support input class Valuators. + * + */ + +typedef struct + { + int type; /* of event */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; /* "event" window reported relative to */ + XID deviceid; + Window root; /* root window that the event occured on */ + Window subwindow; /* child window */ + Time time; /* milliseconds */ + int x, y; /* x, y coordinates in event window */ + int x_root; /* coordinates relative to root */ + int y_root; /* coordinates relative to root */ + unsigned int state; /* key or button mask */ + char is_hint; /* detail */ + Bool same_screen; /* same screen flag */ + unsigned int device_state; /* device key or button mask */ + unsigned char axes_count; + unsigned char first_axis; + int axis_data[6]; + } XDeviceMotionEvent; + +/******************************************************************* + * + * DeviceFocusChange events. These events are sent when the focus + * of an extension device that can be focused is changed. + * + */ + +typedef struct + { + int type; /* of event */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; /* "event" window reported relative to */ + XID deviceid; + int mode; /* NotifyNormal, NotifyGrab, NotifyUngrab */ + int detail; + /* + * NotifyAncestor, NotifyVirtual, NotifyInferior, + * NotifyNonLinear,NotifyNonLinearVirtual, NotifyPointer, + * NotifyPointerRoot, NotifyDetailNone + */ + Time time; + } XDeviceFocusChangeEvent; + +typedef XDeviceFocusChangeEvent XDeviceFocusInEvent; +typedef XDeviceFocusChangeEvent XDeviceFocusOutEvent; + +/******************************************************************* + * + * ProximityNotify events. These events are sent by those absolute + * positioning devices that are capable of generating proximity information. + * + */ + +typedef struct + { + int type; /* ProximityIn or ProximityOut */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; + XID deviceid; + Window root; + Window subwindow; + Time time; + int x, y; + int x_root, y_root; + unsigned int state; + Bool same_screen; + unsigned int device_state; /* device key or button mask */ + unsigned char axes_count; + unsigned char first_axis; + int axis_data[6]; + } XProximityNotifyEvent; +typedef XProximityNotifyEvent XProximityInEvent; +typedef XProximityNotifyEvent XProximityOutEvent; + +/******************************************************************* + * + * DeviceStateNotify events are generated on EnterWindow and FocusIn + * for those clients who have selected DeviceState. + * + */ + +typedef struct + { +#if defined(__cplusplus) || defined(c_plusplus) + unsigned char c_class; +#else + unsigned char class; +#endif + unsigned char length; + } XInputClass; + +typedef struct { + int type; + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; + XID deviceid; + Time time; + int num_classes; + char data[64]; +} XDeviceStateNotifyEvent; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + unsigned char c_class; +#else + unsigned char class; +#endif + unsigned char length; + unsigned char num_valuators; + unsigned char mode; + int valuators[6]; +} XValuatorStatus; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + unsigned char c_class; +#else + unsigned char class; +#endif + unsigned char length; + short num_keys; + char keys[32]; +} XKeyStatus; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + unsigned char c_class; +#else + unsigned char class; +#endif + unsigned char length; + short num_buttons; + char buttons[32]; +} XButtonStatus; + +/******************************************************************* + * + * DeviceMappingNotify event. This event is sent when the key mapping, + * modifier mapping, or button mapping of an extension device is changed. + * + */ + +typedef struct { + int type; + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; /* unused */ + XID deviceid; + Time time; + int request; /* one of MappingModifier, MappingKeyboard, + MappingPointer */ + int first_keycode;/* first keycode */ + int count; /* defines range of change w. first_keycode*/ +} XDeviceMappingEvent; + +/******************************************************************* + * + * ChangeDeviceNotify event. This event is sent when an + * XChangeKeyboard or XChangePointer request is made. + * + */ + +typedef struct { + int type; + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; /* unused */ + XID deviceid; + Time time; + int request; /* NewPointer or NewKeyboard */ +} XChangeDeviceNotifyEvent; + +/******************************************************************* + * + * Control structures for input devices that support input class + * Feedback. These are used by the XGetFeedbackControl and + * XChangeFeedbackControl functions. + * + */ + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + XID id; +} XFeedbackState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + XID id; + int click; + int percent; + int pitch; + int duration; + int led_mask; + int global_auto_repeat; + char auto_repeats[32]; +} XKbdFeedbackState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + XID id; + int accelNum; + int accelDenom; + int threshold; +} XPtrFeedbackState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + XID id; + int resolution; + int minVal; + int maxVal; +} XIntegerFeedbackState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + XID id; + int max_symbols; + int num_syms_supported; + KeySym *syms_supported; +} XStringFeedbackState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + XID id; + int percent; + int pitch; + int duration; +} XBellFeedbackState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + XID id; + int led_values; + int led_mask; +} XLedFeedbackState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + XID id; +} XFeedbackControl; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + XID id; + int accelNum; + int accelDenom; + int threshold; +} XPtrFeedbackControl; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + XID id; + int click; + int percent; + int pitch; + int duration; + int led_mask; + int led_value; + int key; + int auto_repeat_mode; +} XKbdFeedbackControl; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + XID id; + int num_keysyms; + KeySym *syms_to_display; +} XStringFeedbackControl; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + XID id; + int int_to_display; +} XIntegerFeedbackControl; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + XID id; + int percent; + int pitch; + int duration; +} XBellFeedbackControl; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + XID id; + int led_mask; + int led_values; +} XLedFeedbackControl; + +/******************************************************************* + * + * Device control structures. + * + */ + +typedef struct { + XID control; + int length; +} XDeviceControl; + +typedef struct { + XID control; + int length; + int first_valuator; + int num_valuators; + int *resolutions; +} XDeviceResolutionControl; + +typedef struct { + XID control; + int length; + int num_valuators; + int *resolutions; + int *min_resolutions; + int *max_resolutions; +} XDeviceResolutionState; + +/******************************************************************* + * + * An array of XDeviceList structures is returned by the + * XListInputDevices function. Each entry contains information + * about one input device. Among that information is an array of + * pointers to structures that describe the characteristics of + * the input device. + * + */ + +typedef struct _XAnyClassinfo *XAnyClassPtr; + +typedef struct _XAnyClassinfo { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + } XAnyClassInfo; + +typedef struct _XDeviceInfo *XDeviceInfoPtr; + +typedef struct _XDeviceInfo + { + XID id; + Atom type; + char *name; + int num_classes; + int use; + XAnyClassPtr inputclassinfo; + } XDeviceInfo; + +typedef struct _XKeyInfo *XKeyInfoPtr; + +typedef struct _XKeyInfo + { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + unsigned short min_keycode; + unsigned short max_keycode; + unsigned short num_keys; + } XKeyInfo; + +typedef struct _XButtonInfo *XButtonInfoPtr; + +typedef struct _XButtonInfo { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + short num_buttons; + } XButtonInfo; + +typedef struct _XAxisInfo *XAxisInfoPtr; + +typedef struct _XAxisInfo { + int resolution; + int min_value; + int max_value; + } XAxisInfo; + +typedef struct _XValuatorInfo *XValuatorInfoPtr; + +typedef struct _XValuatorInfo + { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + unsigned char num_axes; + unsigned char mode; + unsigned long motion_buffer; + XAxisInfoPtr axes; + } XValuatorInfo; + + +/******************************************************************* + * + * An XDevice structure is returned by the XOpenDevice function. + * It contains an array of pointers to XInputClassInfo structures. + * Each contains information about a class of input supported by the + * device, including a pointer to an array of data for each type of event + * the device reports. + * + */ + + +typedef struct { + unsigned char input_class; + unsigned char event_type_base; +} XInputClassInfo; + +typedef struct { + XID device_id; + int num_classes; + XInputClassInfo *classes; +} XDevice; + + +/******************************************************************* + * + * The following structure is used to return information for the + * XGetSelectedExtensionEvents function. + * + */ + +typedef struct { + XEventClass event_type; + XID device; +} XEventList; + +/******************************************************************* + * + * The following structure is used to return motion history data from + * an input device that supports the input class Valuators. + * This information is returned by the XGetDeviceMotionEvents function. + * + */ + +typedef struct { + Time time; + int *data; +} XDeviceTimeCoord; + + +/******************************************************************* + * + * Device state structure. + * This is returned by the XQueryDeviceState request. + * + */ + +typedef struct { + XID device_id; + int num_classes; + XInputClass *data; +} XDeviceState; + +/******************************************************************* + * + * Note that the mode field is a bitfield that reports the Proximity + * status of the device as well as the mode. The mode field should + * be OR'd with the mask DeviceMode and compared with the values + * Absolute and Relative to determine the mode, and should be OR'd + * with the mask ProximityState and compared with the values InProximity + * and OutOfProximity to determine the proximity state. + * + */ + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + unsigned char c_class; +#else + unsigned char class; +#endif + unsigned char length; + unsigned char num_valuators; + unsigned char mode; + int *valuators; +} XValuatorState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + unsigned char c_class; +#else + unsigned char class; +#endif + unsigned char length; + short num_keys; + char keys[32]; +} XKeyState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + unsigned char c_class; +#else + unsigned char class; +#endif + unsigned char length; + short num_buttons; + char buttons[32]; +} XButtonState; + +/******************************************************************* + * + * Function definitions. + * + */ + +_XFUNCPROTOBEGIN + +extern int XChangeKeyboardDevice( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */ +#endif +); + +extern int XChangePointerDevice( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + int /* xaxis */, + int /* yaxis */ +#endif +); + +extern int XGrabDevice( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + Window /* grab_window */, + Bool /* ownerEvents */, + int /* event count */, + XEventClass* /* event_list */, + int /* this_device_mode */, + int /* other_devices_mode */, + Time /* time */ +#endif +); + +extern int XUngrabDevice( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + Time /* time */ +#endif +); + +extern int XGrabDeviceKey( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + unsigned int /* key */, + unsigned int /* modifiers */, + XDevice* /* modifier_device */, + Window /* grab_window */, + Bool /* owner_events */, + unsigned int /* event_count */, + XEventClass* /* event_list */, + int /* this_device_mode */, + int /* other_devices_mode */ +#endif +); + +extern int XUngrabDeviceKey( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + unsigned int /* key */, + unsigned int /* modifiers */, + XDevice* /* modifier_dev */, + Window /* grab_window */ +#endif +); + +extern int XGrabDeviceButton( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + unsigned int /* button */, + unsigned int /* modifiers */, + XDevice* /* modifier_device */, + Window /* grab_window */, + Bool /* owner_events */, + unsigned int /* event_count */, + XEventClass* /* event_list */, + int /* this_device_mode */, + int /* other_devices_mode */ +#endif +); + +extern int XUngrabDeviceButton( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + unsigned int /* button */, + unsigned int /* modifiers */, + XDevice* /* modifier_dev */, + Window /* grab_window */ +#endif +); + +extern int XAllowDeviceEvents( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + int /* event_mode */, + Time /* time */ +#endif +); + +extern int XGetDeviceFocus( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + Window* /* focus */, + int* /* revert_to */, + Time* /* time */ +#endif +); + +extern int XSetDeviceFocus( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + Window /* focus */, + int /* revert_to */, + Time /* time */ +#endif +); + +extern XFeedbackState *XGetFeedbackControl( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + int* /* num_feedbacks */ +#endif +); + +extern void XFreeFeedbackList( +#if NeedFunctionPrototypes + XFeedbackState* /* list */ +#endif +); + +extern int XChangeFeedbackControl( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + unsigned long /* mask */, + XFeedbackControl* /* f */ +#endif +); + +extern int XDeviceBell( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + XID /* feedbackclass */, + XID /* feedbackid */, + int /* percent */ +#endif +); + +extern KeySym *XGetDeviceKeyMapping( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, +#if NeedWidePrototypes + unsigned int /* first */, +#else + KeyCode /* first */, +#endif + int /* keycount */, + int* /* syms_per_code */ +#endif +); + +extern int XChangeDeviceKeyMapping( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + int /* first */, + int /* syms_per_code */, + KeySym* /* keysyms */, + int /* count */ +#endif +); + +extern XModifierKeymap *XGetDeviceModifierMapping( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */ +#endif +); + +extern int XSetDeviceModifierMapping( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + XModifierKeymap* /* modmap */ +#endif +); + +extern int XSetDeviceButtonMapping( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + unsigned char* /* map[] */, + int /* nmap */ +#endif +); + +extern int XGetDeviceButtonMapping( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + unsigned char* /* map[] */, + unsigned int /* nmap */ +#endif +); + +extern XDeviceState *XQueryDeviceState( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */ +#endif +); + +extern void XFreeDeviceState( +#if NeedFunctionPrototypes + XDeviceState* /* list */ +#endif +); + +extern XExtensionVersion *XGetExtensionVersion( +#if NeedFunctionPrototypes + Display* /* display */, + _Xconst char* /* name */ +#endif +); + +extern XDeviceInfo *XListInputDevices( +#if NeedFunctionPrototypes + Display* /* display */, + int* /* ndevices */ +#endif +); + +extern void XFreeDeviceList( +#if NeedFunctionPrototypes + XDeviceInfo* /* list */ +#endif +); + +extern XDevice *XOpenDevice( +#if NeedFunctionPrototypes + Display* /* display */, + XID /* id */ +#endif +); + +extern int XCloseDevice( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */ +#endif +); + +extern int XSetDeviceMode( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + int /* mode */ +#endif +); + +extern int XSetDeviceValuators( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + int* /* valuators */, + int /* first_valuator */, + int /* num_valuators */ +#endif +); + +extern XDeviceControl *XGetDeviceControl( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + int /* control */ +#endif +); + +extern int XChangeDeviceControl( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + int /* control */, + XDeviceControl* /* d */ +#endif +); + +extern int XSelectExtensionEvent( +#if NeedFunctionPrototypes + Display* /* display */, + Window /* w */, + XEventClass* /* event_list */, + int /* count */ +#endif +); + +extern int XGetSelectedExtensionEvents( +#if NeedFunctionPrototypes + Display* /* display */, + Window /* w */, + int* /* this_client_count */, + XEventClass** /* this_client_list */, + int* /* all_clients_count */, + XEventClass** /* all_clients_list */ +#endif +); + +extern int XChangeDeviceDontPropagateList( +#if NeedFunctionPrototypes + Display* /* display */, + Window /* window */, + int /* count */, + XEventClass* /* events */, + int /* mode */ +#endif +); + +extern XEventClass *XGetDeviceDontPropagateList( +#if NeedFunctionPrototypes + Display* /* display */, + Window /* window */, + int* /* count */ +#endif +); + +extern Status XSendExtensionEvent( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + Window /* dest */, + Bool /* prop */, + int /* count */, + XEventClass* /* list */, + XEvent* /* event */ +#endif +); + +extern XDeviceTimeCoord *XGetDeviceMotionEvents( +#if NeedFunctionPrototypes + Display* /* display */, + XDevice* /* device */, + Time /* start */, + Time /* stop */, + int* /* nEvents */, + int* /* mode */, + int* /* axis_count */ +#endif +); + +extern void XFreeDeviceMotionEvents( +#if NeedFunctionPrototypes + XDeviceTimeCoord* /* events */ +#endif +); + +extern void XFreeDeviceControl( +#if NeedFunctionPrototypes + XDeviceControl* /* control */ +#endif +); + +_XFUNCPROTOEND + +#endif /* _XINPUT_H_ */ diff --git a/XIproto.h b/XIproto.h new file mode 100644 index 0000000..f13d990 --- /dev/null +++ b/XIproto.h @@ -0,0 +1,1513 @@ +/* $Xorg: XIproto.h,v 1.5 2001/02/09 02:03:24 xorgcvs Exp $ */ + +/************************************************************ + +Copyright 1989, 1998 The Open Group + +Permission to use, copy, modify, distribute, and sell this software and its +documentation for any purpose is hereby granted without fee, provided that +the above copyright notice appear in all copies and that both that +copyright notice and this permission notice appear in supporting +documentation. + +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN +AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + +Except as contained in this notice, the name of The Open Group shall not be +used in advertising or otherwise to promote the sale, use or other dealings +in this Software without prior written authorization from The Open Group. + +Copyright 1989 by Hewlett-Packard Company, Palo Alto, California. + + All Rights Reserved + +Permission to use, copy, modify, and distribute this software and its +documentation for any purpose and without fee is hereby granted, +provided that the above copyright notice appear in all copies and that +both that copyright notice and this permission notice appear in +supporting documentation, and that the name of Hewlett-Packard not be +used in advertising or publicity pertaining to distribution of the +software without specific, written prior permission. + +HEWLETT-PACKARD DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING +ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL +HEWLETT-PACKARD BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR +ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, +WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS +SOFTWARE. + +********************************************************/ + +#ifndef _XIPROTO_H +#define _XIPROTO_H + +#include +#include + +/* make sure types have right sizes for protocol structures. */ +#define Window CARD32 +#define Time CARD32 +#define KeyCode CARD8 + +/********************************************************* + * + * number of events, errors, and extension name. + * + */ + +#define MORE_EVENTS 0x80 +#define DEVICE_BITS 0x7F + +#define InputClassBits 0x3F /* bits in mode field for input classes */ +#define ModeBitsShift 6 /* amount to shift the remaining bits */ + +#define numInputClasses 7 + +#define IEVENTS 15 +#define IERRORS 5 + +#define CLIENT_REQ 1 + +typedef struct _XExtEventInfo + { + Mask mask; + BYTE type; + BYTE word; + } XExtEventInfo; + +typedef unsigned char *Pointer; + +struct tmask + { + Mask mask; + Pointer dev; + }; + +/********************************************************* + * + * Event constants used by library. + * + */ + +#define XI_DeviceValuator 0 +#define XI_DeviceKeyPress 1 +#define XI_DeviceKeyRelease 2 +#define XI_DeviceButtonPress 3 +#define XI_DeviceButtonRelease 4 +#define XI_DeviceMotionNotify 5 +#define XI_DeviceFocusIn 6 +#define XI_DeviceFocusOut 7 +#define XI_ProximityIn 8 +#define XI_ProximityOut 9 +#define XI_DeviceStateNotify 10 +#define XI_DeviceMappingNotify 11 +#define XI_ChangeDeviceNotify 12 +#define XI_DeviceKeystateNotify 13 +#define XI_DeviceButtonstateNotify 14 + +/********************************************************* + * + * Protocol request constants + * + */ + +#define X_GetExtensionVersion 1 +#define X_ListInputDevices 2 +#define X_OpenDevice 3 +#define X_CloseDevice 4 +#define X_SetDeviceMode 5 +#define X_SelectExtensionEvent 6 +#define X_GetSelectedExtensionEvents 7 +#define X_ChangeDeviceDontPropagateList 8 +#define X_GetDeviceDontPropagateList 9 +#define X_GetDeviceMotionEvents 10 +#define X_ChangeKeyboardDevice 11 +#define X_ChangePointerDevice 12 +#define X_GrabDevice 13 +#define X_UngrabDevice 14 +#define X_GrabDeviceKey 15 +#define X_UngrabDeviceKey 16 +#define X_GrabDeviceButton 17 +#define X_UngrabDeviceButton 18 +#define X_AllowDeviceEvents 19 +#define X_GetDeviceFocus 20 +#define X_SetDeviceFocus 21 +#define X_GetFeedbackControl 22 +#define X_ChangeFeedbackControl 23 +#define X_GetDeviceKeyMapping 24 +#define X_ChangeDeviceKeyMapping 25 +#define X_GetDeviceModifierMapping 26 +#define X_SetDeviceModifierMapping 27 +#define X_GetDeviceButtonMapping 28 +#define X_SetDeviceButtonMapping 29 +#define X_QueryDeviceState 30 +#define X_SendExtensionEvent 31 +#define X_DeviceBell 32 +#define X_SetDeviceValuators 33 +#define X_GetDeviceControl 34 +#define X_ChangeDeviceControl 35 + +/********************************************************* + * + * Protocol request and reply structures. + * + * GetExtensionVersion. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GetExtensionVersion */ + CARD16 length B16; + CARD16 nbytes B16; + CARD8 pad1, pad2; +} xGetExtensionVersionReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetExtensionVersion */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD16 major_version B16; + CARD16 minor_version B16; + BOOL present; + CARD8 pad1, pad2, pad3; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; +} xGetExtensionVersionReply; + +/********************************************************* + * + * ListInputDevices. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_ListInputDevices */ + CARD16 length B16; +} xListInputDevicesReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_ListInputDevices */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 ndevices; + CARD8 pad1, pad2, pad3; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; +} xListInputDevicesReply; + +typedef struct _xDeviceInfo *xDeviceInfoPtr; + +typedef struct _xAnyClassinfo *xAnyClassPtr; + +typedef struct _xAnyClassinfo { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; +#else + CARD8 class; +#endif + CARD8 length; + } xAnyClassInfo; + +typedef struct _xDeviceInfo { + CARD32 type B32; + CARD8 id; + CARD8 num_classes; + CARD8 use; + CARD8 pad1; + } xDeviceInfo; + +typedef struct _xKeyInfo *xKeyInfoPtr; + +typedef struct _xKeyInfo { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; +#else + CARD8 class; +#endif + CARD8 length; + KeyCode min_keycode; + KeyCode max_keycode; + CARD16 num_keys B16; + CARD8 pad1,pad2; + } xKeyInfo; + +typedef struct _xButtonInfo *xButtonInfoPtr; + +typedef struct _xButtonInfo { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; +#else + CARD8 class; +#endif + CARD8 length; + CARD16 num_buttons B16; + } xButtonInfo; + +typedef struct _xValuatorInfo *xValuatorInfoPtr; + +typedef struct _xValuatorInfo { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; +#else + CARD8 class; +#endif + CARD8 length; + CARD8 num_axes; + CARD8 mode; + CARD32 motion_buffer_size B32; + } xValuatorInfo; + +typedef struct _xAxisInfo *xAxisInfoPtr; + +typedef struct _xAxisInfo { + CARD32 resolution B32; + CARD32 min_value B32; + CARD32 max_value B32; + } xAxisInfo; + +/********************************************************* + * + * OpenDevice. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_OpenDevice */ + CARD16 length B16; + CARD8 deviceid; + BYTE pad1, pad2, pad3; +} xOpenDeviceReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_OpenDevice */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 num_classes; + BYTE pad1, pad2, pad3; + CARD32 pad00 B32; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + } xOpenDeviceReply; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; +#else + CARD8 class; +#endif + CARD8 event_type_base; + } xInputClassInfo; + +/********************************************************* + * + * CloseDevice. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_CloseDevice */ + CARD16 length B16; + CARD8 deviceid; + BYTE pad1, pad2, pad3; +} xCloseDeviceReq; + +/********************************************************* + * + * SetDeviceMode. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_SetDeviceMode */ + CARD16 length B16; + CARD8 deviceid; + CARD8 mode; + BYTE pad1, pad2; +} xSetDeviceModeReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_SetDeviceMode */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 status; + BYTE pad1, pad2, pad3; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; +} xSetDeviceModeReply; + +/********************************************************* + * + * SelectExtensionEvent. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_SelectExtensionEvent */ + CARD16 length B16; + Window window B32; + CARD16 count B16; + CARD16 pad00 B16; +} xSelectExtensionEventReq; + +/********************************************************* + * + * GetSelectedExtensionEvent. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* X_GetSelectedExtensionEvents */ + CARD16 length B16; + Window window B32; +} xGetSelectedExtensionEventsReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* GetSelectedExtensionEvents */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD16 this_client_count B16; + CARD16 all_clients_count B16; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; +} xGetSelectedExtensionEventsReply; + +/********************************************************* + * + * ChangeDeviceDontPropagateList. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* X_ChangeDeviceDontPropagateList */ + CARD16 length B16; + Window window B32; + CARD16 count B16; + CARD8 mode; + BYTE pad; +} xChangeDeviceDontPropagateListReq; + +/********************************************************* + * + * GetDeviceDontPropagateList. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* X_GetDeviceDontPropagateList */ + CARD16 length B16; + Window window B32; +} xGetDeviceDontPropagateListReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* GetDeviceDontPropagateList */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD16 count B16; + CARD16 pad00 B16; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; + } xGetDeviceDontPropagateListReply; + +/********************************************************* + * + * GetDeviceMotionEvents. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GetDeviceMotionEvents*/ + CARD16 length B16; + Time start B32; + Time stop B32; + CARD8 deviceid; + BYTE pad1, pad2, pad3; +} xGetDeviceMotionEventsReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetDeviceMotionEvents */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD32 nEvents B32; + CARD8 axes; + CARD8 mode; + BYTE pad1, pad2; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; +} xGetDeviceMotionEventsReply; + +/********************************************************* + * + * ChangeKeyboardDevice. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* X_ChangeKeyboardDevice */ + CARD16 length B16; + CARD8 deviceid; + BYTE pad1, pad2, pad3; +} xChangeKeyboardDeviceReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_ChangeKeyboardDevice*/ + CARD16 sequenceNumber B16; + CARD32 length B32; /* 0 */ + CARD8 status; + BYTE pad1, pad2, pad3; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; + } xChangeKeyboardDeviceReply; + +/********************************************************* + * + * ChangePointerDevice. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* X_ChangePointerDevice */ + CARD16 length B16; + CARD8 xaxis; + CARD8 yaxis; + CARD8 deviceid; + BYTE pad1; +} xChangePointerDeviceReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_ChangePointerDevice */ + CARD16 sequenceNumber B16; + CARD32 length B32; /* 0 */ + CARD8 status; + BYTE pad1, pad2, pad3; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; + } xChangePointerDeviceReply; + +/********************************************************* + * + * GrabDevice. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GrabDevice */ + CARD16 length B16; + Window grabWindow B32; + Time time B32; + CARD16 event_count B16; + CARD8 this_device_mode; + CARD8 other_devices_mode; + BOOL ownerEvents; + CARD8 deviceid; + CARD16 pad01 B16; +} xGrabDeviceReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GrabDevice */ + CARD16 sequenceNumber B16; + CARD32 length B32; /* 0 */ + CARD8 status; + BYTE pad1, pad2, pad3; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; + } xGrabDeviceReply; + +/********************************************************* + * + * UngrabDevice. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_UnGrabDevice */ + CARD16 length B16; + Time time B32; + CARD8 deviceid; + BYTE pad1, pad2, pad3; +} xUngrabDeviceReq; + +/********************************************************* + * + * GrabDeviceKey. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GrabDeviceKey */ + CARD16 length B16; + Window grabWindow B32; + CARD16 event_count B16; + CARD16 modifiers B16; + CARD8 modifier_device; + CARD8 grabbed_device; + CARD8 key; + BYTE this_device_mode; + BYTE other_devices_mode; + BOOL ownerEvents; + BYTE pad1, pad2; +} xGrabDeviceKeyReq; + +/********************************************************* + * + * UngrabDeviceKey. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_UngrabDeviceKey */ + CARD16 length B16; + Window grabWindow B32; + CARD16 modifiers B16; + CARD8 modifier_device; + CARD8 key; + CARD8 grabbed_device; + BYTE pad1, pad2, pad3; +} xUngrabDeviceKeyReq; + +/********************************************************* + * + * GrabDeviceButton. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GrabDeviceButton */ + CARD16 length B16; + Window grabWindow B32; + CARD8 grabbed_device; + CARD8 modifier_device; + CARD16 event_count B16; + CARD16 modifiers B16; + BYTE this_device_mode; + BYTE other_devices_mode; + CARD8 button; + BOOL ownerEvents; + BYTE pad1, pad2; +} xGrabDeviceButtonReq; + +/********************************************************* + * + * UngrabDeviceButton. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_UngrabDeviceButton */ + CARD16 length B16; + Window grabWindow B32; + CARD16 modifiers B16; + CARD8 modifier_device; + CARD8 button; + CARD8 grabbed_device; + BYTE pad1, pad2, pad3; +} xUngrabDeviceButtonReq; + +/********************************************************* + * + * AllowDeviceEvents. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_AllowDeviceEvents */ + CARD16 length B16; + Time time B32; + CARD8 mode; + CARD8 deviceid; + BYTE pad1, pad2; +} xAllowDeviceEventsReq; + +/********************************************************* + * + * GetDeviceFocus. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GetDeviceFocus */ + CARD16 length B16; + CARD8 deviceid; + BYTE pad1, pad2, pad3; +} xGetDeviceFocusReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetDeviceFocus */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD32 focus B32; + Time time B32; + CARD8 revertTo; + BYTE pad1, pad2, pad3; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + } xGetDeviceFocusReply; + +/********************************************************* + * + * SetDeviceFocus. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_SetDeviceFocus */ + CARD16 length B16; + Window focus B32; + Time time B32; + CARD8 revertTo; + CARD8 device; + CARD16 pad01 B16; +} xSetDeviceFocusReq; + +/********************************************************* + * + * GetFeedbackControl. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* X_GetFeedbackControl */ + CARD16 length B16; + CARD8 deviceid; + BYTE pad1, pad2, pad3; +} xGetFeedbackControlReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetFeedbackControl */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD16 num_feedbacks B16; + CARD16 pad01 B16; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; + CARD32 pad06 B32; +} xGetFeedbackControlReply; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; /* feedback class */ +#else + CARD8 class; /* feedback class */ +#endif + CARD8 id; /* feedback id */ + CARD16 length B16; /* feedback length */ +} xFeedbackState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; +#else + CARD8 class; +#endif + CARD8 id; + CARD16 length B16; + CARD16 pitch B16; + CARD16 duration B16; + CARD32 led_mask B32; + CARD32 led_values B32; + BOOL global_auto_repeat; + CARD8 click; + CARD8 percent; + BYTE pad; + BYTE auto_repeats[32]; +} xKbdFeedbackState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; +#else + CARD8 class; +#endif + CARD8 id; + CARD16 length B16; + CARD8 pad1,pad2; + CARD16 accelNum B16; + CARD16 accelDenom B16; + CARD16 threshold B16; +} xPtrFeedbackState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; /* feedback class id */ +#else + CARD8 class; /* feedback class id */ +#endif + CARD8 id; + CARD16 length B16; /* feedback length */ + CARD32 resolution B32; + INT32 min_value B32; + INT32 max_value B32; +} xIntegerFeedbackState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; /* feedback class id */ +#else + CARD8 class; /* feedback class id */ +#endif + CARD8 id; + CARD16 length B16; /* feedback length */ + CARD16 max_symbols B16; + CARD16 num_syms_supported B16; +} xStringFeedbackState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; /* feedback class id */ +#else + CARD8 class; /* feedback class id */ +#endif + CARD8 id; + CARD16 length B16; /* feedback length */ + CARD8 percent; + BYTE pad1, pad2, pad3; + CARD16 pitch B16; + CARD16 duration B16; +} xBellFeedbackState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; /* feedback class id */ +#else + CARD8 class; /* feedback class id */ +#endif + CARD8 id; + CARD16 length B16; /* feedback length */ + CARD32 led_mask B32; + CARD32 led_values B32; +} xLedFeedbackState; + +/********************************************************* + * + * ChangeFeedbackControl. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* X_ChangeFeedbackControl */ + CARD16 length B16; + CARD32 mask B32; + CARD8 deviceid; + CARD8 feedbackid; + BYTE pad1, pad2; +} xChangeFeedbackControlReq; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; /* feedback class id */ +#else + CARD8 class; /* feedback class id */ +#endif + CARD8 id; /* feedback id */ + CARD16 length B16; /* feedback length */ +} xFeedbackCtl; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; /* feedback class id */ +#else + CARD8 class; /* feedback class id */ +#endif + CARD8 id; /* feedback length */ + CARD16 length B16; /* feedback length */ + KeyCode key; + CARD8 auto_repeat_mode; + INT8 click; + INT8 percent; + INT16 pitch B16; + INT16 duration B16; + CARD32 led_mask B32; + CARD32 led_values B32; +} xKbdFeedbackCtl; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; /* feedback class id */ +#else + CARD8 class; /* feedback class id */ +#endif + CARD8 id; /* feedback id */ + CARD16 length B16; /* feedback length */ + CARD8 pad1,pad2; + INT16 num B16; + INT16 denom B16; + INT16 thresh B16; +} xPtrFeedbackCtl; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; /* feedback class id */ +#else + CARD8 class; /* feedback class id */ +#endif + CARD8 id; /* feedback id */ + CARD16 length B16; /* feedback length */ + INT32 int_to_display B32; +} xIntegerFeedbackCtl; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; /* feedback class id */ +#else + CARD8 class; /* feedback class id */ +#endif + CARD8 id; /* feedback id */ + CARD16 length B16; /* feedback length */ + CARD8 pad1,pad2; + CARD16 num_keysyms B16; +} xStringFeedbackCtl; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; /* feedback class id */ +#else + CARD8 class; /* feedback class id */ +#endif + CARD8 id; /* feedback id */ + CARD16 length B16; /* feedback length */ + INT8 percent; + BYTE pad1, pad2, pad3; + INT16 pitch B16; + INT16 duration B16; +} xBellFeedbackCtl; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; /* feedback class id */ +#else + CARD8 class; /* feedback class id */ +#endif + CARD8 id; /* feedback id */ + CARD16 length B16; /* feedback length */ + CARD32 led_mask B32; + CARD32 led_values B32; +} xLedFeedbackCtl; + +/********************************************************* + * + * GetDeviceKeyMapping. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GetDeviceKeyMapping */ + CARD16 length B16; + CARD8 deviceid; + KeyCode firstKeyCode; + CARD8 count; + BYTE pad1; +} xGetDeviceKeyMappingReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetDeviceKeyMapping */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 keySymsPerKeyCode; + CARD8 pad0; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; +} xGetDeviceKeyMappingReply; + +/********************************************************* + * + * ChangeDeviceKeyMapping. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_ChangeDeviceKeyMapping */ + CARD16 length B16; + CARD8 deviceid; + KeyCode firstKeyCode; + CARD8 keySymsPerKeyCode; + CARD8 keyCodes; +} xChangeDeviceKeyMappingReq; + +/********************************************************* + * + * GetDeviceModifierMapping. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GetDeviceModifierMapping */ + CARD16 length B16; + CARD8 deviceid; + BYTE pad1, pad2, pad3; +} xGetDeviceModifierMappingReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetDeviceModifierMapping */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 numKeyPerModifier; + CARD8 pad0; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; +} xGetDeviceModifierMappingReply; + +/********************************************************* + * + * SetDeviceModifierMapping. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_SetDeviceModifierMapping */ + CARD16 length B16; + CARD8 deviceid; + CARD8 numKeyPerModifier; + CARD16 pad1 B16; +} xSetDeviceModifierMappingReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_SetDeviceModifierMapping */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 success; + CARD8 pad0; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; +} xSetDeviceModifierMappingReply; + +/********************************************************* + * + * GetDeviceButtonMapping. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* X_GetDeviceButtonMapping */ + CARD16 length B16; + CARD8 deviceid; + BYTE pad1, pad2, pad3; +} xGetDeviceButtonMappingReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetDeviceButtonMapping */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 nElts; + BYTE pad1, pad2, pad3; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; +} xGetDeviceButtonMappingReply; + +/********************************************************* + * + * SetDeviceButtonMapping. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* X_SetDeviceButtonMapping */ + CARD16 length B16; + CARD8 deviceid; + CARD8 map_length; + BYTE pad1, pad2; +} xSetDeviceButtonMappingReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_SetDeviceButtonMapping */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 status; + BYTE pad0; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; +} xSetDeviceButtonMappingReply; + +/********************************************************* + * + * QueryDeviceState. + * + */ + +typedef struct { + CARD8 reqType; + CARD8 ReqType; /* always X_QueryDeviceState */ + CARD16 length B16; + CARD8 deviceid; + BYTE pad1, pad2, pad3; +} xQueryDeviceStateReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_QueryDeviceState */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 num_classes; + BYTE pad0; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; +} xQueryDeviceStateReply; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; +#else + CARD8 class; +#endif + CARD8 length; + CARD8 num_keys; + BYTE pad1; + CARD8 keys[32]; +} xKeyState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; +#else + CARD8 class; +#endif + CARD8 length; + CARD8 num_buttons; + BYTE pad1; + CARD8 buttons[32]; +} xButtonState; + +typedef struct { +#if defined(__cplusplus) || defined(c_plusplus) + CARD8 c_class; +#else + CARD8 class; +#endif + CARD8 length; + CARD8 num_valuators; + CARD8 mode; +} xValuatorState; + +/********************************************************* + * + * SendExtensionEvent. + * THIS REQUEST MUST BE KEPT A MULTIPLE OF 8 BYTES IN LENGTH! + * MORE EVENTS MAY FOLLOW AND THEY MUST BE QUAD-ALIGNED! + * + */ + +typedef struct { + CARD8 reqType; + CARD8 ReqType; /* always X_SendExtensionEvent */ + CARD16 length B16; + Window destination B32; + CARD8 deviceid; + BOOL propagate; + CARD16 count B16; + CARD8 num_events; + BYTE pad1,pad2,pad3; +} xSendExtensionEventReq; + +/********************************************************* + * + * DeviceBell. + * + */ + +typedef struct { + CARD8 reqType; + CARD8 ReqType; /* always X_DeviceBell */ + CARD16 length B16; + CARD8 deviceid; + CARD8 feedbackid; + CARD8 feedbackclass; + INT8 percent; +} xDeviceBellReq; + +/********************************************************* + * + * SetDeviceValuators. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_SetDeviceValuators */ + CARD16 length B16; + CARD8 deviceid; + CARD8 first_valuator; + CARD8 num_valuators; + BYTE pad1; +} xSetDeviceValuatorsReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_SetDeviceValuators */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 status; + BYTE pad1, pad2, pad3; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; +} xSetDeviceValuatorsReply; + +/********************************************************* + * + * GetDeviceControl. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GetDeviceControl */ + CARD16 length B16; + CARD16 control B16; + CARD8 deviceid; + BYTE pad2; +} xGetDeviceControlReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetDeviceControl */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 status; + BYTE pad1, pad2, pad3; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; +} xGetDeviceControlReply; + +typedef struct { + CARD16 control B16; /* control type */ + CARD16 length B16; /* control length */ +} xDeviceState; + +typedef struct { + CARD16 control B16; /* control type */ + CARD16 length B16; /* control length */ + CARD32 num_valuators B32; /* number of valuators */ +} xDeviceResolutionState; + +/********************************************************* + * + * ChangeDeviceControl. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_ChangeDeviceControl */ + CARD16 length B16; + CARD16 control B16; + CARD8 deviceid; + BYTE pad0; +} xChangeDeviceControlReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_ChangeDeviceControl */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 status; + BYTE pad1, pad2, pad3; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; +} xChangeDeviceControlReply; + +typedef struct { + CARD16 control B16; /* control type */ + CARD16 length B16; /* control length */ +} xDeviceCtl; + +typedef struct { + CARD16 control B16; /* control type */ + CARD16 length B16; /* control length */ + CARD8 first_valuator; /* first valuator to change */ + CARD8 num_valuators; /* number of valuators to change*/ + CARD8 pad1,pad2; +} xDeviceResolutionCtl; + +/********************************************************** + * + * Input extension events. + * + * DeviceValuator + * + */ + +typedef struct + { + BYTE type; + CARD8 deviceid; + CARD16 sequenceNumber B16; + KeyButMask device_state B16; + CARD8 num_valuators; + CARD8 first_valuator; + INT32 valuator0 B32; + INT32 valuator1 B32; + INT32 valuator2 B32; + INT32 valuator3 B32; + INT32 valuator4 B32; + INT32 valuator5 B32; + } deviceValuator; + +/********************************************************** + * + * DeviceKeyButtonPointer. + * + * Used for: DeviceKeyPress, DeviceKeyRelease, + * DeviceButtonPress, DeviceButtonRelease, + * ProximityIn, ProximityOut + * DeviceMotionNotify, + * + */ + +typedef struct + { + BYTE type; + BYTE detail; + CARD16 sequenceNumber B16; + Time time B32; + Window root B32; + Window event B32; + Window child B32; + INT16 root_x B16; + INT16 root_y B16; + INT16 event_x B16; + INT16 event_y B16; + KeyButMask state B16; + BOOL same_screen; + CARD8 deviceid; + } deviceKeyButtonPointer; + +/********************************************************** + * + * DeviceFocus. + * + */ + +typedef struct + { + BYTE type; + BYTE detail; + CARD16 sequenceNumber B16; + Time time B32; + Window window B32; + BYTE mode; + CARD8 deviceid; + BYTE pad1, pad2; + CARD32 pad00 B32; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + } deviceFocus; + +/********************************************************** + * + * DeviceStateNotify. + * + * Note that the two high-order bits in the classes_reported + * field are the proximity state (InProximity or OutOfProximity), + * and the device mode (Absolute or Relative), respectively. + * + */ + +typedef struct + { + BYTE type; + BYTE deviceid; + CARD16 sequenceNumber B16; + Time time B32; + CARD8 num_keys; + CARD8 num_buttons; + CARD8 num_valuators; + CARD8 classes_reported; + CARD8 buttons[4]; + CARD8 keys[4]; + INT32 valuator0 B32; + INT32 valuator1 B32; + INT32 valuator2 B32; + } deviceStateNotify; + +/********************************************************** + * + * DeviceKeyStateNotify. + * + */ + +typedef struct + { + BYTE type; + BYTE deviceid; + CARD16 sequenceNumber B16; + CARD8 keys[28]; + } deviceKeyStateNotify; + +/********************************************************** + * + * DeviceButtonStateNotify. + * + */ + +typedef struct + { + BYTE type; + BYTE deviceid; + CARD16 sequenceNumber B16; + CARD8 buttons[28]; + } deviceButtonStateNotify; + +/********************************************************** + * + * DeviceMappingNotify. + * Fields must be kept in sync with core mappingnotify event. + * + */ + +typedef struct + { + BYTE type; + BYTE deviceid; + CARD16 sequenceNumber B16; + CARD8 request; + KeyCode firstKeyCode; + CARD8 count; + BYTE pad1; + Time time B32; + CARD32 pad00 B32; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + } deviceMappingNotify; + +/********************************************************** + * + * ChangeDeviceNotify. + * + */ + +typedef struct + { + BYTE type; + BYTE deviceid; + CARD16 sequenceNumber B16; + Time time B32; + CARD8 request; + BYTE pad1, pad2, pad3; + CARD32 pad00 B32; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + } changeDeviceNotify; + +#undef Window +#undef Time +#undef KeyCode + +#endif From 4383a95e0bbc2f09394deefc453c2edd1c813d0f Mon Sep 17 00:00:00 2001 From: Kaleb Keithley Date: Fri, 14 Nov 2003 16:48:42 +0000 Subject: [PATCH 002/388] XFree86 4.3.0.1 --- XI.h | 7 +++++++ XInput.h | 8 ++------ XIproto.h | 17 +++++++++++++++++ 3 files changed, 26 insertions(+), 6 deletions(-) diff --git a/XI.h b/XI.h index bb4cec1..ea162fa 100644 --- a/XI.h +++ b/XI.h @@ -45,6 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ +/* $XFree86: xc/include/extensions/XI.h,v 1.5 2001/12/14 19:53:28 dawes Exp $ */ /* Definitions used by the server, library and client */ @@ -203,6 +204,12 @@ SOFTWARE. #define DeviceMode (1L << 0) #define Relative 0 #define Absolute 1 +/* Merged from Metrolink tree for XINPUT stuff */ +#define TS_Raw 57 +#define TS_Scaled 58 +#define SendCoreEvents 59 +#define DontSendCoreEvents 60 +/* End of merged section */ #define ProximityState (1L << 1) #define InProximity (0L << 1) diff --git a/XInput.h b/XInput.h index 2470377..83aba0c 100644 --- a/XInput.h +++ b/XInput.h @@ -45,19 +45,15 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ +/* $XFree86: xc/include/extensions/XInput.h,v 1.3 2001/12/14 19:53:28 dawes Exp $ */ /* Definitions used by the library and client */ #ifndef _XINPUT_H_ #define _XINPUT_H_ -#ifndef _XLIB_H_ #include -#endif - -#ifndef _XI_H_ -#include "XI.h" -#endif +#include #define _deviceKeyPress 0 #define _deviceKeyRelease 1 diff --git a/XIproto.h b/XIproto.h index f13d990..0dbe4d2 100644 --- a/XIproto.h +++ b/XIproto.h @@ -45,6 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ +/* $XFree86: xc/include/extensions/XIproto.h,v 1.5 2001/12/14 19:53:28 dawes Exp $ */ #ifndef _XIPROTO_H #define _XIPROTO_H @@ -1331,6 +1332,22 @@ typedef struct { CARD8 pad1,pad2; } xDeviceResolutionCtl; + +/* Merged from Metrolink tree for XINPUT stuff */ + +typedef struct { + CARD16 control; + CARD16 length; + CARD32 min_x; + CARD32 max_x; + CARD32 min_y; + CARD32 max_y; + CARD32 button_threshold; +} xDeviceTSCalibrationCtl; + +/* End of merged section */ + + /********************************************************** * * Input extension events. From 47d36cccfdf0e65848bb2e9595779501a76d6000 Mon Sep 17 00:00:00 2001 From: Kaleb Keithley Date: Tue, 25 Nov 2003 19:28:02 +0000 Subject: [PATCH 003/388] XFree86 4.3.99.16 Bring the tree up to date for the Cygwin folks --- XInput.h | 82 +------------------------------------------------------- 1 file changed, 1 insertion(+), 81 deletions(-) diff --git a/XInput.h b/XInput.h index 83aba0c..0abd5a7 100644 --- a/XInput.h +++ b/XInput.h @@ -45,7 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86: xc/include/extensions/XInput.h,v 1.3 2001/12/14 19:53:28 dawes Exp $ */ +/* $XFree86: xc/include/extensions/XInput.h,v 1.4 2003/11/17 22:20:02 dawes Exp $ */ /* Definitions used by the library and client */ @@ -833,23 +833,18 @@ typedef struct { _XFUNCPROTOBEGIN extern int XChangeKeyboardDevice( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */ -#endif ); extern int XChangePointerDevice( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, int /* xaxis */, int /* yaxis */ -#endif ); extern int XGrabDevice( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, Window /* grab_window */, @@ -859,19 +854,15 @@ extern int XGrabDevice( int /* this_device_mode */, int /* other_devices_mode */, Time /* time */ -#endif ); extern int XUngrabDevice( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, Time /* time */ -#endif ); extern int XGrabDeviceKey( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, unsigned int /* key */, @@ -883,22 +874,18 @@ extern int XGrabDeviceKey( XEventClass* /* event_list */, int /* this_device_mode */, int /* other_devices_mode */ -#endif ); extern int XUngrabDeviceKey( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, unsigned int /* key */, unsigned int /* modifiers */, XDevice* /* modifier_dev */, Window /* grab_window */ -#endif ); extern int XGrabDeviceButton( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, unsigned int /* button */, @@ -910,84 +897,66 @@ extern int XGrabDeviceButton( XEventClass* /* event_list */, int /* this_device_mode */, int /* other_devices_mode */ -#endif ); extern int XUngrabDeviceButton( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, unsigned int /* button */, unsigned int /* modifiers */, XDevice* /* modifier_dev */, Window /* grab_window */ -#endif ); extern int XAllowDeviceEvents( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, int /* event_mode */, Time /* time */ -#endif ); extern int XGetDeviceFocus( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, Window* /* focus */, int* /* revert_to */, Time* /* time */ -#endif ); extern int XSetDeviceFocus( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, Window /* focus */, int /* revert_to */, Time /* time */ -#endif ); extern XFeedbackState *XGetFeedbackControl( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, int* /* num_feedbacks */ -#endif ); extern void XFreeFeedbackList( -#if NeedFunctionPrototypes XFeedbackState* /* list */ -#endif ); extern int XChangeFeedbackControl( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, unsigned long /* mask */, XFeedbackControl* /* f */ -#endif ); extern int XDeviceBell( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, XID /* feedbackclass */, XID /* feedbackid */, int /* percent */ -#endif ); extern KeySym *XGetDeviceKeyMapping( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, #if NeedWidePrototypes @@ -997,175 +966,133 @@ extern KeySym *XGetDeviceKeyMapping( #endif int /* keycount */, int* /* syms_per_code */ -#endif ); extern int XChangeDeviceKeyMapping( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, int /* first */, int /* syms_per_code */, KeySym* /* keysyms */, int /* count */ -#endif ); extern XModifierKeymap *XGetDeviceModifierMapping( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */ -#endif ); extern int XSetDeviceModifierMapping( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, XModifierKeymap* /* modmap */ -#endif ); extern int XSetDeviceButtonMapping( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, unsigned char* /* map[] */, int /* nmap */ -#endif ); extern int XGetDeviceButtonMapping( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, unsigned char* /* map[] */, unsigned int /* nmap */ -#endif ); extern XDeviceState *XQueryDeviceState( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */ -#endif ); extern void XFreeDeviceState( -#if NeedFunctionPrototypes XDeviceState* /* list */ -#endif ); extern XExtensionVersion *XGetExtensionVersion( -#if NeedFunctionPrototypes Display* /* display */, _Xconst char* /* name */ -#endif ); extern XDeviceInfo *XListInputDevices( -#if NeedFunctionPrototypes Display* /* display */, int* /* ndevices */ -#endif ); extern void XFreeDeviceList( -#if NeedFunctionPrototypes XDeviceInfo* /* list */ -#endif ); extern XDevice *XOpenDevice( -#if NeedFunctionPrototypes Display* /* display */, XID /* id */ -#endif ); extern int XCloseDevice( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */ -#endif ); extern int XSetDeviceMode( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, int /* mode */ -#endif ); extern int XSetDeviceValuators( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, int* /* valuators */, int /* first_valuator */, int /* num_valuators */ -#endif ); extern XDeviceControl *XGetDeviceControl( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, int /* control */ -#endif ); extern int XChangeDeviceControl( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, int /* control */, XDeviceControl* /* d */ -#endif ); extern int XSelectExtensionEvent( -#if NeedFunctionPrototypes Display* /* display */, Window /* w */, XEventClass* /* event_list */, int /* count */ -#endif ); extern int XGetSelectedExtensionEvents( -#if NeedFunctionPrototypes Display* /* display */, Window /* w */, int* /* this_client_count */, XEventClass** /* this_client_list */, int* /* all_clients_count */, XEventClass** /* all_clients_list */ -#endif ); extern int XChangeDeviceDontPropagateList( -#if NeedFunctionPrototypes Display* /* display */, Window /* window */, int /* count */, XEventClass* /* events */, int /* mode */ -#endif ); extern XEventClass *XGetDeviceDontPropagateList( -#if NeedFunctionPrototypes Display* /* display */, Window /* window */, int* /* count */ -#endif ); extern Status XSendExtensionEvent( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, Window /* dest */, @@ -1173,11 +1100,9 @@ extern Status XSendExtensionEvent( int /* count */, XEventClass* /* list */, XEvent* /* event */ -#endif ); extern XDeviceTimeCoord *XGetDeviceMotionEvents( -#if NeedFunctionPrototypes Display* /* display */, XDevice* /* device */, Time /* start */, @@ -1185,19 +1110,14 @@ extern XDeviceTimeCoord *XGetDeviceMotionEvents( int* /* nEvents */, int* /* mode */, int* /* axis_count */ -#endif ); extern void XFreeDeviceMotionEvents( -#if NeedFunctionPrototypes XDeviceTimeCoord* /* events */ -#endif ); extern void XFreeDeviceControl( -#if NeedFunctionPrototypes XDeviceControl* /* control */ -#endif ); _XFUNCPROTOEND From f276a601f272742ea8570fae4326c172cf4b8723 Mon Sep 17 00:00:00 2001 From: Egbert Eich Date: Thu, 26 Feb 2004 09:22:27 +0000 Subject: [PATCH 004/388] Importing vendor version xf86-4_3_99_903 on Wed Feb 26 01:21:00 PST 2004 --- XI.h | 2 +- XInput.h | 2 +- XIproto.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/XI.h b/XI.h index ea162fa..8b504f0 100644 --- a/XI.h +++ b/XI.h @@ -45,7 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86: xc/include/extensions/XI.h,v 1.5 2001/12/14 19:53:28 dawes Exp $ */ +/* $XFree86$ */ /* Definitions used by the server, library and client */ diff --git a/XInput.h b/XInput.h index 0abd5a7..c378167 100644 --- a/XInput.h +++ b/XInput.h @@ -45,7 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86: xc/include/extensions/XInput.h,v 1.4 2003/11/17 22:20:02 dawes Exp $ */ +/* $XFree86$ */ /* Definitions used by the library and client */ diff --git a/XIproto.h b/XIproto.h index 0dbe4d2..c88a2b0 100644 --- a/XIproto.h +++ b/XIproto.h @@ -45,7 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86: xc/include/extensions/XIproto.h,v 1.5 2001/12/14 19:53:28 dawes Exp $ */ +/* $XFree86$ */ #ifndef _XIPROTO_H #define _XIPROTO_H From 1b98dbf2eab5a8ef74afda0c669c9fdfc6461cda Mon Sep 17 00:00:00 2001 From: Egbert Eich Date: Thu, 26 Feb 2004 13:35:11 +0000 Subject: [PATCH 005/388] readding XFree86's cvs IDs --- XI.h | 2 +- XInput.h | 2 +- XIproto.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/XI.h b/XI.h index 8b504f0..ea162fa 100644 --- a/XI.h +++ b/XI.h @@ -45,7 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86$ */ +/* $XFree86: xc/include/extensions/XI.h,v 1.5 2001/12/14 19:53:28 dawes Exp $ */ /* Definitions used by the server, library and client */ diff --git a/XInput.h b/XInput.h index c378167..0abd5a7 100644 --- a/XInput.h +++ b/XInput.h @@ -45,7 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86$ */ +/* $XFree86: xc/include/extensions/XInput.h,v 1.4 2003/11/17 22:20:02 dawes Exp $ */ /* Definitions used by the library and client */ diff --git a/XIproto.h b/XIproto.h index c88a2b0..0dbe4d2 100644 --- a/XIproto.h +++ b/XIproto.h @@ -45,7 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86$ */ +/* $XFree86: xc/include/extensions/XIproto.h,v 1.5 2001/12/14 19:53:28 dawes Exp $ */ #ifndef _XIPROTO_H #define _XIPROTO_H From 08e413c25f385e51466ef3309d880c1f63bf0a73 Mon Sep 17 00:00:00 2001 From: Egbert Eich Date: Wed, 3 Mar 2004 12:10:54 +0000 Subject: [PATCH 006/388] Importing vendor version xf86-4_4_0 on Wed Mar 3 04:09:24 PST 2004 --- XI.h | 2 +- XInput.h | 2 +- XIproto.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/XI.h b/XI.h index ea162fa..c710e0a 100644 --- a/XI.h +++ b/XI.h @@ -45,7 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86: xc/include/extensions/XI.h,v 1.5 2001/12/14 19:53:28 dawes Exp $ */ +/* $XFree86: xc/include/extensions/XI.h,v 1.4 2001/01/17 17:53:16 dawes Exp $ */ /* Definitions used by the server, library and client */ diff --git a/XInput.h b/XInput.h index 0abd5a7..ee44105 100644 --- a/XInput.h +++ b/XInput.h @@ -45,7 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86: xc/include/extensions/XInput.h,v 1.4 2003/11/17 22:20:02 dawes Exp $ */ +/* $XFree86: xc/include/extensions/XInput.h,v 1.3 2001/12/14 19:53:28 dawes Exp $ */ /* Definitions used by the library and client */ diff --git a/XIproto.h b/XIproto.h index 0dbe4d2..1da0248 100644 --- a/XIproto.h +++ b/XIproto.h @@ -45,7 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86: xc/include/extensions/XIproto.h,v 1.5 2001/12/14 19:53:28 dawes Exp $ */ +/* $XFree86: xc/include/extensions/XIproto.h,v 1.4 2001/01/17 17:53:17 dawes Exp $ */ #ifndef _XIPROTO_H #define _XIPROTO_H From ca910a158bdc060d17cf3c00f93c82c3a6ee6f05 Mon Sep 17 00:00:00 2001 From: Egbert Eich Date: Sun, 14 Mar 2004 08:31:35 +0000 Subject: [PATCH 007/388] Importing vendor version xf86-4_4_99_1 on Sun Mar 14 00:26:39 PST 2004 --- XI.h | 2 +- XInput.h | 2 +- XIproto.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/XI.h b/XI.h index c710e0a..ea162fa 100644 --- a/XI.h +++ b/XI.h @@ -45,7 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86: xc/include/extensions/XI.h,v 1.4 2001/01/17 17:53:16 dawes Exp $ */ +/* $XFree86: xc/include/extensions/XI.h,v 1.5 2001/12/14 19:53:28 dawes Exp $ */ /* Definitions used by the server, library and client */ diff --git a/XInput.h b/XInput.h index ee44105..0abd5a7 100644 --- a/XInput.h +++ b/XInput.h @@ -45,7 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86: xc/include/extensions/XInput.h,v 1.3 2001/12/14 19:53:28 dawes Exp $ */ +/* $XFree86: xc/include/extensions/XInput.h,v 1.4 2003/11/17 22:20:02 dawes Exp $ */ /* Definitions used by the library and client */ diff --git a/XIproto.h b/XIproto.h index 1da0248..0dbe4d2 100644 --- a/XIproto.h +++ b/XIproto.h @@ -45,7 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86: xc/include/extensions/XIproto.h,v 1.4 2001/01/17 17:53:17 dawes Exp $ */ +/* $XFree86: xc/include/extensions/XIproto.h,v 1.5 2001/12/14 19:53:28 dawes Exp $ */ #ifndef _XIPROTO_H #define _XIPROTO_H From 4254b2967e3c5f256138f35de1ab49efff87220c Mon Sep 17 00:00:00 2001 From: Egbert Eich Date: Fri, 23 Apr 2004 18:43:06 +0000 Subject: [PATCH 008/388] Merging XORG-CURRENT into trunk --- XI.h | 2 +- XInput.h | 2 +- XIproto.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/XI.h b/XI.h index ea162fa..c710e0a 100644 --- a/XI.h +++ b/XI.h @@ -45,7 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86: xc/include/extensions/XI.h,v 1.5 2001/12/14 19:53:28 dawes Exp $ */ +/* $XFree86: xc/include/extensions/XI.h,v 1.4 2001/01/17 17:53:16 dawes Exp $ */ /* Definitions used by the server, library and client */ diff --git a/XInput.h b/XInput.h index 0abd5a7..ee44105 100644 --- a/XInput.h +++ b/XInput.h @@ -45,7 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86: xc/include/extensions/XInput.h,v 1.4 2003/11/17 22:20:02 dawes Exp $ */ +/* $XFree86: xc/include/extensions/XInput.h,v 1.3 2001/12/14 19:53:28 dawes Exp $ */ /* Definitions used by the library and client */ diff --git a/XIproto.h b/XIproto.h index 0dbe4d2..1da0248 100644 --- a/XIproto.h +++ b/XIproto.h @@ -45,7 +45,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86: xc/include/extensions/XIproto.h,v 1.5 2001/12/14 19:53:28 dawes Exp $ */ +/* $XFree86: xc/include/extensions/XIproto.h,v 1.4 2001/01/17 17:53:17 dawes Exp $ */ #ifndef _XIPROTO_H #define _XIPROTO_H From 518f527ab685d2d082796460113bb7a9ea9bfe15 Mon Sep 17 00:00:00 2001 From: Kevin E Martin Date: Fri, 6 May 2005 01:46:30 +0000 Subject: [PATCH 009/388] Initial build system files for proto module. --- Makefile.am | 10 ++++++++++ autogen.sh | 12 ++++++++++++ configure.ac | 6 ++++++ inputext.pc.in | 9 +++++++++ 4 files changed, 37 insertions(+) create mode 100644 Makefile.am create mode 100755 autogen.sh create mode 100644 configure.ac create mode 100644 inputext.pc.in diff --git a/Makefile.am b/Makefile.am new file mode 100644 index 0000000..3d270da --- /dev/null +++ b/Makefile.am @@ -0,0 +1,10 @@ +inputdir = $(includedir)/X11/extensions +input_HEADERS = \ + XI.h \ + XInput.h \ + XIproto.h + +pkgconfigdir = $(libdir)/pkgconfig +pkgconfig_DATA = inputext.pc + +EXTRA_DIST = autogen.sh inputext.pc.in diff --git a/autogen.sh b/autogen.sh new file mode 100755 index 0000000..904cd67 --- /dev/null +++ b/autogen.sh @@ -0,0 +1,12 @@ +#! /bin/sh + +srcdir=`dirname $0` +test -z "$srcdir" && srcdir=. + +ORIGDIR=`pwd` +cd $srcdir + +autoreconf -v --install || exit 1 +cd $ORIGDIR || exit $? + +$srcdir/configure --enable-maintainer-mode "$@" diff --git a/configure.ac b/configure.ac new file mode 100644 index 0000000..e3476dd --- /dev/null +++ b/configure.ac @@ -0,0 +1,6 @@ +AC_PREREQ([2.57]) +AC_INIT([InputExt], [7.0], [xorg@lists.freedesktop.org]) +AM_INIT_AUTOMAKE([foreign dist-bzip2]) + +AC_OUTPUT([Makefile + inputext.pc]) diff --git a/inputext.pc.in b/inputext.pc.in new file mode 100644 index 0000000..f10abf9 --- /dev/null +++ b/inputext.pc.in @@ -0,0 +1,9 @@ +prefix=@prefix@ +exec_prefix=@exec_prefix@ +libdir=@libdir@ +includedir=@includedir@ + +Name: InputExt +Description: Input extension headers +Version: @PACKAGE_VERSION@ +Cflags: -I${includedir} From 5c5945a47990b7bc077bcfdbabb6e0003cbf1659 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=B8ren=20Sandmann=20Pedersen?= Date: Mon, 9 May 2005 18:20:04 +0000 Subject: [PATCH 010/388] Change all the protonames from Ext to Proto. --- Makefile.am | 4 ++-- configure.ac | 4 ++-- inputext.pc.in => inputproto.pc.in | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) rename inputext.pc.in => inputproto.pc.in (91%) diff --git a/Makefile.am b/Makefile.am index 3d270da..e39ea0a 100644 --- a/Makefile.am +++ b/Makefile.am @@ -5,6 +5,6 @@ input_HEADERS = \ XIproto.h pkgconfigdir = $(libdir)/pkgconfig -pkgconfig_DATA = inputext.pc +pkgconfig_DATA = inputproto.pc -EXTRA_DIST = autogen.sh inputext.pc.in +EXTRA_DIST = autogen.sh inputproto.pc.in diff --git a/configure.ac b/configure.ac index e3476dd..1b13ffd 100644 --- a/configure.ac +++ b/configure.ac @@ -1,6 +1,6 @@ AC_PREREQ([2.57]) -AC_INIT([InputExt], [7.0], [xorg@lists.freedesktop.org]) +AC_INIT([InputProto], [7.0], [xorg@lists.freedesktop.org]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) AC_OUTPUT([Makefile - inputext.pc]) + inputproto.pc]) diff --git a/inputext.pc.in b/inputproto.pc.in similarity index 91% rename from inputext.pc.in rename to inputproto.pc.in index f10abf9..c499cda 100644 --- a/inputext.pc.in +++ b/inputproto.pc.in @@ -3,7 +3,7 @@ exec_prefix=@exec_prefix@ libdir=@libdir@ includedir=@includedir@ -Name: InputExt +Name: InputProto Description: Input extension headers Version: @PACKAGE_VERSION@ Cflags: -I${includedir} From 242316c65e53d1bba244e4f35e5a93718b0ea8d0 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 16 May 2005 03:30:03 +0000 Subject: [PATCH 011/388] Add COPYING file for Input. --- COPYING | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 COPYING diff --git a/COPYING b/COPYING new file mode 100644 index 0000000..aac40e8 --- /dev/null +++ b/COPYING @@ -0,0 +1,41 @@ +Copyright 1989, 1998 The Open Group + +Permission to use, copy, modify, distribute, and sell this software and its +documentation for any purpose is hereby granted without fee, provided that +the above copyright notice appear in all copies and that both that +copyright notice and this permission notice appear in supporting +documentation. + +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN +AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + +Except as contained in this notice, the name of The Open Group shall not be +used in advertising or otherwise to promote the sale, use or other dealings +in this Software without prior written authorization from The Open Group. + +Copyright 1989 by Hewlett-Packard Company, Palo Alto, California. + + All Rights Reserved + +Permission to use, copy, modify, and distribute this software and its +documentation for any purpose and without fee is hereby granted, +provided that the above copyright notice appear in all copies and that +both that copyright notice and this permission notice appear in +supporting documentation, and that the name of Hewlett-Packard not be +used in advertising or publicity pertaining to distribution of the +software without specific, written prior permission. + +HEWLETT-PACKARD DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING +ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL +HEWLETT-PACKARD BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR +ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, +WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS +SOFTWARE. From ec71e17293b90ff5eeaa97566751fc5c3955904a Mon Sep 17 00:00:00 2001 From: Adam Jackson Date: Thu, 19 May 2005 00:10:18 +0000 Subject: [PATCH 012/388] Require automake 1.7 in AM_INIT_AUTOMAKE --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 1b13ffd..dadefab 100644 --- a/configure.ac +++ b/configure.ac @@ -1,6 +1,6 @@ AC_PREREQ([2.57]) AC_INIT([InputProto], [7.0], [xorg@lists.freedesktop.org]) -AM_INIT_AUTOMAKE([foreign dist-bzip2]) +AM_INIT_AUTOMAKE([1.7], [foreign dist-bzip2]) AC_OUTPUT([Makefile inputproto.pc]) From 492f0a9e16bfe9cfb2c7b888b5b5e511db2bf83b Mon Sep 17 00:00:00 2001 From: Adam Jackson Date: Thu, 19 May 2005 00:22:39 +0000 Subject: [PATCH 013/388] revert last change, didn't do right thing at all, sorry for the noise --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index dadefab..1b13ffd 100644 --- a/configure.ac +++ b/configure.ac @@ -1,6 +1,6 @@ AC_PREREQ([2.57]) AC_INIT([InputProto], [7.0], [xorg@lists.freedesktop.org]) -AM_INIT_AUTOMAKE([1.7], [foreign dist-bzip2]) +AM_INIT_AUTOMAKE([foreign dist-bzip2]) AC_OUTPUT([Makefile inputproto.pc]) From 9161a356397a07002e03cf1846d212c7154f4c52 Mon Sep 17 00:00:00 2001 From: Daniel Stone Date: Sat, 21 May 2005 04:04:21 +0000 Subject: [PATCH 014/388] Set version to 1.3. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 1b13ffd..503d597 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [7.0], [xorg@lists.freedesktop.org]) +AC_INIT([InputProto], [1.3], [xorg@lists.freedesktop.org]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) AC_OUTPUT([Makefile From 742a1eb222d662fc9247ab7c1bd337ffef01eafb Mon Sep 17 00:00:00 2001 From: Kevin E Martin Date: Fri, 29 Jul 2005 21:22:55 +0000 Subject: [PATCH 015/388] Various changes preparing packages for RC0: - Verify and update package version numbers as needed - Implement versioning scheme - Change bug address to point to bugzilla bug entry form - Disable loadable i18n in libX11 by default (use --enable-loadable-i18n to reenable it) - Fix makedepend to use pkgconfig and pass distcheck - Update build script to build macros first - Update modular Xorg version --- configure.ac | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 503d597..0078728 100644 --- a/configure.ac +++ b/configure.ac @@ -1,6 +1,8 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.3], [xorg@lists.freedesktop.org]) +AC_INIT([InputProto], [1.3], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) - + +XORG_RELEASE_VERSION + AC_OUTPUT([Makefile inputproto.pc]) From 67498db2df7435d9d59eda4ac444c6560da839b3 Mon Sep 17 00:00:00 2001 From: Eric Anholt Date: Tue, 2 Aug 2005 19:19:38 +0000 Subject: [PATCH 016/388] Add basic .cvsignore files for proto modules. --- .cvsignore | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 .cvsignore diff --git a/.cvsignore b/.cvsignore new file mode 100644 index 0000000..2c3bca3 --- /dev/null +++ b/.cvsignore @@ -0,0 +1,10 @@ +Makefile +Makefile.in +aclocal.m4 +autom4te.cache +config.log +config.status +configure +install-sh +missing +inputproto.pc From 3ade2fe8443f572abeee73b4fa8e986e4a054017 Mon Sep 17 00:00:00 2001 From: Kevin E Martin Date: Wed, 19 Oct 2005 02:48:14 +0000 Subject: [PATCH 017/388] Update package version number for RC1 release. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 0078728..0f188bd 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.3], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.3.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) XORG_RELEASE_VERSION From 4cc2697880ae61723094dacf78ffe77d81f6e0ee Mon Sep 17 00:00:00 2001 From: Kevin E Martin Date: Thu, 15 Dec 2005 00:24:37 +0000 Subject: [PATCH 018/388] Update package version number for final X11R7 release candidate. --- ChangeLog | 4 ++++ configure.ac | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) create mode 100644 ChangeLog diff --git a/ChangeLog b/ChangeLog new file mode 100644 index 0000000..c722b51 --- /dev/null +++ b/ChangeLog @@ -0,0 +1,4 @@ +2005-12-14 Kevin E. Martin + + * configure.ac: + Update package version number for final X11R7 release candidate. diff --git a/configure.ac b/configure.ac index 0f188bd..3503bb9 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.3.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.3.2], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) XORG_RELEASE_VERSION From 6767671f502964d385aa41de3a45fb479c6330c0 Mon Sep 17 00:00:00 2001 From: Alan Coopersmith Date: Fri, 14 Jul 2006 18:56:18 -0700 Subject: [PATCH 019/388] renamed: .cvsignore -> .gitignore --- .cvsignore => .gitignore | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename .cvsignore => .gitignore (100%) diff --git a/.cvsignore b/.gitignore similarity index 100% rename from .cvsignore rename to .gitignore From 7a4a2a3e733378abced0a184627adfda4ed387b9 Mon Sep 17 00:00:00 2001 From: Daniel Stone Date: Mon, 17 Jul 2006 19:34:45 -0400 Subject: [PATCH 020/388] =?UTF-8?q?add=20DevicePresenceNotify=20event,=20c?= =?UTF-8?q?lean=20up=20Add=20DevicePresenceNotify=20event,=20which=20indic?= =?UTF-8?q?ates=20that=20something=20in=20the=20device=20list=20changed=20?= =?UTF-8?q?(Kristian=20H=C3=B8gsberg,=20Red=20Hat).=20Add=20a=20core=20eve?= =?UTF-8?q?nt=20control,=20which=20toggles=20the=20sending=20or=20not=20of?= =?UTF-8?q?=20core=20events=20by=20an=20extended=20device.=20Clean=20up=20?= =?UTF-8?q?some=20random=20detritus=20from=20the=20MetroLink=20merge.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- XI.h | 14 +++++++------ XInput.h | 41 ++++++++++++++++++++++++++++++++++++ XIproto.h | 59 ++++++++++++++++++++++++++++++++++++++++++++-------- configure.ac | 2 +- 4 files changed, 100 insertions(+), 16 deletions(-) diff --git a/XI.h b/XI.h index c710e0a..dc1f22d 100644 --- a/XI.h +++ b/XI.h @@ -137,6 +137,7 @@ SOFTWARE. #define XInput_Add_XDeviceBell 2 #define XInput_Add_XSetDeviceValuators 3 #define XInput_Add_XChangeDeviceControl 4 +#define XInput_Add_DevicePresenceNotify 5 #define XI_Absent 0 #define XI_Present 1 @@ -153,7 +154,12 @@ SOFTWARE. #define XI_Add_XChangeDeviceControl_Major 1 #define XI_Add_XChangeDeviceControl_Minor 3 +#define XI_Add_DevicePresenceNotify_Major 1 +#define XI_Add_DevicePresenceNotify_Minor 4 + #define DEVICE_RESOLUTION 1 +#define DEVICE_TOUCHSCREEN 2 +#define DEVICE_CORE 3 #define NoSuchExtension 1 @@ -204,12 +210,6 @@ SOFTWARE. #define DeviceMode (1L << 0) #define Relative 0 #define Absolute 1 -/* Merged from Metrolink tree for XINPUT stuff */ -#define TS_Raw 57 -#define TS_Scaled 58 -#define SendCoreEvents 59 -#define DontSendCoreEvents 60 -/* End of merged section */ #define ProximityState (1L << 1) #define InProximity (0L << 1) @@ -244,6 +244,8 @@ SOFTWARE. #define _deviceOwnerGrabButton 8 #define _noExtensionEvent 9 +#define _devicePresence 0 + #define XI_BadDevice 0 #define XI_BadEvent 1 #define XI_BadMode 2 diff --git a/XInput.h b/XInput.h index ee44105..2f1fffb 100644 --- a/XInput.h +++ b/XInput.h @@ -149,6 +149,13 @@ SOFTWARE. #define NoExtensionEvent(d,type,_class) \ { _class = ((XDevice *) d)->device_id << 8 | _noExtensionEvent;} +#define DevicePresence(dpy, type, _class) \ + { \ + extern int_XiGetDevicePresenceNotifyEvent(Display *); \ + type = _XiGetDevicePresenceNotifyEvent(dpy); \ + _class = (0x10000 | _devicePresence); \ + } + #define BadDevice(dpy,error) _xibaddevice(dpy, &error) #define BadClass(dpy,error) _xibadclass(dpy, &error) @@ -416,6 +423,24 @@ typedef struct { int request; /* NewPointer or NewKeyboard */ } XChangeDeviceNotifyEvent; +/******************************************************************* + * + * DevicePresenceNotify event. This event is sent when the list of + * input devices changes. No information about the change is + * contained in this event, the client should use XListInputDevices() + * to learn what has changed. + * + */ + +typedef struct { + int type; + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; /* unused */ + Time time; +} XDevicePresenceNotifyEvent; + /******************************************************************* * * Control structures for input devices that support input class @@ -632,6 +657,22 @@ typedef struct { int *max_resolutions; } XDeviceResolutionState; +typedef struct { + XID control; + int length; + int min_x; + int max_x; + int min_y; + int max_y; + int button_threshold; +} XDeviceTSControl, XDeviceTSState; + +typedef struct { + XID control; + int length; + int status; +} XDeviceCoreControl, XDeviceCoreState; + /******************************************************************* * * An array of XDeviceList structures is returned by the diff --git a/XIproto.h b/XIproto.h index 1da0248..ec2941b 100644 --- a/XIproto.h +++ b/XIproto.h @@ -72,7 +72,7 @@ SOFTWARE. #define numInputClasses 7 -#define IEVENTS 15 +#define IEVENTS 16 #define IERRORS 5 #define CLIENT_REQ 1 @@ -113,6 +113,7 @@ struct tmask #define XI_ChangeDeviceNotify 12 #define XI_DeviceKeystateNotify 13 #define XI_DeviceButtonstateNotify 14 +#define XI_DevicePresenceNotify 15 /********************************************************* * @@ -1290,6 +1291,24 @@ typedef struct { CARD32 num_valuators B32; /* number of valuators */ } xDeviceResolutionState; +typedef struct { + CARD16 control B16; + CARD16 length B16; + CARD32 min_x; + CARD32 max_x; + CARD32 min_y; + CARD32 max_y; + CARD32 button_threshold; +} xDeviceTSState; + +typedef struct { + CARD16 control B16; /* control type */ + CARD16 length B16; /* control length */ + CARD8 status; + CARD8 pad0; + CARD16 pad1 B16; +} xDeviceCoreState; + /********************************************************* * * ChangeDeviceControl. @@ -1332,21 +1351,23 @@ typedef struct { CARD8 pad1,pad2; } xDeviceResolutionCtl; - -/* Merged from Metrolink tree for XINPUT stuff */ - typedef struct { - CARD16 control; - CARD16 length; + CARD16 control B16; + CARD16 length B16; CARD32 min_x; CARD32 max_x; CARD32 min_y; CARD32 max_y; CARD32 button_threshold; -} xDeviceTSCalibrationCtl; - -/* End of merged section */ +} xDeviceTSCtl; +typedef struct { + CARD16 control B16; + CARD16 length B16; + CARD8 status; + CARD8 pad0; + CARD16 pad1 B16; +} xDeviceCoreCtl; /********************************************************** * @@ -1523,6 +1544,26 @@ typedef struct CARD32 pad04 B32; } changeDeviceNotify; +/********************************************************** + * + * devicePresenceNotify. + * + */ + +typedef struct + { + BYTE type; + BYTE pad00; + CARD16 sequenceNumber B16; + Time time B32; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; + CARD32 pad06 B32; + } devicePresenceNotify; + #undef Window #undef Time #undef KeyCode diff --git a/configure.ac b/configure.ac index 3503bb9..aa96cc1 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.3.2], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.4], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) XORG_RELEASE_VERSION From 926251a486b57197d735a426887acad6fdfd7dc6 Mon Sep 17 00:00:00 2001 From: Daniel Stone Date: Tue, 18 Jul 2006 11:56:37 -0400 Subject: [PATCH 021/388] add XExtensionKeyboard and XExtensionPointer classes Add two new classes of device, XExtensionKeyboard, and XExtensionPointer. --- XI.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/XI.h b/XI.h index dc1f22d..b85797a 100644 --- a/XI.h +++ b/XI.h @@ -177,6 +177,8 @@ SOFTWARE. #define IsXPointer 0 #define IsXKeyboard 1 #define IsXExtensionDevice 2 +#define IsXExtensionKeyboard 3 +#define IsXExtensionPointer 4 #define AsyncThisDevice 0 #define SyncThisDevice 1 From 1fab95863efc2bbf9a5b836b3de31da4a956b4bd Mon Sep 17 00:00:00 2001 From: Daniel Stone Date: Fri, 20 Oct 2006 00:33:13 +0300 Subject: [PATCH 022/388] add DEVICE_ENABLE control, add core indication Add DEVICE_ENABLE control, which allows specific devices to be enabled or disabled at runtime. Add 'iscore' flag to DEVICE_CORE, which indicates whether or not the device is a virtual core device. --- XI.h | 1 + XInput.h | 15 ++++++++++++++- XIproto.h | 18 +++++++++++++++++- 3 files changed, 32 insertions(+), 2 deletions(-) diff --git a/XI.h b/XI.h index b85797a..1cfac91 100644 --- a/XI.h +++ b/XI.h @@ -160,6 +160,7 @@ SOFTWARE. #define DEVICE_RESOLUTION 1 #define DEVICE_TOUCHSCREEN 2 #define DEVICE_CORE 3 +#define DEVICE_ENABLE 4 #define NoSuchExtension 1 diff --git a/XInput.h b/XInput.h index 2f1fffb..3cc7d31 100644 --- a/XInput.h +++ b/XInput.h @@ -671,7 +671,20 @@ typedef struct { XID control; int length; int status; -} XDeviceCoreControl, XDeviceCoreState; +} XDeviceCoreControl; + +typedef struct { + XID control; + int length; + int status; + int iscore; +} XDeviceCoreState; + +typedef struct { + XID control; + int length; + int enable; +} XDeviceEnableControl, XDeviceEnableState; /******************************************************************* * diff --git a/XIproto.h b/XIproto.h index ec2941b..c1b6202 100644 --- a/XIproto.h +++ b/XIproto.h @@ -1305,10 +1305,18 @@ typedef struct { CARD16 control B16; /* control type */ CARD16 length B16; /* control length */ CARD8 status; - CARD8 pad0; + CARD8 iscore; CARD16 pad1 B16; } xDeviceCoreState; +typedef struct { + CARD16 control B16; /* control type */ + CARD16 length B16; /* control length */ + CARD8 enable; + CARD8 pad0; + CARD16 pad1 B16; +} xDeviceEnableState; + /********************************************************* * * ChangeDeviceControl. @@ -1369,6 +1377,14 @@ typedef struct { CARD16 pad1 B16; } xDeviceCoreCtl; +typedef struct { + CARD16 control B16; + CARD16 length B16; + CARD8 enable; + CARD8 pad0; + CARD16 pad1 B16; +} xDeviceEnableCtl; + /********************************************************** * * Input extension events. From 06ffd1e6b600d4e3f55ce7da69448a284ff5dac6 Mon Sep 17 00:00:00 2001 From: "Zephaniah E. Hull" Date: Sat, 21 Oct 2006 03:58:53 -0400 Subject: [PATCH 023/388] DEVICE_TOUCHPAD -> DEVICE_ABS_CALIB. As it's really calibration for absolute devices, add some stuff. DEVICE_ABS_AREA Defines the area of the screen that an absolute device covers if it is sending core events. --- XI.h | 3 ++- XInput.h | 16 +++++++++++++++- XIproto.h | 48 ++++++++++++++++++++++++++++++++++++++---------- 3 files changed, 55 insertions(+), 12 deletions(-) diff --git a/XI.h b/XI.h index 1cfac91..fbecd80 100644 --- a/XI.h +++ b/XI.h @@ -158,9 +158,10 @@ SOFTWARE. #define XI_Add_DevicePresenceNotify_Minor 4 #define DEVICE_RESOLUTION 1 -#define DEVICE_TOUCHSCREEN 2 +#define DEVICE_ABS_CALIB 2 #define DEVICE_CORE 3 #define DEVICE_ENABLE 4 +#define DEVICE_ABS_AREA 5 #define NoSuchExtension 1 diff --git a/XInput.h b/XInput.h index 3cc7d31..528e442 100644 --- a/XInput.h +++ b/XInput.h @@ -664,8 +664,22 @@ typedef struct { int max_x; int min_y; int max_y; + int flip_x; + int flip_y; + int rotation; int button_threshold; -} XDeviceTSControl, XDeviceTSState; +} XDeviceAbsCalibControl, XDeviceAbsCalibState; + +typedef struct { + XID control; + int length; + int offset_x; + int offset_y; + int width; + int height; + int screen; + XID following; +} XDeviceAbsAreaControl, XDeviceAbsAreaState; typedef struct { XID control; diff --git a/XIproto.h b/XIproto.h index c1b6202..139d828 100644 --- a/XIproto.h +++ b/XIproto.h @@ -1294,12 +1294,26 @@ typedef struct { typedef struct { CARD16 control B16; CARD16 length B16; - CARD32 min_x; - CARD32 max_x; - CARD32 min_y; - CARD32 max_y; + INT32 min_x; + INT32 max_x; + INT32 min_y; + INT32 max_y; + CARD32 flip_x; + CARD32 flip_y; + CARD32 rotation; CARD32 button_threshold; -} xDeviceTSState; +} xDeviceAbsCalibState; + +typedef struct { + CARD16 control B16; + CARD16 length B16; + CARD32 offset_x; + CARD32 offset_y; + CARD32 width; + CARD32 height; + CARD32 screen; + CARD32 following; +} xDeviceAbsAreaState; typedef struct { CARD16 control B16; /* control type */ @@ -1362,12 +1376,26 @@ typedef struct { typedef struct { CARD16 control B16; CARD16 length B16; - CARD32 min_x; - CARD32 max_x; - CARD32 min_y; - CARD32 max_y; + INT32 min_x; + INT32 max_x; + INT32 min_y; + INT32 max_y; + CARD32 flip_x; + CARD32 flip_y; + CARD32 rotation; CARD32 button_threshold; -} xDeviceTSCtl; +} xDeviceAbsCalibCtl; + +typedef struct { + CARD16 control B16; + CARD16 length B16; + CARD32 offset_x; + CARD32 offset_y; + INT32 width; + INT32 height; + INT32 screen; + CARD32 following; +} xDeviceAbsAreaCtl; typedef struct { CARD16 control B16; From b1b3dbfd9b00d47c84c213bc6b7d61c5e8c80466 Mon Sep 17 00:00:00 2001 From: Daniel Stone Date: Sun, 22 Oct 2006 16:30:56 +0300 Subject: [PATCH 024/388] DevicePresenceNotify: add deviceid field, with explanation Add deviceid field, and an explanation of same in XInput.h. deviceid is only used if a specific device changed, and control is non-zero if a specific control on that device changed. --- XInput.h | 13 ++++++++++--- XIproto.h | 4 +++- 2 files changed, 13 insertions(+), 4 deletions(-) diff --git a/XInput.h b/XInput.h index 528e442..e4066b1 100644 --- a/XInput.h +++ b/XInput.h @@ -426,10 +426,14 @@ typedef struct { /******************************************************************* * * DevicePresenceNotify event. This event is sent when the list of - * input devices changes. No information about the change is - * contained in this event, the client should use XListInputDevices() - * to learn what has changed. + * input devices changes, in which case devchange will be false, and + * no information about the change will be contained in the event; + * the client should use XListInputDevices() to learn what has changed. * + * If devchange is true, an attribute that the server believes is + * important has changed on a device, and the client should use + * XGetDeviceControl to examine the device. If control is non-zero, + * then that control has changed meaningfully. */ typedef struct { @@ -439,6 +443,9 @@ typedef struct { Display *display; /* Display the event was read from */ Window window; /* unused */ Time time; + Bool devchange; + XID deviceid; + XID control; } XDevicePresenceNotifyEvent; /******************************************************************* diff --git a/XIproto.h b/XIproto.h index 139d828..e3c6d6b 100644 --- a/XIproto.h +++ b/XIproto.h @@ -1600,7 +1600,9 @@ typedef struct BYTE pad00; CARD16 sequenceNumber B16; Time time B32; - CARD32 pad01 B32; + BYTE devchange; + BYTE deviceid; + CARD16 control B16; CARD32 pad02 B32; CARD32 pad03 B32; CARD32 pad04 B32; From a0be30da79e35e7d503c6eeb9021c2f63beb2176 Mon Sep 17 00:00:00 2001 From: Daniel Stone Date: Sun, 22 Oct 2006 16:40:11 +0300 Subject: [PATCH 025/388] DeviceAbs{Area,Calib}: properly align 32-bit types Decorate CARD32s and INT32s with B32. --- XIproto.h | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/XIproto.h b/XIproto.h index e3c6d6b..36b5a49 100644 --- a/XIproto.h +++ b/XIproto.h @@ -1294,25 +1294,25 @@ typedef struct { typedef struct { CARD16 control B16; CARD16 length B16; - INT32 min_x; - INT32 max_x; - INT32 min_y; - INT32 max_y; - CARD32 flip_x; - CARD32 flip_y; - CARD32 rotation; - CARD32 button_threshold; + INT32 min_x B32; + INT32 max_x B32; + INT32 min_y B32; + INT32 max_y B32; + CARD32 flip_x B32; + CARD32 flip_y B32; + CARD32 rotation B32; + CARD32 button_threshold B32; } xDeviceAbsCalibState; typedef struct { CARD16 control B16; CARD16 length B16; - CARD32 offset_x; - CARD32 offset_y; - CARD32 width; - CARD32 height; - CARD32 screen; - CARD32 following; + CARD32 offset_x B32; + CARD32 offset_y B32; + CARD32 width B32; + CARD32 height B32; + CARD32 screen B32; + CARD32 following B32; } xDeviceAbsAreaState; typedef struct { From cc055ae804f4dfd8b09b8993673b4670e5cf61ce Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 20 Dec 2006 13:36:06 +1030 Subject: [PATCH 026/388] add QueryDevicePointer request + reply add WarpDevicePointer request --- Changelog | 7 +++++++ XI.h | 3 +++ XInput.h | 14 +++++++++++++ XIproto.h | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 86 insertions(+) create mode 100644 Changelog diff --git a/Changelog b/Changelog new file mode 100644 index 0000000..89ced93 --- /dev/null +++ b/Changelog @@ -0,0 +1,7 @@ +MPX changelog + +== 20.12.06 == +add QueryDevicePointer request + reply +add WarpDevicePointer request + + diff --git a/XI.h b/XI.h index fbecd80..3b8b548 100644 --- a/XI.h +++ b/XI.h @@ -110,6 +110,9 @@ SOFTWARE. #define sz_xGetDeviceControlReply 32 #define sz_xChangeDeviceControlReq 8 #define sz_xChangeDeviceControlReply 32 +#define sz_xQueryDevicePointerReq 12 +#define sz_xQueryDevicePointerReply 32 +#define sz_xWarpDevicePointerReq 28 #define INAME "XInputExtension" diff --git a/XInput.h b/XInput.h index e4066b1..c6d0ae8 100644 --- a/XInput.h +++ b/XInput.h @@ -1195,6 +1195,20 @@ extern void XFreeDeviceControl( XDeviceControl* /* control */ ); +extern Bool XQueryDevicePointer( + Display* /* display */, + XDevice* /* device */, + Window /* win */, + Window* /* root */, + Window* /* child */, + int* /* root_x */, + int* /* root_y */, + int* /* win_x */, + int* /* win_y */, + unsigned int* /* mask */, + Bool* /* shared */ +); + _XFUNCPROTOEND #endif /* _XINPUT_H_ */ diff --git a/XIproto.h b/XIproto.h index 36b5a49..33d4708 100644 --- a/XIproto.h +++ b/XIproto.h @@ -156,6 +156,8 @@ struct tmask #define X_SetDeviceValuators 33 #define X_GetDeviceControl 34 #define X_ChangeDeviceControl 35 +#define X_QueryDevicePointer 36 +#define X_WarpDevicePointer 37 /********************************************************* * @@ -1413,6 +1415,65 @@ typedef struct { CARD16 pad1 B16; } xDeviceEnableCtl; +/********************************************************** + * + * QueryDevicePointer. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_QueryDevicePointer */ + CARD16 length B16; + Window win; + CARD8 deviceid; + CARD8 pad0; + CARD16 pad1 B16; +} xQueryDevicePointerReq; + + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_QueryDevicePointer */ + CARD16 sequenceNumber B16; + CARD32 length B32; + Window root B32; + Window child B32; + INT16 rootX B16; + INT16 rootY B16; + INT16 winX B16; + INT16 winY B16; + CARD16 mask B16; + BYTE sameScreen; + BYTE shared; /* sharing the core cursor? */ + CARD32 pad0 B32; +} xQueryDevicePointerReply; + + +/********************************************************** + * + * WarpDevicePointer. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_WarpDevicePointer */ + CARD16 length B16; + Window src_win B32; + Window dst_win B32; + INT16 src_x B16; + INT16 src_y B16; + CARD16 src_width B16; + CARD16 src_height B16; + INT16 dst_x B16; + INT16 dst_y B16; + CARD8 deviceid; + CARD8 pad0; + CARD16 pad1 B16; +} xWarpDevicePointerReq; + + /********************************************************** * * Input extension events. @@ -1610,6 +1671,7 @@ typedef struct CARD32 pad06 B32; } devicePresenceNotify; + #undef Window #undef Time #undef KeyCode From 3b84ea85ace4dc9fe1caf7d7c45c0c51ee35b4b2 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 8 Jan 2007 12:33:41 +1030 Subject: [PATCH 027/388] add ChangeDeviceCursor request --- Changelog | 7 +++++-- XI.h | 1 + XInput.h | 14 ++++++++++++++ XIproto.h | 18 ++++++++++++++++++ 4 files changed, 38 insertions(+), 2 deletions(-) diff --git a/Changelog b/Changelog index 89ced93..5dcf225 100644 --- a/Changelog +++ b/Changelog @@ -1,7 +1,10 @@ MPX changelog +== 08.01.07 == + add ChangeDeviceCursor request + == 20.12.06 == -add QueryDevicePointer request + reply -add WarpDevicePointer request + add QueryDevicePointer request + reply + add WarpDevicePointer request diff --git a/XI.h b/XI.h index 3b8b548..6573310 100644 --- a/XI.h +++ b/XI.h @@ -113,6 +113,7 @@ SOFTWARE. #define sz_xQueryDevicePointerReq 12 #define sz_xQueryDevicePointerReply 32 #define sz_xWarpDevicePointerReq 28 +#define sz_xChangeDeviceCursorReq 16 #define INAME "XInputExtension" diff --git a/XInput.h b/XInput.h index c6d0ae8..e5239ff 100644 --- a/XInput.h +++ b/XInput.h @@ -1209,6 +1209,20 @@ extern Bool XQueryDevicePointer( Bool* /* shared */ ); +extern Status XDefineDeviceCursor( + Display* /* display */, + XDevice* /* device */, + Window /* win */, + Cursor /* cursor */ +); + +extern Status XUndefineDeviceCursor( + Display* /* display */, + XDevice* /* device */, + Window /* win */ +); + + _XFUNCPROTOEND #endif /* _XINPUT_H_ */ diff --git a/XIproto.h b/XIproto.h index 33d4708..541e9a2 100644 --- a/XIproto.h +++ b/XIproto.h @@ -158,6 +158,7 @@ struct tmask #define X_ChangeDeviceControl 35 #define X_QueryDevicePointer 36 #define X_WarpDevicePointer 37 +#define X_ChangeDeviceCursor 38 /********************************************************* * @@ -1473,6 +1474,23 @@ typedef struct { CARD16 pad1 B16; } xWarpDevicePointerReq; +/********************************************************** + * + * ChangeDeviceCursor. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_ChangeDeviceCursor */ + CARD16 length B16; + Window win B32; + Cursor cursor B32; + CARD8 deviceid; + CARD8 pad0; + CARD16 pad1; +} xChangeDeviceCursorReq; + /********************************************************** * From ad2edb61ffd8baf87b9ab249aa36b0c04a765f79 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 9 Jan 2007 13:32:39 +1030 Subject: [PATCH 028/388] Fix typo in DevicePresence() macro --- XInput.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XInput.h b/XInput.h index e4066b1..e3585b4 100644 --- a/XInput.h +++ b/XInput.h @@ -151,7 +151,7 @@ SOFTWARE. #define DevicePresence(dpy, type, _class) \ { \ - extern int_XiGetDevicePresenceNotifyEvent(Display *); \ + extern int _XiGetDevicePresenceNotifyEvent(Display *); \ type = _XiGetDevicePresenceNotifyEvent(dpy); \ _class = (0x10000 | _devicePresence); \ } From b50c4424020d1b2b641ce15ee3ffea41a287a160 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 10 Jan 2007 14:53:01 +1030 Subject: [PATCH 029/388] add deviceEnterNotify event, DeviceEnterNotify, DeviceLeaveNotify support add MPX Major/Minor version numbers --- Changelog | 10 ---------- XI.h | 6 ++++++ XInput.h | 34 ++++++++++++++++++++++++++++++++++ XIproto.h | 32 +++++++++++++++++++++++++++++++- 4 files changed, 71 insertions(+), 11 deletions(-) delete mode 100644 Changelog diff --git a/Changelog b/Changelog deleted file mode 100644 index 5dcf225..0000000 --- a/Changelog +++ /dev/null @@ -1,10 +0,0 @@ -MPX changelog - -== 08.01.07 == - add ChangeDeviceCursor request - -== 20.12.06 == - add QueryDevicePointer request + reply - add WarpDevicePointer request - - diff --git a/XI.h b/XI.h index 6573310..3335c7d 100644 --- a/XI.h +++ b/XI.h @@ -161,6 +161,9 @@ SOFTWARE. #define XI_Add_DevicePresenceNotify_Major 1 #define XI_Add_DevicePresenceNotify_Minor 4 +#define XI_Add_MPX_Major 1 +#define XI_Add_MPX_Minor 5 + #define DEVICE_RESOLUTION 1 #define DEVICE_ABS_CALIB 2 #define DEVICE_CORE 3 @@ -254,6 +257,9 @@ SOFTWARE. #define _devicePresence 0 +#define _deviceEnter 0 +#define _deviceLeave 1 + #define XI_BadDevice 0 #define XI_BadEvent 1 #define XI_BadMode 2 diff --git a/XInput.h b/XInput.h index e5239ff..16c5a45 100644 --- a/XInput.h +++ b/XInput.h @@ -72,6 +72,9 @@ SOFTWARE. #define _deviceStateNotify 0 #define _deviceMappingNotify 1 #define _changeDeviceNotify 2 +/* Space of 4 between is necessary! */ +#define _deviceEnterNotify 6 +#define _deviceLeaveNotify 7 #define FindTypeAndClass(d,type,_class,classid,offset) \ { int _i; XInputClassInfo *_ip; \ @@ -156,6 +159,12 @@ SOFTWARE. _class = (0x10000 | _devicePresence); \ } +#define DeviceEnterNotify(d, type, _class) \ + FindTypeAndClass(d, type, _class, OtherClass, _deviceEnterNotify); + +#define DeviceLeaveNotify(d, type, _class) \ + FindTypeAndClass(d, type, _class, OtherClass, _deviceLeaveNotify); + #define BadDevice(dpy,error) _xibaddevice(dpy, &error) #define BadClass(dpy,error) _xibadclass(dpy, &error) @@ -448,6 +457,31 @@ typedef struct { XID control; } XDevicePresenceNotifyEvent; + +typedef struct { + int type; + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; /* "event" window reported relative to */ + Window root; /* root window that the event occurred on */ + Window subwindow; /* child window */ + XID deviceid; + Time time; /* milliseconds */ + int x, y; /* pointer x, y coordinates in event window */ + int x_root, y_root; /* coordinates relative to root */ + int mode; /* NotifyNormal, NotifyGrab, NotifyUngrab */ + int detail; + /* + * NotifyAncestor, NotifyVirtual, NotifyInferior, + * NotifyNonlinear,NotifyNonlinearVirtual + */ + unsigned int state; /* key or button mask */ +} XDeviceCrossingEvent; + +typedef XDeviceCrossingEvent XDeviceLeaveWindowEvent; +typedef XDeviceCrossingEvent XDeviceEnterWindowEvent; + /******************************************************************* * * Control structures for input devices that support input class diff --git a/XIproto.h b/XIproto.h index 541e9a2..89f171a 100644 --- a/XIproto.h +++ b/XIproto.h @@ -72,7 +72,7 @@ SOFTWARE. #define numInputClasses 7 -#define IEVENTS 16 +#define IEVENTS 18 #define IERRORS 5 #define CLIENT_REQ 1 @@ -114,6 +114,8 @@ struct tmask #define XI_DeviceKeystateNotify 13 #define XI_DeviceButtonstateNotify 14 #define XI_DevicePresenceNotify 15 +#define XI_DeviceEnterNotify 16 +#define XI_DeviceLeaveNotify 17 /********************************************************* * @@ -1690,6 +1692,34 @@ typedef struct } devicePresenceNotify; +/********************************************************** + * + * deviceEnterNotify. + * + */ + +typedef struct + { + BYTE type; + BYTE pad00; + CARD16 sequenceNumber B16; + Time time B32; + Window root B32; + Window event B32; + Window child B32; + INT16 rootX B16; + INT16 rootY B16; + INT16 eventX B16; + INT16 eventY B16; + KeyButMask state B16; + BYTE mode; + /* flags are missing */ + CARD8 deviceid; + } deviceEnterNotify; + +typedef deviceEnterNotify deviceLeaveNotify; + + #undef Window #undef Time #undef KeyCode From 4ab02ccbdad477a0d7a0bee79c947f50826f1a36 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 29 Jan 2007 18:18:56 +1030 Subject: [PATCH 030/388] add ChangePointerKeyboardPairing request add pairingChangedNotify event --- XI.h | 3 +++ XInput.h | 30 ++++++++++++++++++++++++++++++ XIproto.h | 41 ++++++++++++++++++++++++++++++++++++++++- 3 files changed, 73 insertions(+), 1 deletion(-) diff --git a/XI.h b/XI.h index 3335c7d..52f8c4d 100644 --- a/XI.h +++ b/XI.h @@ -114,6 +114,7 @@ SOFTWARE. #define sz_xQueryDevicePointerReply 32 #define sz_xWarpDevicePointerReq 28 #define sz_xChangeDeviceCursorReq 16 +#define sz_xChangePointerKeyboardPairingReq 8 #define INAME "XInputExtension" @@ -256,10 +257,12 @@ SOFTWARE. #define _noExtensionEvent 9 #define _devicePresence 0 +#define _pairingChanged 1 #define _deviceEnter 0 #define _deviceLeave 1 + #define XI_BadDevice 0 #define XI_BadEvent 1 #define XI_BadMode 2 diff --git a/XInput.h b/XInput.h index 16c5a45..90a3ca3 100644 --- a/XInput.h +++ b/XInput.h @@ -159,6 +159,13 @@ SOFTWARE. _class = (0x10000 | _devicePresence); \ } +#define PointerKeyboardPairing(dpy, type, _class) \ + { \ + extern int _XiGetPointerKeyboardPairingNotifyEvent(Display *); \ + type = _XiGetPointerKeyboardPairingNotifyEvent(Display *); \ + _class = (0x10000 | _pairingNotify); \ + } + #define DeviceEnterNotify(d, type, _class) \ FindTypeAndClass(d, type, _class, OtherClass, _deviceEnterNotify); @@ -482,6 +489,23 @@ typedef struct { typedef XDeviceCrossingEvent XDeviceLeaveWindowEvent; typedef XDeviceCrossingEvent XDeviceEnterWindowEvent; +/* + * Notifies the client that a mouse/keyboard mapping has changed. A mouse may + * have several keyboards mapped to it, but a keyboard can only map to one + * mouse. + * Keyboard events will follow the focus of the given mouse. + */ +typedef struct { + int type; + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; /* unused */ + Time time; + XID pointerid; /* pointer deviceid */ + XID keyboardid; /* keyboard deviceid */ +} XPointerKeyboardPairingChangedNotifyEvent; + /******************************************************************* * * Control structures for input devices that support input class @@ -1256,6 +1280,12 @@ extern Status XUndefineDeviceCursor( Window /* win */ ); +extern Status XChangePointerKeyboardPairing( + Display* /* display */, + XDevice* /* pointer */, + XDevice* /* keyboard*/ +); + _XFUNCPROTOEND diff --git a/XIproto.h b/XIproto.h index 89f171a..1e941c1 100644 --- a/XIproto.h +++ b/XIproto.h @@ -72,7 +72,7 @@ SOFTWARE. #define numInputClasses 7 -#define IEVENTS 18 +#define IEVENTS 19 #define IERRORS 5 #define CLIENT_REQ 1 @@ -116,6 +116,7 @@ struct tmask #define XI_DevicePresenceNotify 15 #define XI_DeviceEnterNotify 16 #define XI_DeviceLeaveNotify 17 +#define XI_PointerKeyboardPairingChangedNotify 18 /********************************************************* * @@ -161,6 +162,7 @@ struct tmask #define X_QueryDevicePointer 36 #define X_WarpDevicePointer 37 #define X_ChangeDeviceCursor 38 +#define X_ChangePointerKeyboardPairing 39 /********************************************************* * @@ -1493,6 +1495,20 @@ typedef struct { CARD16 pad1; } xChangeDeviceCursorReq; +/********************************************************** + * + * ChangePointerKeyboardPairing. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_ChangePointerKeyboardPairing */ + CARD16 length B16; + CARD8 pointer; /* ID of pointer devices */ + CARD8 keyboard; /* ID of keyboard device */ + CARD16 pad0; +} xChangePointerKeyboardPairingReq; /********************************************************** * @@ -1719,6 +1735,29 @@ typedef struct typedef deviceEnterNotify deviceLeaveNotify; +/********************************************************** + * + * pairingChangedNotify. + * + */ + +typedef struct + { + BYTE type; + BYTE pad00; + CARD16 sequenceNumber B16; + Time time B32; + CARD8 pointer; + CARD8 keyboard; + CARD16 pad0; + CARD32 pad1; + CARD32 pad2; + CARD32 pad3; + CARD32 pad4; + CARD32 pad5; + CARD32 pad6; + } pairingChangedNotify; + #undef Window #undef Time From 328cd827e89424292ca020d0b828154f8e4f2c17 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 8 Feb 2007 10:54:34 +1030 Subject: [PATCH 031/388] add flags field to deviceEnterNotify struct add same_screen, focus to XDeviceCrossingEvent struct --- XInput.h | 2 ++ XIproto.h | 5 ++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/XInput.h b/XInput.h index 90a3ca3..13d1dff 100644 --- a/XInput.h +++ b/XInput.h @@ -483,6 +483,8 @@ typedef struct { * NotifyAncestor, NotifyVirtual, NotifyInferior, * NotifyNonlinear,NotifyNonlinearVirtual */ + Bool same_screen; /* same screen flag */ + Bool focus; /* boolean focus */ unsigned int state; /* key or button mask */ } XDeviceCrossingEvent; diff --git a/XIproto.h b/XIproto.h index 1e941c1..ad61c0e 100644 --- a/XIproto.h +++ b/XIproto.h @@ -1717,7 +1717,7 @@ typedef struct typedef struct { BYTE type; - BYTE pad00; + CARD8 deviceid; CARD16 sequenceNumber B16; Time time B32; Window root B32; @@ -1729,8 +1729,7 @@ typedef struct INT16 eventY B16; KeyButMask state B16; BYTE mode; - /* flags are missing */ - CARD8 deviceid; + BYTE flags; } deviceEnterNotify; typedef deviceEnterNotify deviceLeaveNotify; From 157a7984f1d2e2630191b6d392bc15975a3786db Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 9 Feb 2007 11:37:54 +1030 Subject: [PATCH 032/388] add missing XWarpDevicePointer declaration --- XInput.h | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/XInput.h b/XInput.h index fcc5eae..96696ba 100644 --- a/XInput.h +++ b/XInput.h @@ -1269,6 +1269,19 @@ extern Bool XQueryDevicePointer( Bool* /* shared */ ); +extern Bool XWarpDevicePointer( + Display* /* display */, + XDevice* /* device */, + Window /* src_win */, + Window /* dst_win */, + int /* src_x */, + int /* src_y */, + unsigned int /* src_width */, + unsigned int /* src_height */, + int /* dst_x */, + int /* dst_y */ +); + extern Status XDefineDeviceCursor( Display* /* display */, XDevice* /* device */, From c608d82c6b5b87ddc8d14862f528bdd69f5f5b72 Mon Sep 17 00:00:00 2001 From: Daniel Stone Date: Thu, 15 Feb 2007 16:33:07 +0200 Subject: [PATCH 033/388] bump to 1.4.1 --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index aa96cc1..057e1c5 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.4], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.4.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) XORG_RELEASE_VERSION From bb5c144c53fcb03c56b247b439915d72ad284856 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 21 Feb 2007 10:03:24 +1030 Subject: [PATCH 034/388] add xRegisterPairingClient request and reply --- XI.h | 2 ++ XInput.h | 7 +++++++ XIproto.h | 31 +++++++++++++++++++++++++++++++ 3 files changed, 40 insertions(+) diff --git a/XI.h b/XI.h index 52f8c4d..11a1416 100644 --- a/XI.h +++ b/XI.h @@ -115,6 +115,8 @@ SOFTWARE. #define sz_xWarpDevicePointerReq 28 #define sz_xChangeDeviceCursorReq 16 #define sz_xChangePointerKeyboardPairingReq 8 +#define sz_xRegisterPairingClientReq 8 +#define sz_xRegisterPairingClientReply 32 #define INAME "XInputExtension" diff --git a/XInput.h b/XInput.h index 96696ba..a954ab1 100644 --- a/XInput.h +++ b/XInput.h @@ -1301,6 +1301,13 @@ extern Status XChangePointerKeyboardPairing( XDevice* /* keyboard*/ ); +extern Bool XRegisterPairingClient( + Display* /* display */ +); + +extern Bool XUnregisterPairingClient( + Display* /* display */ +); _XFUNCPROTOEND diff --git a/XIproto.h b/XIproto.h index ad61c0e..7a18c2b 100644 --- a/XIproto.h +++ b/XIproto.h @@ -163,6 +163,7 @@ struct tmask #define X_WarpDevicePointer 37 #define X_ChangeDeviceCursor 38 #define X_ChangePointerKeyboardPairing 39 +#define X_RegisterPairingClient 40 /********************************************************* * @@ -1510,6 +1511,36 @@ typedef struct { CARD16 pad0; } xChangePointerKeyboardPairingReq; +/********************************************************** + * + * ChangePointerKeyboardPairing. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_RegisterPairingClient */ + CARD16 length B16; + CARD8 disable; /* True to disable registration */ + CARD8 pad0; + CARD16 pad1; +} xRegisterPairingClientReq; + +typedef struct { + CARD8 repType; /* input extension major code */ + CARD8 RepType; /* always X_RegisterPairingClient */ + CARD16 sequenceNumber B16; + CARD32 length B16; /* 0 */ + CARD8 success; /* True on success, false otherwise */ + CARD8 pad0; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; +} xRegisterPairingClientReply; + /********************************************************** * * Input extension events. From de6f3fcaffe204e8f7c811f8a1599e9ed0999f9c Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 22 Feb 2007 20:03:36 +1030 Subject: [PATCH 035/388] add access control requests. fix wrong field lengths for RegisterPairing request and reply. --- XI.h | 21 +++++++++++-- XInput.h | 43 +++++++++++++++++++++++++++ XIproto.h | 88 +++++++++++++++++++++++++++++++++++++++++++++++++++++-- 3 files changed, 147 insertions(+), 5 deletions(-) diff --git a/XI.h b/XI.h index 11a1416..d0bfc92 100644 --- a/XI.h +++ b/XI.h @@ -114,9 +114,14 @@ SOFTWARE. #define sz_xQueryDevicePointerReply 32 #define sz_xWarpDevicePointerReq 28 #define sz_xChangeDeviceCursorReq 16 -#define sz_xChangePointerKeyboardPairingReq 8 -#define sz_xRegisterPairingClientReq 8 +#define sz_xChangePointerKeyboardPairingReq 8 +#define sz_xRegisterPairingClientReq 8 #define sz_xRegisterPairingClientReply 32 +#define sz_xGrabAccessControlReq 8 +#define sz_xGrabAccessControlReply 32 +#define sz_xChangeWindowAccessReq 12 +#define sz_xQueryWindowAccessReq 8 +#define sz_xQueryWindowAccessReply 32 #define INAME "XInputExtension" @@ -264,6 +269,18 @@ SOFTWARE. #define _deviceEnter 0 #define _deviceLeave 1 +/* Flags for ChangeWindowAccess defaultRule. Pick one. */ +#define WindowAccessNoRule 0 +#define WindowAccessKeepRule 1 +#define WindowAccessDenyAll 2 + +/* Flags for ChangeWindowAccess. */ +#define WindowAccessClearNone 0 +#define WindowAccessClearPerm (1) +#define WindowAccessClearDeny (1 << 1) +#define WindowAccessClearRule (1 << 2) +#define WindowAccessClearAll \ + WindowAccessClearPerm | WindowAccessClearDeny | WindowAccessClearRule #define XI_BadDevice 0 #define XI_BadEvent 1 diff --git a/XInput.h b/XInput.h index a954ab1..df47da2 100644 --- a/XInput.h +++ b/XInput.h @@ -1309,6 +1309,49 @@ extern Bool XUnregisterPairingClient( Display* /* display */ ); +extern Bool XGrabAccessControl( + Display* /* display */ +); + +extern Bool XUngrabAccessControl( + Display* /* display */ +); + +extern Bool XClearAccessControl( + Display* /* display*/, + int /* what */ +); + +extern Bool XChangeAcccessRule( + Display* /* display */, + int /* rule */ +); + +extern Status XPermitDevices( + Display* /* display */, + Window /* win */, + char* /* deviceids */, + int /* ndevices */ +); + +extern Status XDenyDevices( + Display* /* display */, + Window /* win */, + char* /* deviceids */, + int /* ndevices */ +); + +extern Status XQueryWindowAccess( + Display* /* dpy */, + Window /* win */, + int* /* rule */, + char** /* permdevices */, + int* /* nperm */, + char** /* denydevices */, + int* /* ndeny */ +); + + _XFUNCPROTOEND #endif /* _XINPUT_H_ */ diff --git a/XIproto.h b/XIproto.h index 7a18c2b..418be4b 100644 --- a/XIproto.h +++ b/XIproto.h @@ -164,6 +164,9 @@ struct tmask #define X_ChangeDeviceCursor 38 #define X_ChangePointerKeyboardPairing 39 #define X_RegisterPairingClient 40 +#define X_GrabAccessControl 41 +#define X_ChangeWindowAccess 42 +#define X_QueryWindowAccess 43 /********************************************************* * @@ -1513,7 +1516,7 @@ typedef struct { /********************************************************** * - * ChangePointerKeyboardPairing. + * RegisterPairingClient. * */ @@ -1523,14 +1526,14 @@ typedef struct { CARD16 length B16; CARD8 disable; /* True to disable registration */ CARD8 pad0; - CARD16 pad1; + CARD16 pad1 B16; } xRegisterPairingClientReq; typedef struct { CARD8 repType; /* input extension major code */ CARD8 RepType; /* always X_RegisterPairingClient */ CARD16 sequenceNumber B16; - CARD32 length B16; /* 0 */ + CARD32 length B32; /* 0 */ CARD8 success; /* True on success, false otherwise */ CARD8 pad0; CARD16 pad1 B16; @@ -1541,6 +1544,85 @@ typedef struct { CARD32 pad6 B32; } xRegisterPairingClientReply; +/********************************************************** + * + * GrabAccessControl. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GrabAccessControl */ + CARD16 length B16; + BOOL ungrab; /* true if request is ungrab request */ + CARD8 pad0, pad1, pad2; +} xGrabAccessControlReq; + +typedef struct { + CARD8 repType; /* input extension major code */ + CARD8 RepType; /* always X_GrabAccessControl */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 success; + CARD8 pad0, + pad1, + pad2; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; + CARD32 pad7 B32; +} xGrabAccessControlReply; + +/********************************************************** + * + * ChangeWindowAccess. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major opcode */ + CARD8 ReqType; /* Always X_ChangeWindowAccess */ + CARD16 length B16; + Window win B32; + CARD8 npermit; /* number of devices for permit rule */ + CARD8 ndeny; /* number of devices for deny rule */ + CARD8 defaultRule; /* default rule */ + CARD8 clear; /* WindowAccessClearPerm, + WindowAccessClearDeny, + WindowAccessClearRule, + WindowAccessClearAll */ +} xChangeWindowAccessReq; + +/********************************************************** + * + * QueryAccessToWindow. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_RegisterAccessControl */ + CARD16 length B16; + Window win B32; +} xQueryWindowAccessReq; + +typedef struct { + CARD8 repType; /* input extension major opcode */ + CARD8 RepType; /* Always X_ChangeAccessToWindow */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 defaultRule; /* default rule setting */ + CARD8 npermit; /* number of devices in permit */ + CARD8 ndeny; /* number of devices in deny */ + CARD8 pad0; + CARD32 pad1 B32; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; +} xQueryWindowAccessReply; + /********************************************************** * * Input extension events. From 9dd8dcfa7e084d94cf3b7429eae65c93416159e3 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 9 Mar 2007 15:51:07 +1030 Subject: [PATCH 036/388] add SetClientPointer request. fix typos and wrong names for access function declarations. --- XI.h | 1 + XInput.h | 12 ++++++++++-- XIproto.h | 26 +++++++++++++++++++++++--- 3 files changed, 34 insertions(+), 5 deletions(-) diff --git a/XI.h b/XI.h index d0bfc92..ad50164 100644 --- a/XI.h +++ b/XI.h @@ -122,6 +122,7 @@ SOFTWARE. #define sz_xChangeWindowAccessReq 12 #define sz_xQueryWindowAccessReq 8 #define sz_xQueryWindowAccessReply 32 +#define sz_xSetClientPointerReq 12 #define INAME "XInputExtension" diff --git a/XInput.h b/XInput.h index df47da2..46216f8 100644 --- a/XInput.h +++ b/XInput.h @@ -1317,13 +1317,15 @@ extern Bool XUngrabAccessControl( Display* /* display */ ); -extern Bool XClearAccessControl( +extern Bool XWindowClearAccess( Display* /* display*/, + Window /* win */, int /* what */ ); -extern Bool XChangeAcccessRule( +extern Bool XChangeAccessRule( Display* /* display */, + Window /* win */, int /* rule */ ); @@ -1351,6 +1353,12 @@ extern Status XQueryWindowAccess( int* /* ndeny */ ); +extern Status XSetClientPointer( + Display* /* dpy */, + Window /* win */, + char /* deviceid */ +); + _XFUNCPROTOEND diff --git a/XIproto.h b/XIproto.h index 418be4b..3753bea 100644 --- a/XIproto.h +++ b/XIproto.h @@ -167,6 +167,7 @@ struct tmask #define X_GrabAccessControl 41 #define X_ChangeWindowAccess 42 #define X_QueryWindowAccess 43 +#define X_SetClientPointer 44 /********************************************************* * @@ -1596,20 +1597,20 @@ typedef struct { /********************************************************** * - * QueryAccessToWindow. + * QueryWindowAccess * */ typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_RegisterAccessControl */ + CARD8 ReqType; /* always X_QueryWindowAccess */ CARD16 length B16; Window win B32; } xQueryWindowAccessReq; typedef struct { CARD8 repType; /* input extension major opcode */ - CARD8 RepType; /* Always X_ChangeAccessToWindow */ + CARD8 RepType; /* Always X_QueryWindowAccess */ CARD16 sequenceNumber B16; CARD32 length B32; CARD8 defaultRule; /* default rule setting */ @@ -1623,6 +1624,25 @@ typedef struct { CARD32 pad5 B32; } xQueryWindowAccessReply; + + +/********************************************************** + * + * SetClientPointer. + * + */ + +typedef struct { + CARD8 reqType; + CARD8 ReqType; /* Always X_SetClientPointer */ + CARD16 length B16; + Window win B32; + CARD8 deviceid; + CARD8 pad0; + CARD16 pad1 B16; +} xSetClientPointerReq; + + /********************************************************** * * Input extension events. From 4ed9be75a5d3d75782351269481db5856f7e3f60 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 22 Mar 2007 17:27:32 +1030 Subject: [PATCH 037/388] add GetClientPointer request and reply. add GetPairedPointer request and reply. move declaration of _XiGetDevicePresenceNotifyEvent out of the macro and wrap it between extern "C". Otherwise C++ code won't be able to find it. --- XI.h | 5 ++++- XInput.h | 23 +++++++++++++++++++++- XIproto.h | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 85 insertions(+), 2 deletions(-) diff --git a/XI.h b/XI.h index ad50164..d561fcf 100644 --- a/XI.h +++ b/XI.h @@ -50,7 +50,6 @@ SOFTWARE. /* Definitions used by the server, library and client */ #ifndef _XI_H_ - #define _XI_H_ #define sz_xGetExtensionVersionReq 8 @@ -123,6 +122,10 @@ SOFTWARE. #define sz_xQueryWindowAccessReq 8 #define sz_xQueryWindowAccessReply 32 #define sz_xSetClientPointerReq 12 +#define sz_xGetClientPointerReq 8 +#define sz_xGetClientPointerReply 32 +#define sz_xGetPairedPointerReq 8 +#define sz_xGetPairedPointerReply 32 #define INAME "XInputExtension" diff --git a/XInput.h b/XInput.h index 46216f8..9e95993 100644 --- a/XInput.h +++ b/XInput.h @@ -152,9 +152,18 @@ SOFTWARE. #define NoExtensionEvent(d,type,_class) \ { _class = ((XDevice *) d)->device_id << 8 | _noExtensionEvent;} + +/* We need the declaration for DevicePresence. */ +#if defined(__cplusplus) || defined(c_plusplus) +extern "C" { +#endif + extern int _XiGetDevicePresenceNotifyEvent(Display *); +#if defined(__cplusplus) || defined(c_plusplus) +} +#endif + #define DevicePresence(dpy, type, _class) \ { \ - extern int _XiGetDevicePresenceNotifyEvent(Display *); \ type = _XiGetDevicePresenceNotifyEvent(dpy); \ _class = (0x10000 | _devicePresence); \ } @@ -1301,6 +1310,12 @@ extern Status XChangePointerKeyboardPairing( XDevice* /* keyboard*/ ); +extern Bool XGetPairedPointer( + Display* /* display */, + XDevice* /* keyboard */, + int* /* deviceid */ +); + extern Bool XRegisterPairingClient( Display* /* display */ ); @@ -1359,6 +1374,12 @@ extern Status XSetClientPointer( char /* deviceid */ ); +extern Bool XGetClientPointer( + Display* /* dpy */, + Window /* win */, + int* /* deviceid */ +); + _XFUNCPROTOEND diff --git a/XIproto.h b/XIproto.h index 3753bea..8905489 100644 --- a/XIproto.h +++ b/XIproto.h @@ -168,6 +168,8 @@ struct tmask #define X_ChangeWindowAccess 42 #define X_QueryWindowAccess 43 #define X_SetClientPointer 44 +#define X_GetClientPointer 45 +#define X_GetPairedPointer 46 /********************************************************* * @@ -1643,6 +1645,63 @@ typedef struct { } xSetClientPointerReq; +/********************************************************** + * + * GetClientPointer. + * + */ +typedef struct { + CARD8 reqType; + CARD8 ReqType; /* Always X_GetClientPointer */ + CARD16 length B16; + Window win B32; +} xGetClientPointerReq; + +typedef struct { + CARD8 repType; /* input extension major opcode */ + CARD8 RepType; /* Always X_GetClientPointer */ + CARD16 sequenceNumber B16; + CARD32 length B32; + BOOL set; /* client pointer is set */ + CARD8 deviceid; + CARD16 pad0 B16; + CARD32 pad1 B32; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; +} xGetClientPointerReply; + +/********************************************************** + * + * GetPairedPointer. + * + */ + +typedef struct { + CARD8 reqType; + CARD8 ReqType; /* Always X_GetPairedPointer */ + CARD16 length B16; + CARD8 deviceid; + CARD8 pad0; + CARD16 pad1 B16; +} xGetPairedPointerReq; + +typedef struct { + CARD8 repType; /* input extension major opcode */ + CARD8 RepType; /* Always X_GetClientPointer */ + CARD16 sequenceNumber B16; + CARD32 length B32; + BOOL paired; /* keyboard is paired */ + CARD8 deviceid; + CARD16 pad0 B16; + CARD32 pad1 B32; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; +} xGetPairedPointerReply; + /********************************************************** * * Input extension events. From a928365b91a2e25d02291844e430db9a9a62673d Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 22 Mar 2007 21:14:11 +1030 Subject: [PATCH 038/388] Change XSetClientPointer API to use an XDevice instead of deviceid. --- XInput.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XInput.h b/XInput.h index 9e95993..617b4cc 100644 --- a/XInput.h +++ b/XInput.h @@ -1371,7 +1371,7 @@ extern Status XQueryWindowAccess( extern Status XSetClientPointer( Display* /* dpy */, Window /* win */, - char /* deviceid */ + XDevice* /* device */ ); extern Bool XGetClientPointer( From c9bed7d4750c314002c16430a4dd75f95cc2f78d Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 24 Apr 2007 22:53:27 +0930 Subject: [PATCH 039/388] Add flags to be used for DevicePrensence's devchange field. --- XI.h | 6 ++++++ XIproto.h | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/XI.h b/XI.h index fbecd80..ae52292 100644 --- a/XI.h +++ b/XI.h @@ -250,6 +250,12 @@ SOFTWARE. #define _devicePresence 0 +#define DeviceAdded 0 +#define DeviceRemoved 1 +#define DeviceEnabled 2 +#define DeviceDisabled 3 +#define DeviceUnrecoverable 4 + #define XI_BadDevice 0 #define XI_BadEvent 1 #define XI_BadMode 2 diff --git a/XIproto.h b/XIproto.h index 36b5a49..4f46f4f 100644 --- a/XIproto.h +++ b/XIproto.h @@ -1600,7 +1600,7 @@ typedef struct BYTE pad00; CARD16 sequenceNumber B16; Time time B32; - BYTE devchange; + BYTE devchange; /* Device{Added|Removed|Enabled|Disabled} */ BYTE deviceid; CARD16 control B16; CARD32 pad02 B32; From 310a93f8e194aa070b0f1d40c8fd5ae941908dbe Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 26 Apr 2007 11:06:18 +0930 Subject: [PATCH 040/388] bump to 1.4.2 --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 057e1c5..72f9882 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.4.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.4.2], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) XORG_RELEASE_VERSION From ce7bbfb7e0ecaf977c4ec8e760c634cebf8ac167 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 1 May 2007 22:31:09 +0930 Subject: [PATCH 041/388] Add XGE support and event types for RawDeviceEvent and PairingChanged event. --- XI.h | 6 ++++ XInput.h | 52 ++++++++++++++++++++++++++------ XIproto.h | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++----- 3 files changed, 130 insertions(+), 16 deletions(-) diff --git a/XI.h b/XI.h index a9b96c5..6e00ba1 100644 --- a/XI.h +++ b/XI.h @@ -126,6 +126,7 @@ SOFTWARE. #define sz_xGetClientPointerReply 32 #define sz_xGetPairedPointerReq 8 #define sz_xGetPairedPointerReply 32 +#define sz_xXiSelectEventReq 12 #define INAME "XInputExtension" @@ -298,6 +299,11 @@ SOFTWARE. #define XI_DeviceBusy 3 #define XI_BadClass 4 +/* GE masks */ +#define XI_PointerKeyboardPairingChangedMask (1 << 0) +#define XI_RandomStringMask (1 << 1) +#define XI_RawDeviceEventMask (1 << 2) + /* Make XEventClass be a CARD32 for 64 bit servers. Don't affect client * definition of XEventClass since that would be a library interface change. * See the top of X.h for more _XSERVER64 magic. diff --git a/XInput.h b/XInput.h index 617b4cc..7f6fcb9 100644 --- a/XInput.h +++ b/XInput.h @@ -168,19 +168,13 @@ extern "C" { _class = (0x10000 | _devicePresence); \ } -#define PointerKeyboardPairing(dpy, type, _class) \ - { \ - extern int _XiGetPointerKeyboardPairingNotifyEvent(Display *); \ - type = _XiGetPointerKeyboardPairingNotifyEvent(Display *); \ - _class = (0x10000 | _pairingNotify); \ - } - #define DeviceEnterNotify(d, type, _class) \ FindTypeAndClass(d, type, _class, OtherClass, _deviceEnterNotify); #define DeviceLeaveNotify(d, type, _class) \ FindTypeAndClass(d, type, _class, OtherClass, _deviceLeaveNotify); +/* Errors */ #define BadDevice(dpy,error) _xibaddevice(dpy, &error) #define BadClass(dpy,error) _xibadclass(dpy, &error) @@ -507,16 +501,51 @@ typedef XDeviceCrossingEvent XDeviceEnterWindowEvent; * Keyboard events will follow the focus of the given mouse. */ typedef struct { - int type; + int type; /* GenericEvent */ unsigned long serial; /* # of last request processed by server */ Bool send_event; /* true if this came from a SendEvent request */ Display *display; /* Display the event was read from */ - Window window; /* unused */ + int extension; /* XI extension offset */ + int evtype; /* PointerKeyboardPairingCHangedNotify */ Time time; XID pointerid; /* pointer deviceid */ XID keyboardid; /* keyboard deviceid */ } XPointerKeyboardPairingChangedNotifyEvent; + +/* + * XRandomStringEvent. + * FOR TESTING ONLY. DO NOT USE. + */ + +typedef struct { + int type; /* GenericEvent */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + int extension; /* XI extension offset */ + int evtype; /* RandomStringEvent */ + char* string; +} XRandomStringEvent; + +/* + * RawDeviceEvent. + * Data as received directly from the device. + */ +typedef struct { + int type; /* GenericEvent */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + int extension; /* XI extension offset */ + int evtype; /* XI_RawDeviceEvent */ + int buttons; + int num_valuators; + int first_valuator; + int* valuators; +} XRawDeviceEvent; + + /******************************************************************* * * Control structures for input devices that support input class @@ -1380,6 +1409,11 @@ extern Bool XGetClientPointer( int* /* deviceid */ ); +extern Status XiSelectEvent( + Display* /* dpy */, + Window /* win */, + Mask /* mask */ +); _XFUNCPROTOEND diff --git a/XIproto.h b/XIproto.h index dadccab..918aae3 100644 --- a/XIproto.h +++ b/XIproto.h @@ -57,6 +57,7 @@ SOFTWARE. #define Window CARD32 #define Time CARD32 #define KeyCode CARD8 +#define Mask CARD32 /********************************************************* * @@ -72,7 +73,7 @@ SOFTWARE. #define numInputClasses 7 -#define IEVENTS 19 +#define IEVENTS 18 #define IERRORS 5 #define CLIENT_REQ 1 @@ -116,7 +117,12 @@ struct tmask #define XI_DevicePresenceNotify 15 #define XI_DeviceEnterNotify 16 #define XI_DeviceLeaveNotify 17 -#define XI_PointerKeyboardPairingChangedNotify 18 + +/* GE events */ +#define XI_PointerKeyboardPairingChangedNotify 0 +#define XI_RandomStringEvent 1 +#define XI_RawDeviceEvent 2 + /********************************************************* * @@ -170,6 +176,7 @@ struct tmask #define X_SetClientPointer 44 #define X_GetClientPointer 45 #define X_GetPairedPointer 46 +#define X_XiSelectEvent 47 /********************************************************* * @@ -1702,6 +1709,22 @@ typedef struct { CARD32 pad5 B32; } xGetPairedPointerReply; + +/********************************************************** + * + * XiSelectevent. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major opcode */ + CARD8 ReqType; /* always X_XiSelectEvent */ + CARD16 length B16; + Window window B32; /* window to be changed */ + Mask mask B32; /* mask to be applied */ +} xXiSelectEventReq; + + /********************************************************** * * Input extension events. @@ -1934,10 +1957,12 @@ typedef deviceEnterNotify deviceLeaveNotify; typedef struct { - BYTE type; - BYTE pad00; + BYTE type; /* always GenericEvent */ + BYTE extension; /* Xi extension offset */ CARD16 sequenceNumber B16; - Time time B32; + CARD32 length B32; + CARD16 evtype B16; + CARD32 time B32; CARD8 pointer; CARD8 keyboard; CARD16 pad0; @@ -1945,13 +1970,62 @@ typedef struct CARD32 pad2; CARD32 pad3; CARD32 pad4; - CARD32 pad5; - CARD32 pad6; } pairingChangedNotify; +/********************************************************** + * + * RandomStringEvent. + * GE event, != 32 bytes. + * + * FOR TESTING, DO NOT USE THIS. + */ + +typedef struct + { + BYTE type; /* always GenericEvent */ + BYTE extension; /* XI extension offset */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD16 evtype B16; /* XI_RandomStringEvent */ + CARD16 slen B16; + CARD32 pad1 B32; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + } randomStringEvent; + +/********************************************************* + * RawDeviceEvent. + * + * GE event, may be larger than 32 bytes. If length is > 0, then the event is + * followed by (length * CARD32) fields denoting the values of valuator4 to + * valuator(num_valuators-1). + */ + +typedef struct + { + BYTE type; /* always GenericEvent */ + BYTE extension; /* XI extension offset */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD16 evtype B16; /* XI_RawDeviceEvent */ + CARD8 buttons; + CARD8 num_valuators; + CARD8 first_valuator; + CARD8 pad0; + CARD16 pad1; + CARD32 valuator0 B32; + CARD32 valuator1 B32; + CARD32 valuator2 B32; + CARD32 valuator3 B32; + } rawDeviceEvent; + + #undef Window #undef Time #undef KeyCode +#undef Mask #endif From b12514254cb1d2b91381b59251440b22e36052fb Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 2 May 2007 09:43:48 +0930 Subject: [PATCH 042/388] Providing a device id for a RawDeviceEvent may not be a bad idea. --- XInput.h | 1 + XIproto.h | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/XInput.h b/XInput.h index 7f6fcb9..c4318e3 100644 --- a/XInput.h +++ b/XInput.h @@ -539,6 +539,7 @@ typedef struct { Display *display; /* Display the event was read from */ int extension; /* XI extension offset */ int evtype; /* XI_RawDeviceEvent */ + int deviceid; int buttons; int num_valuators; int first_valuator; diff --git a/XIproto.h b/XIproto.h index 918aae3..9dfec78 100644 --- a/XIproto.h +++ b/XIproto.h @@ -2014,7 +2014,7 @@ typedef struct CARD8 buttons; CARD8 num_valuators; CARD8 first_valuator; - CARD8 pad0; + CARD8 deviceid; CARD16 pad1; CARD32 valuator0 B32; CARD32 valuator1 B32; From ccbe2e63123c58041a3c32ae6a21b05bd8c72b04 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 2 May 2007 18:19:11 +0930 Subject: [PATCH 043/388] Add xFakeDeviceDataReq --- XI.h | 4 ++++ XInput.h | 10 ++++++++++ XIproto.h | 24 ++++++++++++++++++++++++ 3 files changed, 38 insertions(+) diff --git a/XI.h b/XI.h index 6e00ba1..179b9a2 100644 --- a/XI.h +++ b/XI.h @@ -127,6 +127,7 @@ SOFTWARE. #define sz_xGetPairedPointerReq 8 #define sz_xGetPairedPointerReply 32 #define sz_xXiSelectEventReq 12 +#define sz_xFakeDeviceDataReq 12 #define INAME "XInputExtension" @@ -304,14 +305,17 @@ SOFTWARE. #define XI_RandomStringMask (1 << 1) #define XI_RawDeviceEventMask (1 << 2) + /* Make XEventClass be a CARD32 for 64 bit servers. Don't affect client * definition of XEventClass since that would be a library interface change. * See the top of X.h for more _XSERVER64 magic. */ #ifdef _XSERVER64 typedef CARD32 XEventClass; +typedef CARD32 ValuatorData; #else typedef unsigned long XEventClass; +typedef unsigned long ValuatorData; #endif /******************************************************************* diff --git a/XInput.h b/XInput.h index c4318e3..65d95d5 100644 --- a/XInput.h +++ b/XInput.h @@ -1416,6 +1416,16 @@ extern Status XiSelectEvent( Mask /* mask */ ); +extern Status XFakeDeviceData( + Display* /* dpy */, + XDevice* /* dev */, + int /* type */, + int /* buttons */, + int /* num_valuators */, + int /* first_valuator */, + ValuatorData* /* valuators */ +); + _XFUNCPROTOEND #endif /* _XINPUT_H_ */ diff --git a/XIproto.h b/XIproto.h index 9dfec78..b904097 100644 --- a/XIproto.h +++ b/XIproto.h @@ -177,6 +177,7 @@ struct tmask #define X_GetClientPointer 45 #define X_GetPairedPointer 46 #define X_XiSelectEvent 47 +#define X_FakeDeviceData 48 /********************************************************* * @@ -1725,6 +1726,29 @@ typedef struct { } xXiSelectEventReq; +/********************************************************** + * + * FakeDeviceData. + * + * Followed by num_valuators * CARD32 fields that represent valuator data. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major opcode */ + CARD8 ReqType; /* always X_XiSelectEvent */ + CARD16 length B16; + CARD8 type; + CARD8 buttons; + CARD8 num_valuators; + CARD8 first_valuator; + CARD8 deviceid; + CARD8 pad0; + CARD16 pad1; +} xFakeDeviceDataReq; + + + /********************************************************** * * Input extension events. From 42a6b9b643d22ca8df64757cf497d2c7ac2dee65 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 14 May 2007 18:03:53 +0930 Subject: [PATCH 044/388] Add ExtendedGrabRequest and the matching reply. --- XI.h | 3 +++ XInput.h | 19 +++++++++++++++++++ XIproto.h | 41 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 63 insertions(+) diff --git a/XI.h b/XI.h index 179b9a2..921ea8d 100644 --- a/XI.h +++ b/XI.h @@ -51,6 +51,7 @@ SOFTWARE. #ifndef _XI_H_ #define _XI_H_ +#include #define sz_xGetExtensionVersionReq 8 #define sz_xGetExtensionVersionReply 32 @@ -128,6 +129,8 @@ SOFTWARE. #define sz_xGetPairedPointerReply 32 #define sz_xXiSelectEventReq 12 #define sz_xFakeDeviceDataReq 12 +#define sz_xExtendedGrabDeviceReq 28 +#define sz_xExtendedGrabDeviceReply 32 #define INAME "XInputExtension" diff --git a/XInput.h b/XInput.h index 65d95d5..baeab9b 100644 --- a/XInput.h +++ b/XInput.h @@ -54,6 +54,7 @@ SOFTWARE. #include #include +#include #define _deviceKeyPress 0 #define _deviceKeyRelease 1 @@ -1426,6 +1427,24 @@ extern Status XFakeDeviceData( ValuatorData* /* valuators */ ); +extern Status XExtendedGrabDevice( + Display* /* dpy */, + XDevice* /* dev */, + Window /* grab_win */, + int /* device_mode */, + Bool /* ownerEvents */, + Window /* confineTo */, + Cursor /* cursor */, + int /* event_count */, + XEventClass* /* event_list */, + int /* generic_event_count */, + XGenericEventMask* /* generic_events */ +); + +extern Status XExtendedUngrabDevice( + Display* /* dpy */, + XDevice* /* dev */); + _XFUNCPROTOEND #endif /* _XINPUT_H_ */ diff --git a/XIproto.h b/XIproto.h index b904097..962c04c 100644 --- a/XIproto.h +++ b/XIproto.h @@ -178,6 +178,7 @@ struct tmask #define X_GetPairedPointer 46 #define X_XiSelectEvent 47 #define X_FakeDeviceData 48 +#define X_ExtendedGrabDevice 49 /********************************************************* * @@ -1748,6 +1749,46 @@ typedef struct { } xFakeDeviceDataReq; +/************************************************************ + * + * ExtendedGrabDevice. + * + * This is a grab request to acommodate GE events. + * Event is followed by (event_count * XEventClass) bytes, followed by + * (ge_event_masks * GenericEventMask) bytes. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major opcode */ + CARD8 ReqType; /* always X_ExtendedGrabDevice */ + CARD16 length B16; + CARD32 grab_window B32; + Time time B32; + CARD8 ungrab; /* True if request is Ungrab request */ + CARD8 device_mode; /* GrabModeSync or GrabModeAsync */ + BOOL owner_events; + CARD8 deviceid; + Window confine_to B32; + Cursor cursor B32; + CARD16 event_count B16; + CARD16 generic_event_count B16; +} xExtendedGrabDeviceReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_ExtendedGrabDevice */ + CARD16 sequenceNumber B16; + CARD32 length B32; /* 0 */ + CARD8 status; + BYTE pad1, pad2, pad3; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; +} xExtendedGrabDeviceReply; + /********************************************************** * From 3d164140845c2ff65d84b56977b1722e95882f1c Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 17 May 2007 20:19:02 +0930 Subject: [PATCH 045/388] Add event_type to RawDeviceEvent to store matching core event type. --- XInput.h | 2 ++ XIproto.h | 4 +++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/XInput.h b/XInput.h index baeab9b..2494eaa 100644 --- a/XInput.h +++ b/XInput.h @@ -540,6 +540,8 @@ typedef struct { Display *display; /* Display the event was read from */ int extension; /* XI extension offset */ int evtype; /* XI_RawDeviceEvent */ + int event_type; /* MotionNotify, ButtonPress or + ButtonRelease*/ int deviceid; int buttons; int num_valuators; diff --git a/XIproto.h b/XIproto.h index 962c04c..182eca9 100644 --- a/XIproto.h +++ b/XIproto.h @@ -2080,7 +2080,9 @@ typedef struct CARD8 num_valuators; CARD8 first_valuator; CARD8 deviceid; - CARD16 pad1; + CARD8 event_type; /* one of MotionNotify, + ButtonPress, ButtonRelase */ + CARD8 pad0; CARD32 valuator0 B32; CARD32 valuator1 B32; CARD32 valuator2 B32; From 5e4ff6bf4590d856966f151529d27be0eb070804 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 17 May 2007 20:19:29 +0930 Subject: [PATCH 046/388] Move deviceid around in deviceEnterNotify, make room for detail field. --- XIproto.h | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/XIproto.h b/XIproto.h index 182eca9..eb86def 100644 --- a/XIproto.h +++ b/XIproto.h @@ -1991,13 +1991,14 @@ typedef struct /********************************************************** * * deviceEnterNotify. - * + * This has a slightly different layout than the core event. + * */ typedef struct { BYTE type; - CARD8 deviceid; + BYTE detail; CARD16 sequenceNumber B16; Time time B32; Window root B32; @@ -2009,7 +2010,7 @@ typedef struct INT16 eventY B16; KeyButMask state B16; BYTE mode; - BYTE flags; + CARD8 deviceid; } deviceEnterNotify; typedef deviceEnterNotify deviceLeaveNotify; From 0e9f8468ba15a55ddba7fb8c263a80091e9decde Mon Sep 17 00:00:00 2001 From: Paulo Ricardo Zanoni Date: Tue, 10 Jul 2007 10:16:06 +0930 Subject: [PATCH 047/388] Change some calls to use XID* instead of char* for device id lists. --- XInput.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/XInput.h b/XInput.h index 2494eaa..8bf11b1 100644 --- a/XInput.h +++ b/XInput.h @@ -1346,7 +1346,7 @@ extern Status XChangePointerKeyboardPairing( extern Bool XGetPairedPointer( Display* /* display */, XDevice* /* keyboard */, - int* /* deviceid */ + XID* /* deviceid */ ); extern Bool XRegisterPairingClient( @@ -1380,14 +1380,14 @@ extern Bool XChangeAccessRule( extern Status XPermitDevices( Display* /* display */, Window /* win */, - char* /* deviceids */, + XID* /* deviceids */, int /* ndevices */ ); extern Status XDenyDevices( Display* /* display */, Window /* win */, - char* /* deviceids */, + XID* /* deviceids */, int /* ndevices */ ); @@ -1395,9 +1395,9 @@ extern Status XQueryWindowAccess( Display* /* dpy */, Window /* win */, int* /* rule */, - char** /* permdevices */, + XID** /* permdevices */, int* /* nperm */, - char** /* denydevices */, + XID** /* denydevices */, int* /* ndeny */ ); @@ -1410,7 +1410,7 @@ extern Status XSetClientPointer( extern Bool XGetClientPointer( Display* /* dpy */, Window /* win */, - int* /* deviceid */ + XID* /* deviceid */ ); extern Status XiSelectEvent( From 96b0c13a5a689b3a6dbc4249ca4ef364f778c003 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 31 Aug 2007 17:58:27 +0930 Subject: [PATCH 048/388] Bump to 1.4.2.1 No source changes, the 1.4.2 tarball had a busted configure script. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 72f9882..c010699 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.4.2], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.4.2.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) XORG_RELEASE_VERSION From 369dd283cfcf006e2cfe3496ebc5157839a3d04e Mon Sep 17 00:00:00 2001 From: James Cloos Date: Mon, 3 Sep 2007 05:54:06 -0400 Subject: [PATCH 049/388] Add *~ to .gitignore to skip patch/emacs droppings --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 2c3bca3..503dd99 100644 --- a/.gitignore +++ b/.gitignore @@ -8,3 +8,4 @@ configure install-sh missing inputproto.pc +*~ From 4b22047f347d8fd65a36b2fc90e1a87dff8e93e3 Mon Sep 17 00:00:00 2001 From: Eamon Walsh Date: Thu, 27 Sep 2007 12:27:19 -0400 Subject: [PATCH 050/388] XI.h needs X.h for CARD32 on 64-bit systems. --- XI.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/XI.h b/XI.h index ae52292..0bfefcc 100644 --- a/XI.h +++ b/XI.h @@ -50,9 +50,10 @@ SOFTWARE. /* Definitions used by the server, library and client */ #ifndef _XI_H_ - #define _XI_H_ +#include /* CARD32 */ + #define sz_xGetExtensionVersionReq 8 #define sz_xGetExtensionVersionReply 32 #define sz_xListInputDevicesReq 4 From 6a0ffc2f461bd41a223732551e0ea1f05c293028 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 17 Oct 2007 12:38:38 +0930 Subject: [PATCH 051/388] xDeviceInfo: add "attached" field (replace previous padding). If use is set to IsXExtensionPointer/Keyboard/Devices, attached indicates the device ID of the master device it is attached to. If the device is floating, attached is set to IsFloating. --- XI.h | 1 + XIproto.h | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/XI.h b/XI.h index 921ea8d..36aa7d6 100644 --- a/XI.h +++ b/XI.h @@ -199,6 +199,7 @@ SOFTWARE. #define XKEYBOARD 1 #define UseXKeyboard 0xFF +#define IsFloating (1 << 7) #define IsXPointer 0 #define IsXKeyboard 1 diff --git a/XIproto.h b/XIproto.h index eb86def..3e233d3 100644 --- a/XIproto.h +++ b/XIproto.h @@ -254,8 +254,8 @@ typedef struct _xDeviceInfo { CARD32 type B32; CARD8 id; CARD8 num_classes; - CARD8 use; - CARD8 pad1; + CARD8 use; /* IsXPointer | IsXKeyboard | IsXExtension... */ + CARD8 attached; /* id of master dev (if IsXExtension..) */ } xDeviceInfo; typedef struct _xKeyInfo *xKeyInfoPtr; From 3c5555544e06f1be70e6981446e2a92dc1e2aecd Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 18 Oct 2007 10:39:40 +0930 Subject: [PATCH 052/388] Add XI version 2 defines. --- XI.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/XI.h b/XI.h index 36aa7d6..475b12d 100644 --- a/XI.h +++ b/XI.h @@ -159,6 +159,7 @@ SOFTWARE. #define XInput_Add_XSetDeviceValuators 3 #define XInput_Add_XChangeDeviceControl 4 #define XInput_Add_DevicePresenceNotify 5 +#define XInput_2 6 #define XI_Absent 0 #define XI_Present 1 @@ -178,8 +179,8 @@ SOFTWARE. #define XI_Add_DevicePresenceNotify_Major 1 #define XI_Add_DevicePresenceNotify_Minor 4 -#define XI_Add_MPX_Major 1 -#define XI_Add_MPX_Minor 5 +#define XI_2_Major 2 +#define XI_2_Minor 0 #define DEVICE_RESOLUTION 1 #define DEVICE_ABS_CALIB 2 From 52e2f24b3a21741d2fb0614642fd5b12b72c0d3d Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 18 Oct 2007 12:23:34 +0930 Subject: [PATCH 053/388] Create new XAttachInfo class for attachment info (slave devices). Thanks to XLibs design we can't just change XDeviceInfo without breaking the ABI. So here's a new class that isn't actually a class on the wire. --- XI.h | 1 + XInput.h | 17 +++++++++++++++++ 2 files changed, 18 insertions(+) diff --git a/XI.h b/XI.h index 475b12d..43b8745 100644 --- a/XI.h +++ b/XI.h @@ -255,6 +255,7 @@ SOFTWARE. #define ProximityClass 4 #define FocusClass 5 #define OtherClass 6 +#define AttachClass 7 #define KbdFeedbackClass 0 #define PtrFeedbackClass 1 diff --git a/XInput.h b/XInput.h index 8bf11b1..3d1da54 100644 --- a/XInput.h +++ b/XInput.h @@ -893,6 +893,23 @@ typedef struct _XValuatorInfo XAxisInfoPtr axes; } XValuatorInfo; +/** + * Fake class, added to each device when parsing XListInputDevices internally. + * Indicates the master device this device is attached to. If the device is a + * master device, the value of attached is to be ignored. + */ +typedef struct _XAttachInfo + { +#if defined(__cplusplus) || defined(c_plusplus) + XID c_class; +#else + XID class; +#endif + int length; + unsigned char attached; + } XAttachInfo; + +typedef struct _XAttachInfo *XAttachInfoPtr; /******************************************************************* * From 6037b37a5bf03f0b38db6a83fe1bc48551b8363c Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 19 Oct 2007 10:22:51 +0930 Subject: [PATCH 054/388] Add XChangeDeviceHierarchy and its components. --- XI.h | 13 ++++++++++++- XInput.h | 37 ++++++++++++++++++++++++++++++++++--- XIproto.h | 54 +++++++++++++++++++++++++++++++++++++++++++++++------- 3 files changed, 93 insertions(+), 11 deletions(-) diff --git a/XI.h b/XI.h index 43b8745..cf0b234 100644 --- a/XI.h +++ b/XI.h @@ -114,7 +114,7 @@ SOFTWARE. #define sz_xQueryDevicePointerReply 32 #define sz_xWarpDevicePointerReq 28 #define sz_xChangeDeviceCursorReq 16 -#define sz_xChangePointerKeyboardPairingReq 8 +#define sz_xChangeDeviceHierarchyReq 8 #define sz_xRegisterPairingClientReq 8 #define sz_xRegisterPairingClientReply 32 #define sz_xGrabAccessControlReq 8 @@ -294,12 +294,23 @@ SOFTWARE. #define WindowAccessClearAll \ WindowAccessClearPerm | WindowAccessClearDeny | WindowAccessClearRule +/* Device presence notify states */ #define DeviceAdded 0 #define DeviceRemoved 1 #define DeviceEnabled 2 #define DeviceDisabled 3 #define DeviceUnrecoverable 4 + +/* ChangeHierarchy constants */ +#define CH_CreateMasterDevice 1 +#define CH_RemoveMasterDevice 2 +#define CH_ChangeAttachment 3 + +#define AttachToMaster 1 +#define Floating 2 + +/* XI Errors */ #define XI_BadDevice 0 #define XI_BadEvent 1 #define XI_BadMode 2 diff --git a/XInput.h b/XInput.h index 3d1da54..2167c21 100644 --- a/XInput.h +++ b/XInput.h @@ -1018,6 +1018,37 @@ typedef struct { char buttons[32]; } XButtonState; + +/******************************************************************* + * + */ + +typedef struct { + int type; +} XAnyHierarchyChangeInfo; + +typedef struct { + int type; + char* name; + Bool sendCore; + Bool enable; +} XCreateMasterInfo; + +typedef struct { + int type; + XDevice* device; + int returnMode; /* AttachToMaster, Floating */ + XDevice* returnPointer; + XDevice* returnKeyboard; +} XRemoveMasterInfo; + +typedef struct { + int type; + XDevice* device; + int changeMode; /* AttachToMaster, Floating */ + XDevice* newMaster; +} XChangeAttachmentInfo; + /******************************************************************* * * Function definitions. @@ -1354,10 +1385,10 @@ extern Status XUndefineDeviceCursor( Window /* win */ ); -extern Status XChangePointerKeyboardPairing( +extern Status XChangeDeviceHierarchy( Display* /* display */, - XDevice* /* pointer */, - XDevice* /* keyboard*/ + int /* num_changes */, + XAnyHierarchyChangeInfo** /* changes*/ ); extern Bool XGetPairedPointer( diff --git a/XIproto.h b/XIproto.h index 3e233d3..fc7e5a2 100644 --- a/XIproto.h +++ b/XIproto.h @@ -168,7 +168,7 @@ struct tmask #define X_QueryDevicePointer 36 #define X_WarpDevicePointer 37 #define X_ChangeDeviceCursor 38 -#define X_ChangePointerKeyboardPairing 39 +#define X_ChangeDeviceHierarchy 39 #define X_RegisterPairingClient 40 #define X_GrabAccessControl 41 #define X_ChangeWindowAccess 42 @@ -1513,18 +1513,58 @@ typedef struct { /********************************************************** * - * ChangePointerKeyboardPairing. + * ChangeDeviceHierarchy * */ typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_ChangePointerKeyboardPairing */ + CARD8 ReqType; /* always X_ChangeDeviceHierarchy */ CARD16 length B16; - CARD8 pointer; /* ID of pointer devices */ - CARD8 keyboard; /* ID of keyboard device */ - CARD16 pad0; -} xChangePointerKeyboardPairingReq; + CARD8 num_changes; + CARD8 pad0; + CARD16 pad1 B16; +} xChangeDeviceHierarchyReq; + +typedef struct { + CARD16 type B16; + CARD16 length B16; /* in bytes */ +} xAnyHierarchyChangeInfo; + +/* Create a new master device. + * Name of new master follows struct (4-byte padded) + */ +typedef struct { + CARD16 type B16; /* Always CH_CreateMasterDevice */ + CARD16 length B16; /* 8 + (namelen + padding) */ + CARD16 namelen; + CARD8 sendCore; + CARD8 enable; +} xCreateMasterInfo; + +/* Delete a master device. Will automatically delete the master device paired + * with the given master device. + */ +typedef struct { + CARD16 type B16; /* Always CH_RemoveMasterDevice */ + CARD16 length B16; /* 8 */ + CARD8 deviceid; + CARD8 returnMode; /* AttachToMaster, Floating */ + CARD8 returnPointer; /* Pointer to attach slave ptr devices to */ + CARD8 returnKeyboard; /* keyboard to attach slave keybd devices to*/ +} xRemoveMasterInfo; + +/* Change a device's attachment. + * NewMaster has to be of same type (pointer->pointer, keyboard->keyboard); + */ +typedef struct { + CARD16 type B16; /* Always CH_ChangeAttachment */ + CARD16 length B16; /* 8 */ + CARD8 deviceid; + CARD8 changeMode; /* AttachToMaster, Floating */ + CARD8 newMaster; /* id of new master device */ + CARD8 pad0; +} xChangeAttachmentInfo; /********************************************************** * From 685a2dd32736956f5175afb9bc5773c829725fea Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 8 Nov 2007 17:26:35 +1030 Subject: [PATCH 055/388] Add DeviceHierarchyChangedEvent. Uses same event type as the now removed PointerKeyboardPairingChangedNotify. (removing the RandomStringEvent too, should have been gone a while ago) --- XI.h | 5 ++--- XInput.h | 28 ++++------------------------ XIproto.h | 49 ++++++++++++++++++++++++------------------------- 3 files changed, 30 insertions(+), 52 deletions(-) diff --git a/XI.h b/XI.h index cf0b234..79d4fcb 100644 --- a/XI.h +++ b/XI.h @@ -318,9 +318,8 @@ SOFTWARE. #define XI_BadClass 4 /* GE masks */ -#define XI_PointerKeyboardPairingChangedMask (1 << 0) -#define XI_RandomStringMask (1 << 1) -#define XI_RawDeviceEventMask (1 << 2) +#define XI_DeviceHierarchyChangedMask (1 << 0) +#define XI_RawDeviceEventMask (1 << 2) /* Make XEventClass be a CARD32 for 64 bit servers. Don't affect client diff --git a/XInput.h b/XInput.h index 2167c21..459ea78 100644 --- a/XInput.h +++ b/XInput.h @@ -496,10 +496,8 @@ typedef XDeviceCrossingEvent XDeviceLeaveWindowEvent; typedef XDeviceCrossingEvent XDeviceEnterWindowEvent; /* - * Notifies the client that a mouse/keyboard mapping has changed. A mouse may - * have several keyboards mapped to it, but a keyboard can only map to one - * mouse. - * Keyboard events will follow the focus of the given mouse. + * Notifies the client that the device hierarchy has been changed. The client + * is expected to re-query the server for the device hierarchy. */ typedef struct { int type; /* GenericEvent */ @@ -507,27 +505,9 @@ typedef struct { Bool send_event; /* true if this came from a SendEvent request */ Display *display; /* Display the event was read from */ int extension; /* XI extension offset */ - int evtype; /* PointerKeyboardPairingCHangedNotify */ + int evtype; /* XI_DeviceHierarchyChangedNotify */ Time time; - XID pointerid; /* pointer deviceid */ - XID keyboardid; /* keyboard deviceid */ -} XPointerKeyboardPairingChangedNotifyEvent; - - -/* - * XRandomStringEvent. - * FOR TESTING ONLY. DO NOT USE. - */ - -typedef struct { - int type; /* GenericEvent */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - int extension; /* XI extension offset */ - int evtype; /* RandomStringEvent */ - char* string; -} XRandomStringEvent; +} XDeviceHierarchyChangedEvent; /* * RawDeviceEvent. diff --git a/XIproto.h b/XIproto.h index fc7e5a2..efb7e83 100644 --- a/XIproto.h +++ b/XIproto.h @@ -119,8 +119,7 @@ struct tmask #define XI_DeviceLeaveNotify 17 /* GE events */ -#define XI_PointerKeyboardPairingChangedNotify 0 -#define XI_RandomStringEvent 1 +#define XI_DeviceHierarchyChangedNotify 0 #define XI_RawDeviceEvent 2 @@ -2079,29 +2078,6 @@ typedef struct } pairingChangedNotify; -/********************************************************** - * - * RandomStringEvent. - * GE event, != 32 bytes. - * - * FOR TESTING, DO NOT USE THIS. - */ - -typedef struct - { - BYTE type; /* always GenericEvent */ - BYTE extension; /* XI extension offset */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD16 evtype B16; /* XI_RandomStringEvent */ - CARD16 slen B16; - CARD32 pad1 B32; - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; - } randomStringEvent; - /********************************************************* * RawDeviceEvent. * @@ -2131,6 +2107,29 @@ typedef struct } rawDeviceEvent; +/********************************************************* + * DeviceHierarchyChangedEvent. + * + * Intended as a notification event only, the client is expected to query the + * server for input devices after receipt of this event. + */ + +typedef struct + { + BYTE type; /* always GenericEvent */ + BYTE extension; /* XI extension offset */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD16 evtype B16; /* XI_DeviceHierarchyChangedNotify */ + CARD16 pad0 B16; + CARD32 time B32; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + } deviceHierarchyChangedEvent; + + #undef Window #undef Time #undef KeyCode From 14e6e7bad06a560ec943654b94e05d4293709f2c Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 13 Nov 2007 11:29:06 +1030 Subject: [PATCH 056/388] Add DeviceClassesChangedEvent. --- XI.h | 1 + XInput.h | 27 +++++++++++++++++++++++---- XIproto.h | 29 +++++++++++++++++++++++++++++ 3 files changed, 53 insertions(+), 4 deletions(-) diff --git a/XI.h b/XI.h index 79d4fcb..1306bc7 100644 --- a/XI.h +++ b/XI.h @@ -319,6 +319,7 @@ SOFTWARE. /* GE masks */ #define XI_DeviceHierarchyChangedMask (1 << 0) +#define XI_DeviceClassesChangedMask (1 << 1) #define XI_RawDeviceEventMask (1 << 2) diff --git a/XInput.h b/XInput.h index 459ea78..ba3bf6a 100644 --- a/XInput.h +++ b/XInput.h @@ -186,6 +186,8 @@ extern "C" { #define DeviceBusy(dpy,error) _xidevicebusy(dpy, &error) +typedef struct _XAnyClassinfo *XAnyClassPtr; + /*************************************************************** * * DeviceKey events. These events are sent by input devices that @@ -510,7 +512,26 @@ typedef struct { } XDeviceHierarchyChangedEvent; /* - * RawDeviceEvent. + * Notifies the client that the classes have been changed. This happens when + * the slave device that sends through the master changes. + */ +typedef struct { + int type; /* GenericEvent */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + int extension; /* XI extension offset */ + int evtype; /* XI_DeviceHierarchyChangedNotify */ + Time time; + XID deviceid; /* id of the device that changed */ + XID slaveid; /* id of the slave device that caused the + change */ + int num_classes; + XAnyClassPtr inputclassinfo; /* same as in XDeviceInfo */ +} XDeviceClassesChangedEvent; + +/* + * RawDeviceEvent. * Data as received directly from the device. */ typedef struct { @@ -522,7 +543,7 @@ typedef struct { int evtype; /* XI_RawDeviceEvent */ int event_type; /* MotionNotify, ButtonPress or ButtonRelease*/ - int deviceid; + XID deviceid; int buttons; int num_valuators; int first_valuator; @@ -799,8 +820,6 @@ typedef struct { * */ -typedef struct _XAnyClassinfo *XAnyClassPtr; - typedef struct _XAnyClassinfo { #if defined(__cplusplus) || defined(c_plusplus) XID c_class; diff --git a/XIproto.h b/XIproto.h index efb7e83..ab676ef 100644 --- a/XIproto.h +++ b/XIproto.h @@ -120,6 +120,7 @@ struct tmask /* GE events */ #define XI_DeviceHierarchyChangedNotify 0 +#define XI_DeviceClassesChangedNotify 1 #define XI_RawDeviceEvent 2 @@ -2129,6 +2130,34 @@ typedef struct CARD32 pad5 B32; } deviceHierarchyChangedEvent; +/********************************************************* + * DeviceClassesChangedEvent + * + * Send whenever a master device changes classes (due to another slave device + * sending events). + * + * Event is followed by the same type of class list as used in the + * ListInputDevices request. + */ + +typedef struct + { + BYTE type; /* always GenericEvent */ + BYTE extension; /* XI extension offset */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD16 evtype B16; /* XI_DeviceClassesChangedNotify */ + CARD8 deviceid; /* id of master */ + CARD8 new_slave; /* id of new slave */ + CARD32 time B32; + CARD8 num_classes; + CARD8 pad0; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + } deviceClassesChangedEvent; + #undef Window #undef Time From 92f083437f3129bb67cd4599ad776b8b691f0b56 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 13 Nov 2007 17:22:21 +1030 Subject: [PATCH 057/388] Remove RegisterPairingClient, deprecated with the device hierarchy now. --- XInput.h | 8 -------- XIproto.h | 30 ------------------------------ 2 files changed, 38 deletions(-) diff --git a/XInput.h b/XInput.h index ba3bf6a..ac58175 100644 --- a/XInput.h +++ b/XInput.h @@ -1396,14 +1396,6 @@ extern Bool XGetPairedPointer( XID* /* deviceid */ ); -extern Bool XRegisterPairingClient( - Display* /* display */ -); - -extern Bool XUnregisterPairingClient( - Display* /* display */ -); - extern Bool XGrabAccessControl( Display* /* display */ ); diff --git a/XIproto.h b/XIproto.h index ab676ef..48a1b33 100644 --- a/XIproto.h +++ b/XIproto.h @@ -169,7 +169,6 @@ struct tmask #define X_WarpDevicePointer 37 #define X_ChangeDeviceCursor 38 #define X_ChangeDeviceHierarchy 39 -#define X_RegisterPairingClient 40 #define X_GrabAccessControl 41 #define X_ChangeWindowAccess 42 #define X_QueryWindowAccess 43 @@ -1566,35 +1565,6 @@ typedef struct { CARD8 pad0; } xChangeAttachmentInfo; -/********************************************************** - * - * RegisterPairingClient. - * - */ - -typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_RegisterPairingClient */ - CARD16 length B16; - CARD8 disable; /* True to disable registration */ - CARD8 pad0; - CARD16 pad1 B16; -} xRegisterPairingClientReq; - -typedef struct { - CARD8 repType; /* input extension major code */ - CARD8 RepType; /* always X_RegisterPairingClient */ - CARD16 sequenceNumber B16; - CARD32 length B32; /* 0 */ - CARD8 success; /* True on success, false otherwise */ - CARD8 pad0; - CARD16 pad1 B16; - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; - CARD32 pad6 B32; -} xRegisterPairingClientReply; /********************************************************** * From 9359e625787761e6b3df15f29bbf842c67a9516d Mon Sep 17 00:00:00 2001 From: James Cloos Date: Thu, 6 Dec 2007 16:39:02 -0500 Subject: [PATCH 058/388] Replace static ChangeLog with dist-hook to generate from git log --- ChangeLog | 4 ---- Makefile.am | 10 ++++++++++ 2 files changed, 10 insertions(+), 4 deletions(-) delete mode 100644 ChangeLog diff --git a/ChangeLog b/ChangeLog deleted file mode 100644 index c722b51..0000000 --- a/ChangeLog +++ /dev/null @@ -1,4 +0,0 @@ -2005-12-14 Kevin E. Martin - - * configure.ac: - Update package version number for final X11R7 release candidate. diff --git a/Makefile.am b/Makefile.am index e39ea0a..f8d4a32 100644 --- a/Makefile.am +++ b/Makefile.am @@ -8,3 +8,13 @@ pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = inputproto.pc EXTRA_DIST = autogen.sh inputproto.pc.in + +EXTRA_DIST += ChangeLog +MAINTAINERCLEANFILES = ChangeLog + +.PHONY: ChangeLog + +ChangeLog: + (GIT_DIR=$(top_srcdir)/.git git-log > .changelog.tmp && mv .changelog.tmp ChangeLog; rm -f .changelog.tmp) || (touch ChangeLog; echo 'git directory not found: installing possibly empty changelog.' >&2) + +dist-hook: ChangeLog From 640a97d321cdc5fd2f34265cba86da40463f8e48 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 18 Dec 2007 15:47:01 +1030 Subject: [PATCH 059/388] Move deviceid in XDeviceCrossingEvent up to follow window. This makes XDeviceCrossingEvents in line with the other events who have the same initial ordering of things. --- XInput.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XInput.h b/XInput.h index ac58175..b88efc5 100644 --- a/XInput.h +++ b/XInput.h @@ -477,9 +477,9 @@ typedef struct { Bool send_event; /* true if this came from a SendEvent request */ Display *display; /* Display the event was read from */ Window window; /* "event" window reported relative to */ + XID deviceid; Window root; /* root window that the event occurred on */ Window subwindow; /* child window */ - XID deviceid; Time time; /* milliseconds */ int x, y; /* pointer x, y coordinates in event window */ int x_root, y_root; /* coordinates relative to root */ From 096b20bf5492d248b5c8ff0c1c28e221d59db724 Mon Sep 17 00:00:00 2001 From: Jesse Barnes Date: Mon, 21 Jan 2008 15:28:49 -0800 Subject: [PATCH 060/388] Use Xmd.h instead of X.h to pull in CARD32 definition On 64 bit hosts, CARD32 may be undefined unless we use Xmd.h to define it for us. Apparently X.h is no longer sufficient. --- XI.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XI.h b/XI.h index 0bfefcc..fe4981a 100644 --- a/XI.h +++ b/XI.h @@ -52,7 +52,7 @@ SOFTWARE. #ifndef _XI_H_ #define _XI_H_ -#include /* CARD32 */ +#include /* CARD32 */ #define sz_xGetExtensionVersionReq 8 #define sz_xGetExtensionVersionReply 32 From bd20f0ebd5e71fd03b3140960c3960bc50bd4273 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 23 Jan 2008 15:47:56 +1030 Subject: [PATCH 061/388] Add a device id to XiSelectEvent. --- XI.h | 2 +- XInput.h | 1 + XIproto.h | 3 +++ 3 files changed, 5 insertions(+), 1 deletion(-) diff --git a/XI.h b/XI.h index 1306bc7..b3ed00a 100644 --- a/XI.h +++ b/XI.h @@ -127,7 +127,7 @@ SOFTWARE. #define sz_xGetClientPointerReply 32 #define sz_xGetPairedPointerReq 8 #define sz_xGetPairedPointerReply 32 -#define sz_xXiSelectEventReq 12 +#define sz_xXiSelectEventReq 16 #define sz_xFakeDeviceDataReq 12 #define sz_xExtendedGrabDeviceReq 28 #define sz_xExtendedGrabDeviceReply 32 diff --git a/XInput.h b/XInput.h index b88efc5..c995f35 100644 --- a/XInput.h +++ b/XInput.h @@ -1455,6 +1455,7 @@ extern Bool XGetClientPointer( extern Status XiSelectEvent( Display* /* dpy */, Window /* win */, + XDevice* /* dev */, Mask /* mask */ ); diff --git a/XIproto.h b/XIproto.h index 48a1b33..45d73eb 100644 --- a/XIproto.h +++ b/XIproto.h @@ -1734,6 +1734,9 @@ typedef struct { CARD16 length B16; Window window B32; /* window to be changed */ Mask mask B32; /* mask to be applied */ + CARD8 deviceid; + CARD8 pad0; + CARD16 pad1 B16; } xXiSelectEventReq; From be9e285258b8ea90628bbb5ae65bf74bdc59338b Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 12 Feb 2008 15:04:24 +1030 Subject: [PATCH 062/388] Remove "shared" field from QueryDevicePointer. If it's a slave device, it's shared, if it's a master device it has its own cursor. No need for this field. --- XInput.h | 3 +-- XIproto.h | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/XInput.h b/XInput.h index c995f35..1579a00 100644 --- a/XInput.h +++ b/XInput.h @@ -1354,8 +1354,7 @@ extern Bool XQueryDevicePointer( int* /* root_y */, int* /* win_x */, int* /* win_y */, - unsigned int* /* mask */, - Bool* /* shared */ + unsigned int* /* mask */ ); extern Bool XWarpDevicePointer( diff --git a/XIproto.h b/XIproto.h index 45d73eb..bb6205a 100644 --- a/XIproto.h +++ b/XIproto.h @@ -1465,7 +1465,7 @@ typedef struct { INT16 winY B16; CARD16 mask B16; BYTE sameScreen; - BYTE shared; /* sharing the core cursor? */ + BYTE pad; CARD32 pad0 B32; } xQueryDevicePointerReply; From 1d097c26264b657689d74f3f0a77cd1aa4f7e576 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 12 Feb 2008 19:17:51 +1030 Subject: [PATCH 063/388] Remove pairingChangedNotify event. I swear I already removed that before... Anyway, we don't need it anymore, since pairings can't be changed anyway. Hooray for the device hierarchy. --- XI.h | 1 - XIproto.h | 23 ----------------------- 2 files changed, 24 deletions(-) diff --git a/XI.h b/XI.h index b3ed00a..9e79120 100644 --- a/XI.h +++ b/XI.h @@ -276,7 +276,6 @@ SOFTWARE. #define _noExtensionEvent 9 #define _devicePresence 0 -#define _pairingChanged 1 #define _deviceEnter 0 #define _deviceLeave 1 diff --git a/XIproto.h b/XIproto.h index bb6205a..a84491e 100644 --- a/XIproto.h +++ b/XIproto.h @@ -2028,29 +2028,6 @@ typedef struct typedef deviceEnterNotify deviceLeaveNotify; -/********************************************************** - * - * pairingChangedNotify. - * - */ - -typedef struct - { - BYTE type; /* always GenericEvent */ - BYTE extension; /* Xi extension offset */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD16 evtype B16; - CARD32 time B32; - CARD8 pointer; - CARD8 keyboard; - CARD16 pad0; - CARD32 pad1; - CARD32 pad2; - CARD32 pad3; - CARD32 pad4; - } pairingChangedNotify; - /********************************************************* * RawDeviceEvent. From 6a91ee1bd1d4751d09f2e4aa832913bc66ae4602 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 12 Feb 2008 19:19:58 +1030 Subject: [PATCH 064/388] Remove RawDeviceEvent - for now anyway. Wasn't quite as thought-out as it should be. Throwing it out for now, to get the rest of MPX more stable. --- XI.h | 1 - XInput.h | 20 -------------------- XIproto.h | 30 ------------------------------ 3 files changed, 51 deletions(-) diff --git a/XI.h b/XI.h index 9e79120..7d9d90a 100644 --- a/XI.h +++ b/XI.h @@ -319,7 +319,6 @@ SOFTWARE. /* GE masks */ #define XI_DeviceHierarchyChangedMask (1 << 0) #define XI_DeviceClassesChangedMask (1 << 1) -#define XI_RawDeviceEventMask (1 << 2) /* Make XEventClass be a CARD32 for 64 bit servers. Don't affect client diff --git a/XInput.h b/XInput.h index 1579a00..f0326fc 100644 --- a/XInput.h +++ b/XInput.h @@ -530,26 +530,6 @@ typedef struct { XAnyClassPtr inputclassinfo; /* same as in XDeviceInfo */ } XDeviceClassesChangedEvent; -/* - * RawDeviceEvent. - * Data as received directly from the device. - */ -typedef struct { - int type; /* GenericEvent */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - int extension; /* XI extension offset */ - int evtype; /* XI_RawDeviceEvent */ - int event_type; /* MotionNotify, ButtonPress or - ButtonRelease*/ - XID deviceid; - int buttons; - int num_valuators; - int first_valuator; - int* valuators; -} XRawDeviceEvent; - /******************************************************************* * diff --git a/XIproto.h b/XIproto.h index a84491e..8ccd8c9 100644 --- a/XIproto.h +++ b/XIproto.h @@ -121,7 +121,6 @@ struct tmask /* GE events */ #define XI_DeviceHierarchyChangedNotify 0 #define XI_DeviceClassesChangedNotify 1 -#define XI_RawDeviceEvent 2 /********************************************************* @@ -2029,35 +2028,6 @@ typedef struct typedef deviceEnterNotify deviceLeaveNotify; -/********************************************************* - * RawDeviceEvent. - * - * GE event, may be larger than 32 bytes. If length is > 0, then the event is - * followed by (length * CARD32) fields denoting the values of valuator4 to - * valuator(num_valuators-1). - */ - -typedef struct - { - BYTE type; /* always GenericEvent */ - BYTE extension; /* XI extension offset */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD16 evtype B16; /* XI_RawDeviceEvent */ - CARD8 buttons; - CARD8 num_valuators; - CARD8 first_valuator; - CARD8 deviceid; - CARD8 event_type; /* one of MotionNotify, - ButtonPress, ButtonRelase */ - CARD8 pad0; - CARD32 valuator0 B32; - CARD32 valuator1 B32; - CARD32 valuator2 B32; - CARD32 valuator3 B32; - } rawDeviceEvent; - - /********************************************************* * DeviceHierarchyChangedEvent. * From 3c24865ad98557a5bc3e12c954eefaffff01bf36 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 14 Feb 2008 09:15:11 +1030 Subject: [PATCH 065/388] Remove GrabAccessControl and FakeDeviceData. Both aren't thought out enough to justify their inclusion in the first version of MPX. --- XI.h | 3 --- XInput.h | 17 ----------------- XIproto.h | 54 ------------------------------------------------------ 3 files changed, 74 deletions(-) diff --git a/XI.h b/XI.h index 7d9d90a..ef68094 100644 --- a/XI.h +++ b/XI.h @@ -117,8 +117,6 @@ SOFTWARE. #define sz_xChangeDeviceHierarchyReq 8 #define sz_xRegisterPairingClientReq 8 #define sz_xRegisterPairingClientReply 32 -#define sz_xGrabAccessControlReq 8 -#define sz_xGrabAccessControlReply 32 #define sz_xChangeWindowAccessReq 12 #define sz_xQueryWindowAccessReq 8 #define sz_xQueryWindowAccessReply 32 @@ -128,7 +126,6 @@ SOFTWARE. #define sz_xGetPairedPointerReq 8 #define sz_xGetPairedPointerReply 32 #define sz_xXiSelectEventReq 16 -#define sz_xFakeDeviceDataReq 12 #define sz_xExtendedGrabDeviceReq 28 #define sz_xExtendedGrabDeviceReply 32 diff --git a/XInput.h b/XInput.h index f0326fc..774c496 100644 --- a/XInput.h +++ b/XInput.h @@ -1375,14 +1375,6 @@ extern Bool XGetPairedPointer( XID* /* deviceid */ ); -extern Bool XGrabAccessControl( - Display* /* display */ -); - -extern Bool XUngrabAccessControl( - Display* /* display */ -); - extern Bool XWindowClearAccess( Display* /* display*/, Window /* win */, @@ -1438,15 +1430,6 @@ extern Status XiSelectEvent( Mask /* mask */ ); -extern Status XFakeDeviceData( - Display* /* dpy */, - XDevice* /* dev */, - int /* type */, - int /* buttons */, - int /* num_valuators */, - int /* first_valuator */, - ValuatorData* /* valuators */ -); extern Status XExtendedGrabDevice( Display* /* dpy */, diff --git a/XIproto.h b/XIproto.h index 8ccd8c9..24bbc09 100644 --- a/XIproto.h +++ b/XIproto.h @@ -168,14 +168,12 @@ struct tmask #define X_WarpDevicePointer 37 #define X_ChangeDeviceCursor 38 #define X_ChangeDeviceHierarchy 39 -#define X_GrabAccessControl 41 #define X_ChangeWindowAccess 42 #define X_QueryWindowAccess 43 #define X_SetClientPointer 44 #define X_GetClientPointer 45 #define X_GetPairedPointer 46 #define X_XiSelectEvent 47 -#define X_FakeDeviceData 48 #define X_ExtendedGrabDevice 49 /********************************************************* @@ -1565,36 +1563,6 @@ typedef struct { } xChangeAttachmentInfo; -/********************************************************** - * - * GrabAccessControl. - * - */ - -typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_GrabAccessControl */ - CARD16 length B16; - BOOL ungrab; /* true if request is ungrab request */ - CARD8 pad0, pad1, pad2; -} xGrabAccessControlReq; - -typedef struct { - CARD8 repType; /* input extension major code */ - CARD8 RepType; /* always X_GrabAccessControl */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD8 success; - CARD8 pad0, - pad1, - pad2; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; - CARD32 pad6 B32; - CARD32 pad7 B32; -} xGrabAccessControlReply; - /********************************************************** * * ChangeWindowAccess. @@ -1739,28 +1707,6 @@ typedef struct { } xXiSelectEventReq; -/********************************************************** - * - * FakeDeviceData. - * - * Followed by num_valuators * CARD32 fields that represent valuator data. - * - */ - -typedef struct { - CARD8 reqType; /* input extension major opcode */ - CARD8 ReqType; /* always X_XiSelectEvent */ - CARD16 length B16; - CARD8 type; - CARD8 buttons; - CARD8 num_valuators; - CARD8 first_valuator; - CARD8 deviceid; - CARD8 pad0; - CARD16 pad1; -} xFakeDeviceDataReq; - - /************************************************************ * * ExtendedGrabDevice. From d5245e8b85deec6f76bec2c9599da59516e50cca Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 14 Feb 2008 09:17:34 +1030 Subject: [PATCH 066/388] Whitespace fixing and sz_RegisterPairedClient removal. --- XI.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/XI.h b/XI.h index ef68094..1701828 100644 --- a/XI.h +++ b/XI.h @@ -110,14 +110,12 @@ SOFTWARE. #define sz_xGetDeviceControlReply 32 #define sz_xChangeDeviceControlReq 8 #define sz_xChangeDeviceControlReply 32 -#define sz_xQueryDevicePointerReq 12 +#define sz_xQueryDevicePointerReq 12 #define sz_xQueryDevicePointerReply 32 #define sz_xWarpDevicePointerReq 28 #define sz_xChangeDeviceCursorReq 16 #define sz_xChangeDeviceHierarchyReq 8 -#define sz_xRegisterPairingClientReq 8 -#define sz_xRegisterPairingClientReply 32 -#define sz_xChangeWindowAccessReq 12 +#define sz_xChangeWindowAccessReq 12 #define sz_xQueryWindowAccessReq 8 #define sz_xQueryWindowAccessReply 32 #define sz_xSetClientPointerReq 12 From 330cfbd0ca6e6d1557e08ab0c555fe87acc7be29 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 14 Feb 2008 16:33:03 +1030 Subject: [PATCH 067/388] Make XAnyDeviceHierarchyChangeInfo a union of the possible types. Kinda the same as the XEvent union. Some whitespace fixes too. --- XInput.h | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/XInput.h b/XInput.h index 774c496..8b28a94 100644 --- a/XInput.h +++ b/XInput.h @@ -999,13 +999,8 @@ typedef struct { /******************************************************************* - * + * */ - -typedef struct { - int type; -} XAnyHierarchyChangeInfo; - typedef struct { int type; char* name; @@ -1025,9 +1020,17 @@ typedef struct { int type; XDevice* device; int changeMode; /* AttachToMaster, Floating */ - XDevice* newMaster; + XDevice* newMaster; } XChangeAttachmentInfo; +typedef union { + int type; /* must be first element */ + XCreateMasterInfo create; + XRemoveMasterInfo remove; + XChangeAttachmentInfo change; +} XAnyHierarchyChangeInfo; + + /******************************************************************* * * Function definitions. From b512f47795bd125f6b04806d8a831f888febb67d Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 14 Feb 2008 18:25:24 +1030 Subject: [PATCH 068/388] Change XChangeDeviceHieararchy API. Single-pointer to changes is enough since we have a union now. Provide array first, then number of elements. This at least gives us consistency within the MPX-related stuff. The rest of Xlib can't seem to make its mind up about that. --- XInput.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/XInput.h b/XInput.h index 8b28a94..d48bc31 100644 --- a/XInput.h +++ b/XInput.h @@ -1368,8 +1368,8 @@ extern Status XUndefineDeviceCursor( extern Status XChangeDeviceHierarchy( Display* /* display */, - int /* num_changes */, - XAnyHierarchyChangeInfo** /* changes*/ + XAnyHierarchyChangeInfo* /* changes*/, + int /* num_changes */ ); extern Bool XGetPairedPointer( From 1f6d53f553e580757d4c7391838a44b659812ab0 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 18 Feb 2008 17:21:37 +1030 Subject: [PATCH 069/388] Add WindowAccessAllowAll constant. Not surprisingly the inverse of DenyAll. --- XI.h | 1 + 1 file changed, 1 insertion(+) diff --git a/XI.h b/XI.h index 1701828..3cf5180 100644 --- a/XI.h +++ b/XI.h @@ -279,6 +279,7 @@ SOFTWARE. #define WindowAccessNoRule 0 #define WindowAccessKeepRule 1 #define WindowAccessDenyAll 2 +#define WindowAccessAllowAll 3 /* Flags for ChangeWindowAccess. */ #define WindowAccessClearNone 0 From 1f37b09c99df0890fbf347f3767934cdd4e586c2 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 25 Feb 2008 16:28:05 +1030 Subject: [PATCH 070/388] Remove "ungrab" from ExtendedGrabDevice request, remove XUngrabExtDevice(). That's what UngrabDevice is for, it does the same anyway. --- XInput.h | 4 ---- XIproto.h | 4 ++-- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/XInput.h b/XInput.h index d48bc31..d6b8ad0 100644 --- a/XInput.h +++ b/XInput.h @@ -1448,10 +1448,6 @@ extern Status XExtendedGrabDevice( XGenericEventMask* /* generic_events */ ); -extern Status XExtendedUngrabDevice( - Display* /* dpy */, - XDevice* /* dev */); - _XFUNCPROTOEND #endif /* _XINPUT_H_ */ diff --git a/XIproto.h b/XIproto.h index 24bbc09..33566de 100644 --- a/XIproto.h +++ b/XIproto.h @@ -1723,10 +1723,10 @@ typedef struct { CARD16 length B16; CARD32 grab_window B32; Time time B32; - CARD8 ungrab; /* True if request is Ungrab request */ + CARD8 deviceid; CARD8 device_mode; /* GrabModeSync or GrabModeAsync */ BOOL owner_events; - CARD8 deviceid; + CARD8 pad0; Window confine_to B32; Cursor cursor B32; CARD16 event_count B16; From 66ba434bc5c5fd343e558b758a7e0d61dcebb1c4 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 25 Feb 2008 16:45:16 +1030 Subject: [PATCH 071/388] Remove GetPairedPointer, paired device can be found through ListInputDevices. --- XI.h | 2 -- XInput.h | 6 ------ XIproto.h | 31 ------------------------------- 3 files changed, 39 deletions(-) diff --git a/XI.h b/XI.h index 3cf5180..acf8d6c 100644 --- a/XI.h +++ b/XI.h @@ -121,8 +121,6 @@ SOFTWARE. #define sz_xSetClientPointerReq 12 #define sz_xGetClientPointerReq 8 #define sz_xGetClientPointerReply 32 -#define sz_xGetPairedPointerReq 8 -#define sz_xGetPairedPointerReply 32 #define sz_xXiSelectEventReq 16 #define sz_xExtendedGrabDeviceReq 28 #define sz_xExtendedGrabDeviceReply 32 diff --git a/XInput.h b/XInput.h index d6b8ad0..72e729d 100644 --- a/XInput.h +++ b/XInput.h @@ -1372,12 +1372,6 @@ extern Status XChangeDeviceHierarchy( int /* num_changes */ ); -extern Bool XGetPairedPointer( - Display* /* display */, - XDevice* /* keyboard */, - XID* /* deviceid */ -); - extern Bool XWindowClearAccess( Display* /* display*/, Window /* win */, diff --git a/XIproto.h b/XIproto.h index 33566de..9607b8b 100644 --- a/XIproto.h +++ b/XIproto.h @@ -172,7 +172,6 @@ struct tmask #define X_QueryWindowAccess 43 #define X_SetClientPointer 44 #define X_GetClientPointer 45 -#define X_GetPairedPointer 46 #define X_XiSelectEvent 47 #define X_ExtendedGrabDevice 49 @@ -1658,36 +1657,6 @@ typedef struct { CARD32 pad5 B32; } xGetClientPointerReply; -/********************************************************** - * - * GetPairedPointer. - * - */ - -typedef struct { - CARD8 reqType; - CARD8 ReqType; /* Always X_GetPairedPointer */ - CARD16 length B16; - CARD8 deviceid; - CARD8 pad0; - CARD16 pad1 B16; -} xGetPairedPointerReq; - -typedef struct { - CARD8 repType; /* input extension major opcode */ - CARD8 RepType; /* Always X_GetClientPointer */ - CARD16 sequenceNumber B16; - CARD32 length B32; - BOOL paired; /* keyboard is paired */ - CARD8 deviceid; - CARD16 pad0 B16; - CARD32 pad1 B32; - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; -} xGetPairedPointerReply; - /********************************************************** * From 52e366d845163cdc1ffa8955d36914cd6b5f21f9 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 25 Feb 2008 16:51:31 +1030 Subject: [PATCH 072/388] Squash opcode range for MPX XI requests. This removes the opcode holes that were left by the excessive request removal of the last weeks. --- XIproto.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/XIproto.h b/XIproto.h index 9607b8b..4fd6bf9 100644 --- a/XIproto.h +++ b/XIproto.h @@ -168,12 +168,12 @@ struct tmask #define X_WarpDevicePointer 37 #define X_ChangeDeviceCursor 38 #define X_ChangeDeviceHierarchy 39 -#define X_ChangeWindowAccess 42 -#define X_QueryWindowAccess 43 -#define X_SetClientPointer 44 -#define X_GetClientPointer 45 -#define X_XiSelectEvent 47 -#define X_ExtendedGrabDevice 49 +#define X_ChangeWindowAccess 40 +#define X_QueryWindowAccess 41 +#define X_SetClientPointer 42 +#define X_GetClientPointer 43 +#define X_XiSelectEvent 44 +#define X_ExtendedGrabDevice 45 /********************************************************* * From 83fe5a31cbba502482ee1f2e720aaed8f4fa86b8 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 4 Mar 2008 18:10:00 +1030 Subject: [PATCH 073/388] Add deviceid to QueryDevicePointer reply. Doesn't hurt, we have padding left over anyway. --- XIproto.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XIproto.h b/XIproto.h index 4fd6bf9..d4dfbca 100644 --- a/XIproto.h +++ b/XIproto.h @@ -1461,7 +1461,7 @@ typedef struct { INT16 winY B16; CARD16 mask B16; BYTE sameScreen; - BYTE pad; + CARD8 deviceid; CARD32 pad0 B32; } xQueryDevicePointerReply; From 3edc1bf23b07ea47d7e1e32047e15c67333c663e Mon Sep 17 00:00:00 2001 From: Adam Jackson Date: Wed, 5 Mar 2008 22:06:19 -0500 Subject: [PATCH 074/388] inputproto 1.4.3 --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index c010699..b07f4ea 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.4.2.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.4.3], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) XORG_RELEASE_VERSION From b5cbe2d93f6c0129b8f29da97778f6d1b15c38f9 Mon Sep 17 00:00:00 2001 From: Adam Jackson Date: Mon, 10 Mar 2008 09:08:21 -0400 Subject: [PATCH 075/388] C sucks: define XEventClass in terms of unsigned int, not CARD32. Apparently pulling in Xmd.h here breaks qt, since they both define an INT32 type (and incompatible ones even, since Xmd's is unsigned long on ILP32 because whoever wrote Xmd.h is a C novice). --- XI.h | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/XI.h b/XI.h index fe4981a..ec9bee2 100644 --- a/XI.h +++ b/XI.h @@ -1,5 +1,3 @@ -/* $Xorg: XI.h,v 1.4 2001/02/09 02:03:23 xorgcvs Exp $ */ - /************************************************************ Copyright 1989, 1998 The Open Group @@ -45,17 +43,12 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86: xc/include/extensions/XI.h,v 1.4 2001/01/17 17:53:16 dawes Exp $ */ /* Definitions used by the server, library and client */ #ifndef _XI_H_ #define _XI_H_ -#include /* CARD32 */ - -#define sz_xGetExtensionVersionReq 8 -#define sz_xGetExtensionVersionReply 32 #define sz_xListInputDevicesReq 4 #define sz_xListInputDevicesReply 32 #define sz_xOpenDeviceReq 8 @@ -263,12 +256,16 @@ SOFTWARE. #define XI_DeviceBusy 3 #define XI_BadClass 4 -/* Make XEventClass be a CARD32 for 64 bit servers. Don't affect client +/* + * Make XEventClass be a CARD32 for 64 bit servers. Don't affect client * definition of XEventClass since that would be a library interface change. * See the top of X.h for more _XSERVER64 magic. + * + * But, don't actually use the CARD32 type. We can't get it defined here + * without polluting the namespace. */ #ifdef _XSERVER64 -typedef CARD32 XEventClass; +typedef unsigned int XEventClass; #else typedef unsigned long XEventClass; #endif From 852568991b251e9366da167f1b746a0a1db6adf0 Mon Sep 17 00:00:00 2001 From: Adam Jackson Date: Mon, 10 Mar 2008 09:31:51 -0400 Subject: [PATCH 076/388] Typo fix. --- XI.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/XI.h b/XI.h index ec9bee2..3b11860 100644 --- a/XI.h +++ b/XI.h @@ -49,6 +49,8 @@ SOFTWARE. #ifndef _XI_H_ #define _XI_H_ +#define sz_xGetExtensionVersionReq 8 +#define sz_xGetExtensionVersionReply 32 #define sz_xListInputDevicesReq 4 #define sz_xListInputDevicesReply 32 #define sz_xOpenDeviceReq 8 From b762dad06c33a9bdcdedecb9a20d218aa38d05d6 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 25 Apr 2008 10:34:01 +0930 Subject: [PATCH 077/388] Add #define IREQUESTS 45. Specifies the number of requests in XI. --- XIproto.h | 1 + 1 file changed, 1 insertion(+) diff --git a/XIproto.h b/XIproto.h index d4dfbca..049a3d1 100644 --- a/XIproto.h +++ b/XIproto.h @@ -75,6 +75,7 @@ SOFTWARE. #define IEVENTS 18 #define IERRORS 5 +#define IREQUESTS 45 #define CLIENT_REQ 1 From 746f61a86d1fd37216508a3f913bf2a1d1287478 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 25 Apr 2008 18:09:32 +0930 Subject: [PATCH 078/388] Remove XInput.h. This file is now part of libXi. XInput.h only belongs to libXi and is should not be part of the protocol headers. For future revisions of this file refer to git://anongit.freedesktop.org/git/xorg/lib/libXi --- Makefile.am | 1 - XInput.h | 1447 --------------------------------------------------- 2 files changed, 1448 deletions(-) delete mode 100644 XInput.h diff --git a/Makefile.am b/Makefile.am index e39ea0a..7dc142c 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,7 +1,6 @@ inputdir = $(includedir)/X11/extensions input_HEADERS = \ XI.h \ - XInput.h \ XIproto.h pkgconfigdir = $(libdir)/pkgconfig diff --git a/XInput.h b/XInput.h deleted file mode 100644 index 72e729d..0000000 --- a/XInput.h +++ /dev/null @@ -1,1447 +0,0 @@ -/* $Xorg: XInput.h,v 1.4 2001/02/09 02:03:23 xorgcvs Exp $ */ - -/************************************************************ - -Copyright 1989, 1998 The Open Group - -Permission to use, copy, modify, distribute, and sell this software and its -documentation for any purpose is hereby granted without fee, provided that -the above copyright notice appear in all copies and that both that -copyright notice and this permission notice appear in supporting -documentation. - -The above copyright notice and this permission notice shall be included in -all copies or substantial portions of the Software. - -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR -IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, -FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE -OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN -AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN -CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. - -Except as contained in this notice, the name of The Open Group shall not be -used in advertising or otherwise to promote the sale, use or other dealings -in this Software without prior written authorization from The Open Group. - -Copyright 1989 by Hewlett-Packard Company, Palo Alto, California. - - All Rights Reserved - -Permission to use, copy, modify, and distribute this software and its -documentation for any purpose and without fee is hereby granted, -provided that the above copyright notice appear in all copies and that -both that copyright notice and this permission notice appear in -supporting documentation, and that the name of Hewlett-Packard not be -used in advertising or publicity pertaining to distribution of the -software without specific, written prior permission. - -HEWLETT-PACKARD DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING -ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL -HEWLETT-PACKARD BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR -ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, -WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, -ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -SOFTWARE. - -********************************************************/ -/* $XFree86: xc/include/extensions/XInput.h,v 1.3 2001/12/14 19:53:28 dawes Exp $ */ - -/* Definitions used by the library and client */ - -#ifndef _XINPUT_H_ -#define _XINPUT_H_ - -#include -#include -#include - -#define _deviceKeyPress 0 -#define _deviceKeyRelease 1 - -#define _deviceButtonPress 0 -#define _deviceButtonRelease 1 - -#define _deviceMotionNotify 0 - -#define _deviceFocusIn 0 -#define _deviceFocusOut 1 - -#define _proximityIn 0 -#define _proximityOut 1 - -#define _deviceStateNotify 0 -#define _deviceMappingNotify 1 -#define _changeDeviceNotify 2 -/* Space of 4 between is necessary! */ -#define _deviceEnterNotify 6 -#define _deviceLeaveNotify 7 - -#define FindTypeAndClass(d,type,_class,classid,offset) \ - { int _i; XInputClassInfo *_ip; \ - type = 0; _class = 0; \ - for (_i=0, _ip= ((XDevice *) d)->classes; \ - _i< ((XDevice *) d)->num_classes; \ - _i++, _ip++) \ - if (_ip->input_class == classid) \ - {type = _ip->event_type_base + offset; \ - _class = ((XDevice *) d)->device_id << 8 | type;}} - -#define DeviceKeyPress(d,type,_class) \ - FindTypeAndClass(d, type, _class, KeyClass, _deviceKeyPress) - -#define DeviceKeyRelease(d,type,_class) \ - FindTypeAndClass(d, type, _class, KeyClass, _deviceKeyRelease) - -#define DeviceButtonPress(d,type,_class) \ - FindTypeAndClass(d, type, _class, ButtonClass, _deviceButtonPress) - -#define DeviceButtonRelease(d,type,_class) \ - FindTypeAndClass(d, type, _class, ButtonClass, _deviceButtonRelease) - -#define DeviceMotionNotify(d,type,_class) \ - FindTypeAndClass(d, type, _class, ValuatorClass, _deviceMotionNotify) - -#define DeviceFocusIn(d,type,_class) \ - FindTypeAndClass(d, type, _class, FocusClass, _deviceFocusIn) - -#define DeviceFocusOut(d,type,_class) \ - FindTypeAndClass(d, type, _class, FocusClass, _deviceFocusOut) - -#define ProximityIn(d,type,_class) \ - FindTypeAndClass(d, type, _class, ProximityClass, _proximityIn) - -#define ProximityOut(d,type,_class) \ - FindTypeAndClass(d, type, _class, ProximityClass, _proximityOut) - -#define DeviceStateNotify(d,type,_class) \ - FindTypeAndClass(d, type, _class, OtherClass, _deviceStateNotify) - -#define DeviceMappingNotify(d,type,_class) \ - FindTypeAndClass(d, type, _class, OtherClass, _deviceMappingNotify) - -#define ChangeDeviceNotify(d,type,_class) \ - FindTypeAndClass(d, type, _class, OtherClass, _changeDeviceNotify) - -#define DevicePointerMotionHint(d,type,_class) \ - { _class = ((XDevice *) d)->device_id << 8 | _devicePointerMotionHint;} - -#define DeviceButton1Motion(d,type,_class) \ - { _class = ((XDevice *) d)->device_id << 8 | _deviceButton1Motion;} - -#define DeviceButton2Motion(d,type,_class) \ - { _class = ((XDevice *) d)->device_id << 8 | _deviceButton2Motion;} - -#define DeviceButton3Motion(d,type,_class) \ - { _class = ((XDevice *) d)->device_id << 8 | _deviceButton3Motion;} - -#define DeviceButton4Motion(d,type, _class) \ - { _class = ((XDevice *) d)->device_id << 8 | _deviceButton4Motion;} - -#define DeviceButton5Motion(d,type,_class) \ - { _class = ((XDevice *) d)->device_id << 8 | _deviceButton5Motion;} - -#define DeviceButtonMotion(d,type, _class) \ - { _class = ((XDevice *) d)->device_id << 8 | _deviceButtonMotion;} - -#define DeviceOwnerGrabButton(d,type,_class) \ - { _class = ((XDevice *) d)->device_id << 8 | _deviceOwnerGrabButton;} - -#define DeviceButtonPressGrab(d,type,_class) \ - { _class = ((XDevice *) d)->device_id << 8 | _deviceButtonGrab;} - -#define NoExtensionEvent(d,type,_class) \ - { _class = ((XDevice *) d)->device_id << 8 | _noExtensionEvent;} - - -/* We need the declaration for DevicePresence. */ -#if defined(__cplusplus) || defined(c_plusplus) -extern "C" { -#endif - extern int _XiGetDevicePresenceNotifyEvent(Display *); -#if defined(__cplusplus) || defined(c_plusplus) -} -#endif - -#define DevicePresence(dpy, type, _class) \ - { \ - type = _XiGetDevicePresenceNotifyEvent(dpy); \ - _class = (0x10000 | _devicePresence); \ - } - -#define DeviceEnterNotify(d, type, _class) \ - FindTypeAndClass(d, type, _class, OtherClass, _deviceEnterNotify); - -#define DeviceLeaveNotify(d, type, _class) \ - FindTypeAndClass(d, type, _class, OtherClass, _deviceLeaveNotify); - -/* Errors */ -#define BadDevice(dpy,error) _xibaddevice(dpy, &error) - -#define BadClass(dpy,error) _xibadclass(dpy, &error) - -#define BadEvent(dpy,error) _xibadevent(dpy, &error) - -#define BadMode(dpy,error) _xibadmode(dpy, &error) - -#define DeviceBusy(dpy,error) _xidevicebusy(dpy, &error) - -typedef struct _XAnyClassinfo *XAnyClassPtr; - -/*************************************************************** - * - * DeviceKey events. These events are sent by input devices that - * support input class Keys. - * The location of the X pointer is reported in the coordinate - * fields of the x,y and x_root,y_root fields. - * - */ - -typedef struct - { - int type; /* of event */ - unsigned long serial; /* # of last request processed */ - Bool send_event; /* true if from SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; /* "event" window reported relative to */ - XID deviceid; - Window root; /* root window event occured on */ - Window subwindow; /* child window */ - Time time; /* milliseconds */ - int x, y; /* x, y coordinates in event window */ - int x_root; /* coordinates relative to root */ - int y_root; /* coordinates relative to root */ - unsigned int state; /* key or button mask */ - unsigned int keycode; /* detail */ - Bool same_screen; /* same screen flag */ - unsigned int device_state; /* device key or button mask */ - unsigned char axes_count; - unsigned char first_axis; - int axis_data[6]; - } XDeviceKeyEvent; - -typedef XDeviceKeyEvent XDeviceKeyPressedEvent; -typedef XDeviceKeyEvent XDeviceKeyReleasedEvent; - -/******************************************************************* - * - * DeviceButton events. These events are sent by extension devices - * that support input class Buttons. - * - */ - -typedef struct { - int type; /* of event */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; /* "event" window reported relative to */ - XID deviceid; - Window root; /* root window that the event occured on */ - Window subwindow; /* child window */ - Time time; /* milliseconds */ - int x, y; /* x, y coordinates in event window */ - int x_root; /* coordinates relative to root */ - int y_root; /* coordinates relative to root */ - unsigned int state; /* key or button mask */ - unsigned int button; /* detail */ - Bool same_screen; /* same screen flag */ - unsigned int device_state; /* device key or button mask */ - unsigned char axes_count; - unsigned char first_axis; - int axis_data[6]; - } XDeviceButtonEvent; - -typedef XDeviceButtonEvent XDeviceButtonPressedEvent; -typedef XDeviceButtonEvent XDeviceButtonReleasedEvent; - -/******************************************************************* - * - * DeviceMotionNotify event. These events are sent by extension devices - * that support input class Valuators. - * - */ - -typedef struct - { - int type; /* of event */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; /* "event" window reported relative to */ - XID deviceid; - Window root; /* root window that the event occured on */ - Window subwindow; /* child window */ - Time time; /* milliseconds */ - int x, y; /* x, y coordinates in event window */ - int x_root; /* coordinates relative to root */ - int y_root; /* coordinates relative to root */ - unsigned int state; /* key or button mask */ - char is_hint; /* detail */ - Bool same_screen; /* same screen flag */ - unsigned int device_state; /* device key or button mask */ - unsigned char axes_count; - unsigned char first_axis; - int axis_data[6]; - } XDeviceMotionEvent; - -/******************************************************************* - * - * DeviceFocusChange events. These events are sent when the focus - * of an extension device that can be focused is changed. - * - */ - -typedef struct - { - int type; /* of event */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; /* "event" window reported relative to */ - XID deviceid; - int mode; /* NotifyNormal, NotifyGrab, NotifyUngrab */ - int detail; - /* - * NotifyAncestor, NotifyVirtual, NotifyInferior, - * NotifyNonLinear,NotifyNonLinearVirtual, NotifyPointer, - * NotifyPointerRoot, NotifyDetailNone - */ - Time time; - } XDeviceFocusChangeEvent; - -typedef XDeviceFocusChangeEvent XDeviceFocusInEvent; -typedef XDeviceFocusChangeEvent XDeviceFocusOutEvent; - -/******************************************************************* - * - * ProximityNotify events. These events are sent by those absolute - * positioning devices that are capable of generating proximity information. - * - */ - -typedef struct - { - int type; /* ProximityIn or ProximityOut */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; - XID deviceid; - Window root; - Window subwindow; - Time time; - int x, y; - int x_root, y_root; - unsigned int state; - Bool same_screen; - unsigned int device_state; /* device key or button mask */ - unsigned char axes_count; - unsigned char first_axis; - int axis_data[6]; - } XProximityNotifyEvent; -typedef XProximityNotifyEvent XProximityInEvent; -typedef XProximityNotifyEvent XProximityOutEvent; - -/******************************************************************* - * - * DeviceStateNotify events are generated on EnterWindow and FocusIn - * for those clients who have selected DeviceState. - * - */ - -typedef struct - { -#if defined(__cplusplus) || defined(c_plusplus) - unsigned char c_class; -#else - unsigned char class; -#endif - unsigned char length; - } XInputClass; - -typedef struct { - int type; - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; - XID deviceid; - Time time; - int num_classes; - char data[64]; -} XDeviceStateNotifyEvent; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - unsigned char c_class; -#else - unsigned char class; -#endif - unsigned char length; - unsigned char num_valuators; - unsigned char mode; - int valuators[6]; -} XValuatorStatus; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - unsigned char c_class; -#else - unsigned char class; -#endif - unsigned char length; - short num_keys; - char keys[32]; -} XKeyStatus; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - unsigned char c_class; -#else - unsigned char class; -#endif - unsigned char length; - short num_buttons; - char buttons[32]; -} XButtonStatus; - -/******************************************************************* - * - * DeviceMappingNotify event. This event is sent when the key mapping, - * modifier mapping, or button mapping of an extension device is changed. - * - */ - -typedef struct { - int type; - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; /* unused */ - XID deviceid; - Time time; - int request; /* one of MappingModifier, MappingKeyboard, - MappingPointer */ - int first_keycode;/* first keycode */ - int count; /* defines range of change w. first_keycode*/ -} XDeviceMappingEvent; - -/******************************************************************* - * - * ChangeDeviceNotify event. This event is sent when an - * XChangeKeyboard or XChangePointer request is made. - * - */ - -typedef struct { - int type; - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; /* unused */ - XID deviceid; - Time time; - int request; /* NewPointer or NewKeyboard */ -} XChangeDeviceNotifyEvent; - -/******************************************************************* - * - * DevicePresenceNotify event. This event is sent when the list of - * input devices changes, in which case devchange will be false, and - * no information about the change will be contained in the event; - * the client should use XListInputDevices() to learn what has changed. - * - * If devchange is true, an attribute that the server believes is - * important has changed on a device, and the client should use - * XGetDeviceControl to examine the device. If control is non-zero, - * then that control has changed meaningfully. - */ - -typedef struct { - int type; - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; /* unused */ - Time time; - Bool devchange; - XID deviceid; - XID control; -} XDevicePresenceNotifyEvent; - - -typedef struct { - int type; - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; /* "event" window reported relative to */ - XID deviceid; - Window root; /* root window that the event occurred on */ - Window subwindow; /* child window */ - Time time; /* milliseconds */ - int x, y; /* pointer x, y coordinates in event window */ - int x_root, y_root; /* coordinates relative to root */ - int mode; /* NotifyNormal, NotifyGrab, NotifyUngrab */ - int detail; - /* - * NotifyAncestor, NotifyVirtual, NotifyInferior, - * NotifyNonlinear,NotifyNonlinearVirtual - */ - Bool same_screen; /* same screen flag */ - Bool focus; /* boolean focus */ - unsigned int state; /* key or button mask */ -} XDeviceCrossingEvent; - -typedef XDeviceCrossingEvent XDeviceLeaveWindowEvent; -typedef XDeviceCrossingEvent XDeviceEnterWindowEvent; - -/* - * Notifies the client that the device hierarchy has been changed. The client - * is expected to re-query the server for the device hierarchy. - */ -typedef struct { - int type; /* GenericEvent */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - int extension; /* XI extension offset */ - int evtype; /* XI_DeviceHierarchyChangedNotify */ - Time time; -} XDeviceHierarchyChangedEvent; - -/* - * Notifies the client that the classes have been changed. This happens when - * the slave device that sends through the master changes. - */ -typedef struct { - int type; /* GenericEvent */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - int extension; /* XI extension offset */ - int evtype; /* XI_DeviceHierarchyChangedNotify */ - Time time; - XID deviceid; /* id of the device that changed */ - XID slaveid; /* id of the slave device that caused the - change */ - int num_classes; - XAnyClassPtr inputclassinfo; /* same as in XDeviceInfo */ -} XDeviceClassesChangedEvent; - - -/******************************************************************* - * - * Control structures for input devices that support input class - * Feedback. These are used by the XGetFeedbackControl and - * XChangeFeedbackControl functions. - * - */ - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - XID id; -} XFeedbackState; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - XID id; - int click; - int percent; - int pitch; - int duration; - int led_mask; - int global_auto_repeat; - char auto_repeats[32]; -} XKbdFeedbackState; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - XID id; - int accelNum; - int accelDenom; - int threshold; -} XPtrFeedbackState; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - XID id; - int resolution; - int minVal; - int maxVal; -} XIntegerFeedbackState; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - XID id; - int max_symbols; - int num_syms_supported; - KeySym *syms_supported; -} XStringFeedbackState; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - XID id; - int percent; - int pitch; - int duration; -} XBellFeedbackState; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - XID id; - int led_values; - int led_mask; -} XLedFeedbackState; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - XID id; -} XFeedbackControl; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - XID id; - int accelNum; - int accelDenom; - int threshold; -} XPtrFeedbackControl; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - XID id; - int click; - int percent; - int pitch; - int duration; - int led_mask; - int led_value; - int key; - int auto_repeat_mode; -} XKbdFeedbackControl; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - XID id; - int num_keysyms; - KeySym *syms_to_display; -} XStringFeedbackControl; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - XID id; - int int_to_display; -} XIntegerFeedbackControl; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - XID id; - int percent; - int pitch; - int duration; -} XBellFeedbackControl; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - XID id; - int led_mask; - int led_values; -} XLedFeedbackControl; - -/******************************************************************* - * - * Device control structures. - * - */ - -typedef struct { - XID control; - int length; -} XDeviceControl; - -typedef struct { - XID control; - int length; - int first_valuator; - int num_valuators; - int *resolutions; -} XDeviceResolutionControl; - -typedef struct { - XID control; - int length; - int num_valuators; - int *resolutions; - int *min_resolutions; - int *max_resolutions; -} XDeviceResolutionState; - -typedef struct { - XID control; - int length; - int min_x; - int max_x; - int min_y; - int max_y; - int flip_x; - int flip_y; - int rotation; - int button_threshold; -} XDeviceAbsCalibControl, XDeviceAbsCalibState; - -typedef struct { - XID control; - int length; - int offset_x; - int offset_y; - int width; - int height; - int screen; - XID following; -} XDeviceAbsAreaControl, XDeviceAbsAreaState; - -typedef struct { - XID control; - int length; - int status; -} XDeviceCoreControl; - -typedef struct { - XID control; - int length; - int status; - int iscore; -} XDeviceCoreState; - -typedef struct { - XID control; - int length; - int enable; -} XDeviceEnableControl, XDeviceEnableState; - -/******************************************************************* - * - * An array of XDeviceList structures is returned by the - * XListInputDevices function. Each entry contains information - * about one input device. Among that information is an array of - * pointers to structures that describe the characteristics of - * the input device. - * - */ - -typedef struct _XAnyClassinfo { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - } XAnyClassInfo; - -typedef struct _XDeviceInfo *XDeviceInfoPtr; - -typedef struct _XDeviceInfo - { - XID id; - Atom type; - char *name; - int num_classes; - int use; - XAnyClassPtr inputclassinfo; - } XDeviceInfo; - -typedef struct _XKeyInfo *XKeyInfoPtr; - -typedef struct _XKeyInfo - { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - unsigned short min_keycode; - unsigned short max_keycode; - unsigned short num_keys; - } XKeyInfo; - -typedef struct _XButtonInfo *XButtonInfoPtr; - -typedef struct _XButtonInfo { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - short num_buttons; - } XButtonInfo; - -typedef struct _XAxisInfo *XAxisInfoPtr; - -typedef struct _XAxisInfo { - int resolution; - int min_value; - int max_value; - } XAxisInfo; - -typedef struct _XValuatorInfo *XValuatorInfoPtr; - -typedef struct _XValuatorInfo - { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - unsigned char num_axes; - unsigned char mode; - unsigned long motion_buffer; - XAxisInfoPtr axes; - } XValuatorInfo; - -/** - * Fake class, added to each device when parsing XListInputDevices internally. - * Indicates the master device this device is attached to. If the device is a - * master device, the value of attached is to be ignored. - */ -typedef struct _XAttachInfo - { -#if defined(__cplusplus) || defined(c_plusplus) - XID c_class; -#else - XID class; -#endif - int length; - unsigned char attached; - } XAttachInfo; - -typedef struct _XAttachInfo *XAttachInfoPtr; - -/******************************************************************* - * - * An XDevice structure is returned by the XOpenDevice function. - * It contains an array of pointers to XInputClassInfo structures. - * Each contains information about a class of input supported by the - * device, including a pointer to an array of data for each type of event - * the device reports. - * - */ - - -typedef struct { - unsigned char input_class; - unsigned char event_type_base; -} XInputClassInfo; - -typedef struct { - XID device_id; - int num_classes; - XInputClassInfo *classes; -} XDevice; - - -/******************************************************************* - * - * The following structure is used to return information for the - * XGetSelectedExtensionEvents function. - * - */ - -typedef struct { - XEventClass event_type; - XID device; -} XEventList; - -/******************************************************************* - * - * The following structure is used to return motion history data from - * an input device that supports the input class Valuators. - * This information is returned by the XGetDeviceMotionEvents function. - * - */ - -typedef struct { - Time time; - int *data; -} XDeviceTimeCoord; - - -/******************************************************************* - * - * Device state structure. - * This is returned by the XQueryDeviceState request. - * - */ - -typedef struct { - XID device_id; - int num_classes; - XInputClass *data; -} XDeviceState; - -/******************************************************************* - * - * Note that the mode field is a bitfield that reports the Proximity - * status of the device as well as the mode. The mode field should - * be OR'd with the mask DeviceMode and compared with the values - * Absolute and Relative to determine the mode, and should be OR'd - * with the mask ProximityState and compared with the values InProximity - * and OutOfProximity to determine the proximity state. - * - */ - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - unsigned char c_class; -#else - unsigned char class; -#endif - unsigned char length; - unsigned char num_valuators; - unsigned char mode; - int *valuators; -} XValuatorState; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - unsigned char c_class; -#else - unsigned char class; -#endif - unsigned char length; - short num_keys; - char keys[32]; -} XKeyState; - -typedef struct { -#if defined(__cplusplus) || defined(c_plusplus) - unsigned char c_class; -#else - unsigned char class; -#endif - unsigned char length; - short num_buttons; - char buttons[32]; -} XButtonState; - - -/******************************************************************* - * - */ -typedef struct { - int type; - char* name; - Bool sendCore; - Bool enable; -} XCreateMasterInfo; - -typedef struct { - int type; - XDevice* device; - int returnMode; /* AttachToMaster, Floating */ - XDevice* returnPointer; - XDevice* returnKeyboard; -} XRemoveMasterInfo; - -typedef struct { - int type; - XDevice* device; - int changeMode; /* AttachToMaster, Floating */ - XDevice* newMaster; -} XChangeAttachmentInfo; - -typedef union { - int type; /* must be first element */ - XCreateMasterInfo create; - XRemoveMasterInfo remove; - XChangeAttachmentInfo change; -} XAnyHierarchyChangeInfo; - - -/******************************************************************* - * - * Function definitions. - * - */ - -_XFUNCPROTOBEGIN - -extern int XChangeKeyboardDevice( - Display* /* display */, - XDevice* /* device */ -); - -extern int XChangePointerDevice( - Display* /* display */, - XDevice* /* device */, - int /* xaxis */, - int /* yaxis */ -); - -extern int XGrabDevice( - Display* /* display */, - XDevice* /* device */, - Window /* grab_window */, - Bool /* ownerEvents */, - int /* event count */, - XEventClass* /* event_list */, - int /* this_device_mode */, - int /* other_devices_mode */, - Time /* time */ -); - -extern int XUngrabDevice( - Display* /* display */, - XDevice* /* device */, - Time /* time */ -); - -extern int XGrabDeviceKey( - Display* /* display */, - XDevice* /* device */, - unsigned int /* key */, - unsigned int /* modifiers */, - XDevice* /* modifier_device */, - Window /* grab_window */, - Bool /* owner_events */, - unsigned int /* event_count */, - XEventClass* /* event_list */, - int /* this_device_mode */, - int /* other_devices_mode */ -); - -extern int XUngrabDeviceKey( - Display* /* display */, - XDevice* /* device */, - unsigned int /* key */, - unsigned int /* modifiers */, - XDevice* /* modifier_dev */, - Window /* grab_window */ -); - -extern int XGrabDeviceButton( - Display* /* display */, - XDevice* /* device */, - unsigned int /* button */, - unsigned int /* modifiers */, - XDevice* /* modifier_device */, - Window /* grab_window */, - Bool /* owner_events */, - unsigned int /* event_count */, - XEventClass* /* event_list */, - int /* this_device_mode */, - int /* other_devices_mode */ -); - -extern int XUngrabDeviceButton( - Display* /* display */, - XDevice* /* device */, - unsigned int /* button */, - unsigned int /* modifiers */, - XDevice* /* modifier_dev */, - Window /* grab_window */ -); - -extern int XAllowDeviceEvents( - Display* /* display */, - XDevice* /* device */, - int /* event_mode */, - Time /* time */ -); - -extern int XGetDeviceFocus( - Display* /* display */, - XDevice* /* device */, - Window* /* focus */, - int* /* revert_to */, - Time* /* time */ -); - -extern int XSetDeviceFocus( - Display* /* display */, - XDevice* /* device */, - Window /* focus */, - int /* revert_to */, - Time /* time */ -); - -extern XFeedbackState *XGetFeedbackControl( - Display* /* display */, - XDevice* /* device */, - int* /* num_feedbacks */ -); - -extern void XFreeFeedbackList( - XFeedbackState* /* list */ -); - -extern int XChangeFeedbackControl( - Display* /* display */, - XDevice* /* device */, - unsigned long /* mask */, - XFeedbackControl* /* f */ -); - -extern int XDeviceBell( - Display* /* display */, - XDevice* /* device */, - XID /* feedbackclass */, - XID /* feedbackid */, - int /* percent */ -); - -extern KeySym *XGetDeviceKeyMapping( - Display* /* display */, - XDevice* /* device */, -#if NeedWidePrototypes - unsigned int /* first */, -#else - KeyCode /* first */, -#endif - int /* keycount */, - int* /* syms_per_code */ -); - -extern int XChangeDeviceKeyMapping( - Display* /* display */, - XDevice* /* device */, - int /* first */, - int /* syms_per_code */, - KeySym* /* keysyms */, - int /* count */ -); - -extern XModifierKeymap *XGetDeviceModifierMapping( - Display* /* display */, - XDevice* /* device */ -); - -extern int XSetDeviceModifierMapping( - Display* /* display */, - XDevice* /* device */, - XModifierKeymap* /* modmap */ -); - -extern int XSetDeviceButtonMapping( - Display* /* display */, - XDevice* /* device */, - unsigned char* /* map[] */, - int /* nmap */ -); - -extern int XGetDeviceButtonMapping( - Display* /* display */, - XDevice* /* device */, - unsigned char* /* map[] */, - unsigned int /* nmap */ -); - -extern XDeviceState *XQueryDeviceState( - Display* /* display */, - XDevice* /* device */ -); - -extern void XFreeDeviceState( - XDeviceState* /* list */ -); - -extern XExtensionVersion *XGetExtensionVersion( - Display* /* display */, - _Xconst char* /* name */ -); - -extern XDeviceInfo *XListInputDevices( - Display* /* display */, - int* /* ndevices */ -); - -extern void XFreeDeviceList( - XDeviceInfo* /* list */ -); - -extern XDevice *XOpenDevice( - Display* /* display */, - XID /* id */ -); - -extern int XCloseDevice( - Display* /* display */, - XDevice* /* device */ -); - -extern int XSetDeviceMode( - Display* /* display */, - XDevice* /* device */, - int /* mode */ -); - -extern int XSetDeviceValuators( - Display* /* display */, - XDevice* /* device */, - int* /* valuators */, - int /* first_valuator */, - int /* num_valuators */ -); - -extern XDeviceControl *XGetDeviceControl( - Display* /* display */, - XDevice* /* device */, - int /* control */ -); - -extern int XChangeDeviceControl( - Display* /* display */, - XDevice* /* device */, - int /* control */, - XDeviceControl* /* d */ -); - -extern int XSelectExtensionEvent( - Display* /* display */, - Window /* w */, - XEventClass* /* event_list */, - int /* count */ -); - -extern int XGetSelectedExtensionEvents( - Display* /* display */, - Window /* w */, - int* /* this_client_count */, - XEventClass** /* this_client_list */, - int* /* all_clients_count */, - XEventClass** /* all_clients_list */ -); - -extern int XChangeDeviceDontPropagateList( - Display* /* display */, - Window /* window */, - int /* count */, - XEventClass* /* events */, - int /* mode */ -); - -extern XEventClass *XGetDeviceDontPropagateList( - Display* /* display */, - Window /* window */, - int* /* count */ -); - -extern Status XSendExtensionEvent( - Display* /* display */, - XDevice* /* device */, - Window /* dest */, - Bool /* prop */, - int /* count */, - XEventClass* /* list */, - XEvent* /* event */ -); - -extern XDeviceTimeCoord *XGetDeviceMotionEvents( - Display* /* display */, - XDevice* /* device */, - Time /* start */, - Time /* stop */, - int* /* nEvents */, - int* /* mode */, - int* /* axis_count */ -); - -extern void XFreeDeviceMotionEvents( - XDeviceTimeCoord* /* events */ -); - -extern void XFreeDeviceControl( - XDeviceControl* /* control */ -); - -extern Bool XQueryDevicePointer( - Display* /* display */, - XDevice* /* device */, - Window /* win */, - Window* /* root */, - Window* /* child */, - int* /* root_x */, - int* /* root_y */, - int* /* win_x */, - int* /* win_y */, - unsigned int* /* mask */ -); - -extern Bool XWarpDevicePointer( - Display* /* display */, - XDevice* /* device */, - Window /* src_win */, - Window /* dst_win */, - int /* src_x */, - int /* src_y */, - unsigned int /* src_width */, - unsigned int /* src_height */, - int /* dst_x */, - int /* dst_y */ -); - -extern Status XDefineDeviceCursor( - Display* /* display */, - XDevice* /* device */, - Window /* win */, - Cursor /* cursor */ -); - -extern Status XUndefineDeviceCursor( - Display* /* display */, - XDevice* /* device */, - Window /* win */ -); - -extern Status XChangeDeviceHierarchy( - Display* /* display */, - XAnyHierarchyChangeInfo* /* changes*/, - int /* num_changes */ -); - -extern Bool XWindowClearAccess( - Display* /* display*/, - Window /* win */, - int /* what */ -); - -extern Bool XChangeAccessRule( - Display* /* display */, - Window /* win */, - int /* rule */ -); - -extern Status XPermitDevices( - Display* /* display */, - Window /* win */, - XID* /* deviceids */, - int /* ndevices */ -); - -extern Status XDenyDevices( - Display* /* display */, - Window /* win */, - XID* /* deviceids */, - int /* ndevices */ -); - -extern Status XQueryWindowAccess( - Display* /* dpy */, - Window /* win */, - int* /* rule */, - XID** /* permdevices */, - int* /* nperm */, - XID** /* denydevices */, - int* /* ndeny */ -); - -extern Status XSetClientPointer( - Display* /* dpy */, - Window /* win */, - XDevice* /* device */ -); - -extern Bool XGetClientPointer( - Display* /* dpy */, - Window /* win */, - XID* /* deviceid */ -); - -extern Status XiSelectEvent( - Display* /* dpy */, - Window /* win */, - XDevice* /* dev */, - Mask /* mask */ -); - - -extern Status XExtendedGrabDevice( - Display* /* dpy */, - XDevice* /* dev */, - Window /* grab_win */, - int /* device_mode */, - Bool /* ownerEvents */, - Window /* confineTo */, - Cursor /* cursor */, - int /* event_count */, - XEventClass* /* event_list */, - int /* generic_event_count */, - XGenericEventMask* /* generic_events */ -); - -_XFUNCPROTOEND - -#endif /* _XINPUT_H_ */ From f6e41306f76de966884d4b72c5fb5e5d6d534ce4 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Sat, 26 Apr 2008 10:03:19 +0930 Subject: [PATCH 079/388] Add major/minor version as supported by client to GetExtensionVersionReq. This sort-of breaks old clients. Behaviour to be assumed is that if nbytes is 0, major/minorVersion is set and specifies the version as supported by the client. If nbytes is non-zero, the request is trailed by the extension name (INAME) and major/minorVersion is undefined. This is the behaviour of pre-MPX clients. And then there may be clients who found that no other extension uses this request and supplying a name wasn't actually necessary since it was XI anyway. These clients will break. Tough luck. Read the man pages next time. --- XIproto.h | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/XIproto.h b/XIproto.h index 049a3d1..44050ca 100644 --- a/XIproto.h +++ b/XIproto.h @@ -182,6 +182,10 @@ struct tmask * * GetExtensionVersion. * + * For versioning support and to not break old clients, note that if nbytes is + * non-zero, majorVersion and minorVersion will be ignored. Otherwise, if + * nbytes is zero, majorVersion and minorVersion specify the version the + * client supports. */ typedef struct { @@ -189,7 +193,8 @@ typedef struct { CARD8 ReqType; /* always X_GetExtensionVersion */ CARD16 length B16; CARD16 nbytes B16; - CARD8 pad1, pad2; + CARD8 majorVersion; /* As supported by client if nbytes is 0 */ + CARD8 minorVersion; /* As supported by client if nbytes is 0 */ } xGetExtensionVersionReq; typedef struct { From 834c9ba8b4a1746a5d87d793f7c40bb882712656 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 12 May 2008 17:30:30 +0930 Subject: [PATCH 080/388] Remove a leftover typedef, the code that requires it has since been removed. Was part of the FakeDeviceData request, this request does not exist anymore. --- XI.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/XI.h b/XI.h index 48a3938..a81e8b8 100644 --- a/XI.h +++ b/XI.h @@ -322,10 +322,8 @@ SOFTWARE. */ #ifdef _XSERVER64 typedef unsigned int XEventClass; -typedef unsigned int ValuatorData; #else typedef unsigned long XEventClass; -typedef unsigned long ValuatorData; #endif /******************************************************************* From 9f1f3ef7a36fddacf30ecf867ddad90253103b6a Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 28 May 2008 17:13:49 +0930 Subject: [PATCH 081/388] Bump to 1.9.99.1. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index b07f4ea..4924215 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.4.3], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) XORG_RELEASE_VERSION From bbbe35b3513510afb524e02b8227826dbd5ea87e Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 7 Jul 2008 15:38:50 +0930 Subject: [PATCH 082/388] Add XI device property requests and replies. New requests: ListDeviceProperties ... list all props of a device QueryDeviceProperty ... query meta-information about a property ChangeDeviceProperty ... change the content of a property DeleteDeviceProperty ... delete a property GetDeviceProperty ... retrieve a property New event: DevicePropertyChangedNotify ... the given property on the device has changed --- XI.h | 13 ++++- XIproto.h | 151 ++++++++++++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 158 insertions(+), 6 deletions(-) diff --git a/XI.h b/XI.h index a81e8b8..4df6880 100644 --- a/XI.h +++ b/XI.h @@ -121,8 +121,17 @@ SOFTWARE. #define sz_xXiSelectEventReq 16 #define sz_xExtendedGrabDeviceReq 28 #define sz_xExtendedGrabDeviceReply 32 +#define sz_xListDevicePropertiesReq 8 +#define sz_xListDevicePropertiesReply 32 +#define sz_xQueryDevicePropertyReq 12 +#define sz_xQueryDevicePropertyReply 32 +#define sz_xConfigureDevicePropertyReq 12 +#define sz_xChangeDevicePropertyReq 20 +#define sz_xDeleteDevicePropertyReq 12 +#define sz_xGetDevicePropertyReq 24 +#define sz_xGetDevicePropertyReply 32 -#define INAME "XInputExtension" +#define INAME "XInputExtension" #define XI_KEYBOARD "KEYBOARD" #define XI_MOUSE "MOUSE" @@ -310,7 +319,7 @@ SOFTWARE. /* GE masks */ #define XI_DeviceHierarchyChangedMask (1 << 0) #define XI_DeviceClassesChangedMask (1 << 1) - +#define XI_DevicePropertyNotifyMask (1 << 2) /* * Make XEventClass be a CARD32 for 64 bit servers. Don't affect client diff --git a/XIproto.h b/XIproto.h index 44050ca..b3fcca3 100644 --- a/XIproto.h +++ b/XIproto.h @@ -73,11 +73,11 @@ SOFTWARE. #define numInputClasses 7 -#define IEVENTS 18 -#define IERRORS 5 -#define IREQUESTS 45 +#define IEVENTS 8 /* does NOT include generic events */ +#define IERRORS 5 +#define IREQUESTS 51 -#define CLIENT_REQ 1 +#define CLIENT_REQ 1 typedef struct _XExtEventInfo { @@ -122,6 +122,7 @@ struct tmask /* GE events */ #define XI_DeviceHierarchyChangedNotify 0 #define XI_DeviceClassesChangedNotify 1 +#define XI_DevicePropertyNotify 2 /********************************************************* @@ -175,6 +176,12 @@ struct tmask #define X_GetClientPointer 43 #define X_XiSelectEvent 44 #define X_ExtendedGrabDevice 45 +#define X_ListDeviceProperties 46 +#define X_QueryDeviceProperty 47 +#define X_ConfigureDeviceProperty 48 +#define X_ChangeDeviceProperty 49 +#define X_DeleteDeviceProperty 50 +#define X_GetDeviceProperty 51 /********************************************************* * @@ -1723,6 +1730,118 @@ typedef struct { } xExtendedGrabDeviceReply; +typedef struct { + CARD8 reqType; /* input extension major opcode */ + CARD8 ReqType; /* always X_ListDeviceProperties */ + CARD16 length B16; + CARD8 deviceid; + CARD8 pad0; + CARD16 pad1 B16; +} xListDevicePropertiesReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_ListDeviceProperties */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD16 nAtoms B16; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; +} xListDevicePropertiesReply; + +typedef struct { + CARD8 reqType; /* input extension major opcode */ + CARD8 ReqType; /* always X_QueryDeviceProperty */ + CARD16 length B16; + Atom property B32; + CARD8 deviceid; + CARD8 pad0; + CARD16 pad1 B16; +} xQueryDevicePropertyReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_QueryDeviceProperty */ + CARD16 sequenceNumber B16; + CARD32 length B32; + BOOL pending; + BOOL range; + BOOL immutable; + BOOL fromClient; /* TRUE if allocated by client */ + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; +} xQueryDevicePropertyReply; + +typedef struct { + CARD8 reqType; /* input extension major opcode */ + CARD8 ReqType; /* always X_ConfigureDeviceProperty */ + CARD16 length B16; + Atom property B32; + CARD8 deviceid; + BOOL pending; + BOOL range; + CARD8 pad; +} xConfigureDevicePropertyReq; + +typedef struct { + CARD8 reqType; /* input extension major opcode */ + CARD8 ReqType; /* always X_ChangeDeviceProperty */ + CARD16 length B16; + Atom property B32; + Atom type B32; + CARD8 deviceid; + CARD8 format; + CARD8 mode; + CARD8 pad; + CARD32 nUnits B32; +} xChangeDevicePropertyReq; + +typedef struct { + CARD8 reqType; /* input extension major opcode */ + CARD8 ReqType; /* always X_DeleteDeviceProperty */ + CARD16 length B16; + Atom property B32; + CARD8 deviceid; + CARD8 pad0; + CARD16 pad1 B16; +} xDeleteDevicePropertyReq; + +typedef struct { + CARD8 reqType; /* input extension major opcode */ + CARD8 ReqType; /* always X_ChangeDeviceProperty */ + CARD16 length B16; + Atom property B32; + Atom type B32; + CARD32 longOffset B32; + CARD32 longLength B32; + CARD8 deviceid; + BOOL delete; + BOOL pending; + CARD8 pad; +} xGetDevicePropertyReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetDeviceProperty */ + CARD16 sequenceNumber B16; + CARD32 length B32; + Atom propertyType B32; + CARD32 bytesAfter B32; + CARD32 nItems B32; + CARD8 format; + CARD8 deviceid; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad3 B32; +} xGetDevicePropertyReply; + /********************************************************** * * Input extension events. @@ -1999,6 +2118,30 @@ typedef struct CARD32 pad5 B32; } deviceClassesChangedEvent; +/********************************************************* + * DevicePropertyNotifyEvent + * + * Sent whenever a device's property changes. + * + */ + +typedef struct + { + BYTE type; /* always GenericEvent */ + BYTE extension; /* XI extension offset */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD16 evtype B16; /* XI_DevicePropertyNotify */ + CARD8 deviceid; /* id of device */ + CARD8 state; /* NewValue or Deleted */ + CARD32 time B32; + Atom atom B32; /* affected property */ + CARD32 pad2 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + } devicePropertyNotifyEvent; + + #undef Window #undef Time From 5f686651087ac9d1a15b4d8aa631f2d7f2096871 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 9 Jul 2008 18:28:26 +0930 Subject: [PATCH 083/388] Set IEVENTS back to 18, got set to 8 inadvertantly. --- XIproto.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XIproto.h b/XIproto.h index b3fcca3..0d8f50d 100644 --- a/XIproto.h +++ b/XIproto.h @@ -73,7 +73,7 @@ SOFTWARE. #define numInputClasses 7 -#define IEVENTS 8 /* does NOT include generic events */ +#define IEVENTS 18 /* does NOT include generic events */ #define IERRORS 5 #define IREQUESTS 51 From fe74239e93e6562ba6c268b50d6cfb36d2426bef Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Sun, 13 Jul 2008 20:49:51 +0930 Subject: [PATCH 084/388] Add #defines for XI_PROP_ENABLED, XI_PROP_MODE These two props are expected to be supported by the server. --- XI.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/XI.h b/XI.h index 4df6880..328e224 100644 --- a/XI.h +++ b/XI.h @@ -152,6 +152,11 @@ SOFTWARE. #define XI_CURSORKEYS "CURSORKEYS" #define XI_FOOTMOUSE "FOOTMOUSE" +/* Properties understood by the server */ +#define XI_PROP_ENABLED "Device Enabled" +#define XI_PROP_MODE "Device Mode" + + #define Dont_Check 0 #define XInput_Initial_Release 1 #define XInput_Add_XDeviceBell 2 From 0d300ce64c277f4f7c7fe5fd6dca1ed768880af1 Mon Sep 17 00:00:00 2001 From: Alan Hourihane Date: Mon, 21 Jul 2008 10:33:47 +0100 Subject: [PATCH 085/388] Bump to 1.9.99.2 for inputproto --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4924215..49f2646 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.2], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) XORG_RELEASE_VERSION From 0daf8328cfa90b038753fc409c5eb05ba3fac6d5 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 29 Jul 2008 08:58:53 +0930 Subject: [PATCH 086/388] Add DeviceControlChanged define. This value is used for the devchange field in the DevicePresenceNotify event when a device's control has been modified. --- XI.h | 3 ++- XIproto.h | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/XI.h b/XI.h index 328e224..efcfc78 100644 --- a/XI.h +++ b/XI.h @@ -303,7 +303,8 @@ SOFTWARE. #define DeviceRemoved 1 #define DeviceEnabled 2 #define DeviceDisabled 3 -#define DeviceUnrecoverable 4 +#define DeviceUnrecoverable 4 +#define DeviceControlChanged 5 /* ChangeHierarchy constants */ diff --git a/XIproto.h b/XIproto.h index 0d8f50d..9550639 100644 --- a/XIproto.h +++ b/XIproto.h @@ -2029,7 +2029,7 @@ typedef struct BYTE pad00; CARD16 sequenceNumber B16; Time time B32; - BYTE devchange; /* Device{Added|Removed|Enabled|Disabled} */ + BYTE devchange; /* Device{Added|Removed|Enabled|Disabled|ControlChanged} */ BYTE deviceid; CARD16 control B16; CARD32 pad02 B32; From 54465c743354dd138f4ccacc196198e36c2ecdba Mon Sep 17 00:00:00 2001 From: Alan Hourihane Date: Tue, 29 Jul 2008 14:15:04 +0100 Subject: [PATCH 087/388] bump to 1.99.9.3 --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 49f2646..1cef77c 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.2], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.3], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) XORG_RELEASE_VERSION From 7c9620d8232e5c05115746055a832363a528ac2d Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 13 Aug 2008 10:00:12 +0930 Subject: [PATCH 088/388] Back out Device Properties from XI 2, push into XI 1.5. --- XI.h | 29 +++-- XIproto.h | 357 ++++++++++++++++++++++++++++++------------------------ 2 files changed, 216 insertions(+), 170 deletions(-) diff --git a/XI.h b/XI.h index efcfc78..c737543 100644 --- a/XI.h +++ b/XI.h @@ -107,6 +107,15 @@ SOFTWARE. #define sz_xGetDeviceControlReply 32 #define sz_xChangeDeviceControlReq 8 #define sz_xChangeDeviceControlReply 32 +#define sz_xListDevicePropertiesReq 8 +#define sz_xListDevicePropertiesReply 32 +#define sz_xQueryDevicePropertyReq 12 +#define sz_xQueryDevicePropertyReply 32 +#define sz_xConfigureDevicePropertyReq 12 +#define sz_xChangeDevicePropertyReq 20 +#define sz_xDeleteDevicePropertyReq 12 +#define sz_xGetDevicePropertyReq 24 +#define sz_xGetDevicePropertyReply 32 #define sz_xQueryDevicePointerReq 12 #define sz_xQueryDevicePointerReply 32 #define sz_xWarpDevicePointerReq 28 @@ -121,15 +130,6 @@ SOFTWARE. #define sz_xXiSelectEventReq 16 #define sz_xExtendedGrabDeviceReq 28 #define sz_xExtendedGrabDeviceReply 32 -#define sz_xListDevicePropertiesReq 8 -#define sz_xListDevicePropertiesReply 32 -#define sz_xQueryDevicePropertyReq 12 -#define sz_xQueryDevicePropertyReply 32 -#define sz_xConfigureDevicePropertyReq 12 -#define sz_xChangeDevicePropertyReq 20 -#define sz_xDeleteDevicePropertyReq 12 -#define sz_xGetDevicePropertyReq 24 -#define sz_xGetDevicePropertyReply 32 #define INAME "XInputExtension" @@ -163,7 +163,8 @@ SOFTWARE. #define XInput_Add_XSetDeviceValuators 3 #define XInput_Add_XChangeDeviceControl 4 #define XInput_Add_DevicePresenceNotify 5 -#define XInput_2 6 +#define XInput_Add_DeviceProperties 6 +#define XInput_2 7 #define XI_Absent 0 #define XI_Present 1 @@ -183,8 +184,11 @@ SOFTWARE. #define XI_Add_DevicePresenceNotify_Major 1 #define XI_Add_DevicePresenceNotify_Minor 4 -#define XI_2_Major 2 -#define XI_2_Minor 0 +#define XI_Add_DeviceProperties_Major 1 +#define XI_Add_DeviceProperties_Minor 5 + +#define XI_2_Major 2 +#define XI_2_Minor 0 #define DEVICE_RESOLUTION 1 #define DEVICE_ABS_CALIB 2 @@ -325,7 +329,6 @@ SOFTWARE. /* GE masks */ #define XI_DeviceHierarchyChangedMask (1 << 0) #define XI_DeviceClassesChangedMask (1 << 1) -#define XI_DevicePropertyNotifyMask (1 << 2) /* * Make XEventClass be a CARD32 for 64 bit servers. Don't affect client diff --git a/XIproto.h b/XIproto.h index 9550639..38f79f2 100644 --- a/XIproto.h +++ b/XIproto.h @@ -73,7 +73,7 @@ SOFTWARE. #define numInputClasses 7 -#define IEVENTS 18 /* does NOT include generic events */ +#define IEVENTS 19 /* does NOT include generic events */ #define IERRORS 5 #define IREQUESTS 51 @@ -116,14 +116,13 @@ struct tmask #define XI_DeviceKeystateNotify 13 #define XI_DeviceButtonstateNotify 14 #define XI_DevicePresenceNotify 15 -#define XI_DeviceEnterNotify 16 -#define XI_DeviceLeaveNotify 17 +#define XI_DevicePropertyNotify 16 +#define XI_DeviceEnterNotify 17 +#define XI_DeviceLeaveNotify 18 /* GE events */ #define XI_DeviceHierarchyChangedNotify 0 #define XI_DeviceClassesChangedNotify 1 -#define XI_DevicePropertyNotify 2 - /********************************************************* * @@ -166,22 +165,24 @@ struct tmask #define X_SetDeviceValuators 33 #define X_GetDeviceControl 34 #define X_ChangeDeviceControl 35 -#define X_QueryDevicePointer 36 -#define X_WarpDevicePointer 37 -#define X_ChangeDeviceCursor 38 -#define X_ChangeDeviceHierarchy 39 -#define X_ChangeWindowAccess 40 -#define X_QueryWindowAccess 41 -#define X_SetClientPointer 42 -#define X_GetClientPointer 43 -#define X_XiSelectEvent 44 -#define X_ExtendedGrabDevice 45 -#define X_ListDeviceProperties 46 -#define X_QueryDeviceProperty 47 -#define X_ConfigureDeviceProperty 48 -#define X_ChangeDeviceProperty 49 -#define X_DeleteDeviceProperty 50 -#define X_GetDeviceProperty 51 +/* XI 1.5 */ +#define X_ListDeviceProperties 36 +#define X_QueryDeviceProperty 37 +#define X_ConfigureDeviceProperty 38 +#define X_ChangeDeviceProperty 39 +#define X_DeleteDeviceProperty 40 +#define X_GetDeviceProperty 41 +/* XI 2 */ +#define X_QueryDevicePointer 42 +#define X_WarpDevicePointer 43 +#define X_ChangeDeviceCursor 44 +#define X_ChangeDeviceHierarchy 45 +#define X_ChangeWindowAccess 46 +#define X_QueryWindowAccess 47 +#define X_SetClientPointer 48 +#define X_GetClientPointer 49 +#define X_XiSelectEvent 50 +#define X_ExtendedGrabDevice 51 /********************************************************* * @@ -1444,6 +1445,159 @@ typedef struct { CARD16 pad1 B16; } xDeviceEnableCtl; +/* XI 1.5 */ + +/********************************************************* + * + * ListDeviceProperties. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major opcode */ + CARD8 ReqType; /* always X_ListDeviceProperties */ + CARD16 length B16; + CARD8 deviceid; + CARD8 pad0; + CARD16 pad1 B16; +} xListDevicePropertiesReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_ListDeviceProperties */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD16 nAtoms B16; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; +} xListDevicePropertiesReply; + +/********************************************************* + * + * QueryDeviceProperty. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major opcode */ + CARD8 ReqType; /* always X_QueryDeviceProperty */ + CARD16 length B16; + Atom property B32; + CARD8 deviceid; + CARD8 pad0; + CARD16 pad1 B16; +} xQueryDevicePropertyReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_QueryDeviceProperty */ + CARD16 sequenceNumber B16; + CARD32 length B32; + BOOL pending; + BOOL range; + BOOL immutable; + BOOL fromClient; /* TRUE if allocated by client */ + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; +} xQueryDevicePropertyReply; + +/********************************************************* + * + * ConfigureDeviceProperty. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major opcode */ + CARD8 ReqType; /* always X_ConfigureDeviceProperty */ + CARD16 length B16; + Atom property B32; + CARD8 deviceid; + BOOL pending; + BOOL range; + CARD8 pad; +} xConfigureDevicePropertyReq; + +/********************************************************* + * + * ChangeDeviceProperty. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major opcode */ + CARD8 ReqType; /* always X_ChangeDeviceProperty */ + CARD16 length B16; + Atom property B32; + Atom type B32; + CARD8 deviceid; + CARD8 format; + CARD8 mode; + CARD8 pad; + CARD32 nUnits B32; +} xChangeDevicePropertyReq; + +/********************************************************* + * + * DeleteDeviceProperty. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major opcode */ + CARD8 ReqType; /* always X_DeleteDeviceProperty */ + CARD16 length B16; + Atom property B32; + CARD8 deviceid; + CARD8 pad0; + CARD16 pad1 B16; +} xDeleteDevicePropertyReq; + +/********************************************************* + * + * GetDeviceProperty. + * + */ + +typedef struct { + CARD8 reqType; /* input extension major opcode */ + CARD8 ReqType; /* always X_ChangeDeviceProperty */ + CARD16 length B16; + Atom property B32; + Atom type B32; + CARD32 longOffset B32; + CARD32 longLength B32; + CARD8 deviceid; + BOOL delete; + BOOL pending; + CARD8 pad; +} xGetDevicePropertyReq; + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetDeviceProperty */ + CARD16 sequenceNumber B16; + CARD32 length B32; + Atom propertyType B32; + CARD32 bytesAfter B32; + CARD32 nItems B32; + CARD8 format; + CARD8 deviceid; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad3 B32; +} xGetDevicePropertyReply; + +/* XI 2.0 */ + + /********************************************************** * * QueryDevicePointer. @@ -1730,118 +1884,6 @@ typedef struct { } xExtendedGrabDeviceReply; -typedef struct { - CARD8 reqType; /* input extension major opcode */ - CARD8 ReqType; /* always X_ListDeviceProperties */ - CARD16 length B16; - CARD8 deviceid; - CARD8 pad0; - CARD16 pad1 B16; -} xListDevicePropertiesReq; - -typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_ListDeviceProperties */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD16 nAtoms B16; - CARD16 pad1 B16; - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; - CARD32 pad6 B32; -} xListDevicePropertiesReply; - -typedef struct { - CARD8 reqType; /* input extension major opcode */ - CARD8 ReqType; /* always X_QueryDeviceProperty */ - CARD16 length B16; - Atom property B32; - CARD8 deviceid; - CARD8 pad0; - CARD16 pad1 B16; -} xQueryDevicePropertyReq; - -typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_QueryDeviceProperty */ - CARD16 sequenceNumber B16; - CARD32 length B32; - BOOL pending; - BOOL range; - BOOL immutable; - BOOL fromClient; /* TRUE if allocated by client */ - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; - CARD32 pad6 B32; -} xQueryDevicePropertyReply; - -typedef struct { - CARD8 reqType; /* input extension major opcode */ - CARD8 ReqType; /* always X_ConfigureDeviceProperty */ - CARD16 length B16; - Atom property B32; - CARD8 deviceid; - BOOL pending; - BOOL range; - CARD8 pad; -} xConfigureDevicePropertyReq; - -typedef struct { - CARD8 reqType; /* input extension major opcode */ - CARD8 ReqType; /* always X_ChangeDeviceProperty */ - CARD16 length B16; - Atom property B32; - Atom type B32; - CARD8 deviceid; - CARD8 format; - CARD8 mode; - CARD8 pad; - CARD32 nUnits B32; -} xChangeDevicePropertyReq; - -typedef struct { - CARD8 reqType; /* input extension major opcode */ - CARD8 ReqType; /* always X_DeleteDeviceProperty */ - CARD16 length B16; - Atom property B32; - CARD8 deviceid; - CARD8 pad0; - CARD16 pad1 B16; -} xDeleteDevicePropertyReq; - -typedef struct { - CARD8 reqType; /* input extension major opcode */ - CARD8 ReqType; /* always X_ChangeDeviceProperty */ - CARD16 length B16; - Atom property B32; - Atom type B32; - CARD32 longOffset B32; - CARD32 longLength B32; - CARD8 deviceid; - BOOL delete; - BOOL pending; - CARD8 pad; -} xGetDevicePropertyReq; - -typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_GetDeviceProperty */ - CARD16 sequenceNumber B16; - CARD32 length B32; - Atom propertyType B32; - CARD32 bytesAfter B32; - CARD32 nItems B32; - CARD8 format; - CARD8 deviceid; - CARD16 pad1 B16; - CARD32 pad2 B32; - CARD32 pad3 B32; -} xGetDevicePropertyReply; - /********************************************************** * * Input extension events. @@ -2068,6 +2110,31 @@ typedef struct typedef deviceEnterNotify deviceLeaveNotify; +/********************************************************* + * DevicePropertyNotifyEvent + * + * Sent whenever a device's property changes. + * + */ + +typedef struct + { + BYTE type; /* always GenericEvent */ + BYTE state; /* NewValue or Deleted */ + CARD16 sequenceNumber B16; + CARD32 time B32; + Atom atom B32; /* affected property */ + CARD8 deviceid; /* id of device */ + CARD8 pad0; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + } devicePropertyNotify; + + + /********************************************************* * DeviceHierarchyChangedEvent. * @@ -2118,30 +2185,6 @@ typedef struct CARD32 pad5 B32; } deviceClassesChangedEvent; -/********************************************************* - * DevicePropertyNotifyEvent - * - * Sent whenever a device's property changes. - * - */ - -typedef struct - { - BYTE type; /* always GenericEvent */ - BYTE extension; /* XI extension offset */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD16 evtype B16; /* XI_DevicePropertyNotify */ - CARD8 deviceid; /* id of device */ - CARD8 state; /* NewValue or Deleted */ - CARD32 time B32; - Atom atom B32; /* affected property */ - CARD32 pad2 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; - } devicePropertyNotifyEvent; - - #undef Window #undef Time From c2d47b04c55cf72aef6c13a9e2cc4b41abfca673 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 15 Aug 2008 14:21:24 +0930 Subject: [PATCH 089/388] Remove RCS tags, typo fix. --- XIproto.h | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/XIproto.h b/XIproto.h index 38f79f2..9ab7d5d 100644 --- a/XIproto.h +++ b/XIproto.h @@ -1,5 +1,3 @@ -/* $Xorg: XIproto.h,v 1.5 2001/02/09 02:03:24 xorgcvs Exp $ */ - /************************************************************ Copyright 1989, 1998 The Open Group @@ -45,7 +43,6 @@ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ********************************************************/ -/* $XFree86: xc/include/extensions/XIproto.h,v 1.4 2001/01/17 17:53:17 dawes Exp $ */ #ifndef _XIPROTO_H #define _XIPROTO_H @@ -1568,7 +1565,7 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major opcode */ - CARD8 ReqType; /* always X_ChangeDeviceProperty */ + CARD8 ReqType; /* always X_GetDeviceProperty */ CARD16 length B16; Atom property B32; Atom type B32; From fabe087cebb11c6a2600e57c6f7a52fda2efea29 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 15 Aug 2008 14:50:23 +0930 Subject: [PATCH 090/388] Protect against C++ includes. --- XIproto.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/XIproto.h b/XIproto.h index 9ab7d5d..0645f8b 100644 --- a/XIproto.h +++ b/XIproto.h @@ -1572,7 +1572,11 @@ typedef struct { CARD32 longOffset B32; CARD32 longLength B32; CARD8 deviceid; +#if defined(__cplusplus) || defined(c_plusplus) + BOOL c_delete; +#else BOOL delete; +#endif BOOL pending; CARD8 pad; } xGetDevicePropertyReq; From 3e7b663e7d5a40a115eba3cabfc173549ff89357 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 15 Aug 2008 15:01:16 +0930 Subject: [PATCH 091/388] inputproto 1.9.99.4 Backported device properties. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 1cef77c..3f7d4b3 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.3], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.4], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) XORG_RELEASE_VERSION From 20a0c8433ee50ecef1dfdb218674c7729bbacb99 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 18 Sep 2008 15:00:01 +0930 Subject: [PATCH 092/388] Don't include Xmd.h. --- XI.h | 1 - 1 file changed, 1 deletion(-) diff --git a/XI.h b/XI.h index c737543..c53a38e 100644 --- a/XI.h +++ b/XI.h @@ -48,7 +48,6 @@ SOFTWARE. #ifndef _XI_H_ #define _XI_H_ -#include #define sz_xGetExtensionVersionReq 8 #define sz_xGetExtensionVersionReply 32 From c9454a8e84b2dce54bb346ff1aafb32e3c0ac5b9 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 18 Sep 2008 16:28:09 +0930 Subject: [PATCH 093/388] Add XI_JOYSTICK type. --- XI.h | 1 + 1 file changed, 1 insertion(+) diff --git a/XI.h b/XI.h index c53a38e..f91f3c3 100644 --- a/XI.h +++ b/XI.h @@ -150,6 +150,7 @@ SOFTWARE. #define XI_EYETRACKER "EYETRACKER" #define XI_CURSORKEYS "CURSORKEYS" #define XI_FOOTMOUSE "FOOTMOUSE" +#define XI_JOYSTICK "JOYSTICK" /* Properties understood by the server */ #define XI_PROP_ENABLED "Device Enabled" From 18ef04f8a2026cca5d2d2b796ec2ea1c949bad36 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 18 Sep 2008 15:00:54 +0930 Subject: [PATCH 094/388] Remove Configure/QueryDeviceProperty. --- XI.h | 3 -- XIproto.h | 82 ++++++++++--------------------------------------------- 2 files changed, 15 insertions(+), 70 deletions(-) diff --git a/XI.h b/XI.h index f91f3c3..f722bbf 100644 --- a/XI.h +++ b/XI.h @@ -108,9 +108,6 @@ SOFTWARE. #define sz_xChangeDeviceControlReply 32 #define sz_xListDevicePropertiesReq 8 #define sz_xListDevicePropertiesReply 32 -#define sz_xQueryDevicePropertyReq 12 -#define sz_xQueryDevicePropertyReply 32 -#define sz_xConfigureDevicePropertyReq 12 #define sz_xChangeDevicePropertyReq 20 #define sz_xDeleteDevicePropertyReq 12 #define sz_xGetDevicePropertyReq 24 diff --git a/XIproto.h b/XIproto.h index 0645f8b..d2c2e46 100644 --- a/XIproto.h +++ b/XIproto.h @@ -72,7 +72,7 @@ SOFTWARE. #define IEVENTS 19 /* does NOT include generic events */ #define IERRORS 5 -#define IREQUESTS 51 +#define IREQUESTS 49 #define CLIENT_REQ 1 @@ -164,22 +164,20 @@ struct tmask #define X_ChangeDeviceControl 35 /* XI 1.5 */ #define X_ListDeviceProperties 36 -#define X_QueryDeviceProperty 37 -#define X_ConfigureDeviceProperty 38 -#define X_ChangeDeviceProperty 39 -#define X_DeleteDeviceProperty 40 -#define X_GetDeviceProperty 41 +#define X_ChangeDeviceProperty 37 +#define X_DeleteDeviceProperty 38 +#define X_GetDeviceProperty 39 /* XI 2 */ -#define X_QueryDevicePointer 42 -#define X_WarpDevicePointer 43 -#define X_ChangeDeviceCursor 44 -#define X_ChangeDeviceHierarchy 45 -#define X_ChangeWindowAccess 46 -#define X_QueryWindowAccess 47 -#define X_SetClientPointer 48 -#define X_GetClientPointer 49 -#define X_XiSelectEvent 50 -#define X_ExtendedGrabDevice 51 +#define X_QueryDevicePointer 40 +#define X_WarpDevicePointer 41 +#define X_ChangeDeviceCursor 42 +#define X_ChangeDeviceHierarchy 43 +#define X_ChangeWindowAccess 44 +#define X_QueryWindowAccess 45 +#define X_SetClientPointer 46 +#define X_GetClientPointer 47 +#define X_XiSelectEvent 48 +#define X_ExtendedGrabDevice 49 /********************************************************* * @@ -1473,55 +1471,6 @@ typedef struct { CARD32 pad6 B32; } xListDevicePropertiesReply; -/********************************************************* - * - * QueryDeviceProperty. - * - */ - -typedef struct { - CARD8 reqType; /* input extension major opcode */ - CARD8 ReqType; /* always X_QueryDeviceProperty */ - CARD16 length B16; - Atom property B32; - CARD8 deviceid; - CARD8 pad0; - CARD16 pad1 B16; -} xQueryDevicePropertyReq; - -typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_QueryDeviceProperty */ - CARD16 sequenceNumber B16; - CARD32 length B32; - BOOL pending; - BOOL range; - BOOL immutable; - BOOL fromClient; /* TRUE if allocated by client */ - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; - CARD32 pad6 B32; -} xQueryDevicePropertyReply; - -/********************************************************* - * - * ConfigureDeviceProperty. - * - */ - -typedef struct { - CARD8 reqType; /* input extension major opcode */ - CARD8 ReqType; /* always X_ConfigureDeviceProperty */ - CARD16 length B16; - Atom property B32; - CARD8 deviceid; - BOOL pending; - BOOL range; - CARD8 pad; -} xConfigureDevicePropertyReq; - /********************************************************* * * ChangeDeviceProperty. @@ -1577,8 +1526,7 @@ typedef struct { #else BOOL delete; #endif - BOOL pending; - CARD8 pad; + CARD16 pad; } xGetDevicePropertyReq; typedef struct { From 93c1ea035b46614fd907e33303c6a876d32e2c78 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 26 Sep 2008 09:37:48 +0930 Subject: [PATCH 095/388] Remove default properties (XI_PROP_MODE, XI_PROP_ENABLED) These should be defined by the server, not the protocol. --- XI.h | 5 ----- 1 file changed, 5 deletions(-) diff --git a/XI.h b/XI.h index f722bbf..63acb3e 100644 --- a/XI.h +++ b/XI.h @@ -149,11 +149,6 @@ SOFTWARE. #define XI_FOOTMOUSE "FOOTMOUSE" #define XI_JOYSTICK "JOYSTICK" -/* Properties understood by the server */ -#define XI_PROP_ENABLED "Device Enabled" -#define XI_PROP_MODE "Device Mode" - - #define Dont_Check 0 #define XInput_Initial_Release 1 #define XInput_Add_XDeviceBell 2 From 2166b77ea60bd9cd87f1311a2e7d461db071cb07 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 26 Sep 2008 10:11:04 +0930 Subject: [PATCH 096/388] Bump to 1.9.99.5. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 3f7d4b3..5e0b281 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.4], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.5], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) XORG_RELEASE_VERSION From c919917e375aefaf473570c1b25b3c22231e858d Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 15 Oct 2008 10:34:21 +1030 Subject: [PATCH 097/388] Make sure Atoms are defined as CARD32. --- XIproto.h | 1 + 1 file changed, 1 insertion(+) diff --git a/XIproto.h b/XIproto.h index d2c2e46..4d8fb19 100644 --- a/XIproto.h +++ b/XIproto.h @@ -55,6 +55,7 @@ SOFTWARE. #define Time CARD32 #define KeyCode CARD8 #define Mask CARD32 +#define Atom CARD32 /********************************************************* * From 36c8a6f3faf56a8f8ca31455812c9132b379b1b3 Mon Sep 17 00:00:00 2001 From: Julien Cristau Date: Wed, 15 Oct 2008 10:33:51 +0200 Subject: [PATCH 098/388] Undef Atom after we're done so we don't pollute users of XIproto.h --- XIproto.h | 1 + 1 file changed, 1 insertion(+) diff --git a/XIproto.h b/XIproto.h index 4d8fb19..f167f1c 100644 --- a/XIproto.h +++ b/XIproto.h @@ -2140,5 +2140,6 @@ typedef struct #undef Time #undef KeyCode #undef Mask +#undef Atom #endif From 90a86701e3b9feafa05f44649a8314f06285fab5 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 8 Oct 2008 21:39:20 +1030 Subject: [PATCH 099/388] Remove window access protocol requests. This is a bad idea. It didn't provide security and you can get the same functionality as you did with normal event registration. --- XI.h | 17 ---------------- XIproto.h | 60 ++++--------------------------------------------------- 2 files changed, 4 insertions(+), 73 deletions(-) diff --git a/XI.h b/XI.h index 63acb3e..a95945b 100644 --- a/XI.h +++ b/XI.h @@ -117,9 +117,6 @@ SOFTWARE. #define sz_xWarpDevicePointerReq 28 #define sz_xChangeDeviceCursorReq 16 #define sz_xChangeDeviceHierarchyReq 8 -#define sz_xChangeWindowAccessReq 12 -#define sz_xQueryWindowAccessReq 8 -#define sz_xQueryWindowAccessReply 32 #define sz_xSetClientPointerReq 12 #define sz_xGetClientPointerReq 8 #define sz_xGetClientPointerReply 32 @@ -280,20 +277,6 @@ SOFTWARE. #define _deviceEnter 0 #define _deviceLeave 1 -/* Flags for ChangeWindowAccess defaultRule. Pick one. */ -#define WindowAccessNoRule 0 -#define WindowAccessKeepRule 1 -#define WindowAccessDenyAll 2 -#define WindowAccessAllowAll 3 - -/* Flags for ChangeWindowAccess. */ -#define WindowAccessClearNone 0 -#define WindowAccessClearPerm (1) -#define WindowAccessClearDeny (1 << 1) -#define WindowAccessClearRule (1 << 2) -#define WindowAccessClearAll \ - WindowAccessClearPerm | WindowAccessClearDeny | WindowAccessClearRule - /* Device presence notify states */ #define DeviceAdded 0 #define DeviceRemoved 1 diff --git a/XIproto.h b/XIproto.h index f167f1c..72684dc 100644 --- a/XIproto.h +++ b/XIproto.h @@ -173,12 +173,10 @@ struct tmask #define X_WarpDevicePointer 41 #define X_ChangeDeviceCursor 42 #define X_ChangeDeviceHierarchy 43 -#define X_ChangeWindowAccess 44 -#define X_QueryWindowAccess 45 -#define X_SetClientPointer 46 -#define X_GetClientPointer 47 -#define X_XiSelectEvent 48 -#define X_ExtendedGrabDevice 49 +#define X_SetClientPointer 44 +#define X_GetClientPointer 45 +#define X_XiSelectEvent 46 +#define X_ExtendedGrabDevice 47 /********************************************************* * @@ -1679,56 +1677,6 @@ typedef struct { } xChangeAttachmentInfo; -/********************************************************** - * - * ChangeWindowAccess. - * - */ - -typedef struct { - CARD8 reqType; /* input extension major opcode */ - CARD8 ReqType; /* Always X_ChangeWindowAccess */ - CARD16 length B16; - Window win B32; - CARD8 npermit; /* number of devices for permit rule */ - CARD8 ndeny; /* number of devices for deny rule */ - CARD8 defaultRule; /* default rule */ - CARD8 clear; /* WindowAccessClearPerm, - WindowAccessClearDeny, - WindowAccessClearRule, - WindowAccessClearAll */ -} xChangeWindowAccessReq; - -/********************************************************** - * - * QueryWindowAccess - * - */ - -typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_QueryWindowAccess */ - CARD16 length B16; - Window win B32; -} xQueryWindowAccessReq; - -typedef struct { - CARD8 repType; /* input extension major opcode */ - CARD8 RepType; /* Always X_QueryWindowAccess */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD8 defaultRule; /* default rule setting */ - CARD8 npermit; /* number of devices in permit */ - CARD8 ndeny; /* number of devices in deny */ - CARD8 pad0; - CARD32 pad1 B32; - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; -} xQueryWindowAccessReply; - - /********************************************************** * From f8064629496c6061bedb7a99b788fb9d3a170f11 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 31 Oct 2008 17:53:39 +1030 Subject: [PATCH 100/388] PropertyNotify, move deviceid back to last byte. This way, it can be type-cast to deviceKeyButtonPointer to extract the deviceid, which is (aside from time) the only thing it has in common with those anyway. --- XIproto.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/XIproto.h b/XIproto.h index 72684dc..7238fa6 100644 --- a/XIproto.h +++ b/XIproto.h @@ -2017,18 +2017,18 @@ typedef deviceEnterNotify deviceLeaveNotify; typedef struct { - BYTE type; /* always GenericEvent */ + BYTE type; BYTE state; /* NewValue or Deleted */ CARD16 sequenceNumber B16; CARD32 time B32; Atom atom B32; /* affected property */ - CARD8 deviceid; /* id of device */ - CARD8 pad0; - CARD16 pad1 B16; + CARD32 pad0 B32; + CARD32 pad1 B32; CARD32 pad2 B32; CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; + CARD16 pad5 B16; + CARD8 pad4; + CARD8 deviceid; /* id of device */ } devicePropertyNotify; From 7203036522ba9d4b224d282d6afc2d0b947711ee Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 31 Oct 2008 16:33:25 +1030 Subject: [PATCH 101/388] Bump to 1.9.99.6. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 5e0b281..17d46d1 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.5], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.6], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) XORG_RELEASE_VERSION From c2d426f232f214f24fba2e30766c94e643716a72 Mon Sep 17 00:00:00 2001 From: Paulo Cesar Pereira de Andrade Date: Tue, 27 Jan 2009 20:06:28 -0200 Subject: [PATCH 102/388] Janitor: Correct make distcheck and dont distribute autogen.sh --- .gitignore | 3 +++ Makefile.am | 4 ++-- configure.ac | 4 ++++ 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index 503dd99..28ba404 100644 --- a/.gitignore +++ b/.gitignore @@ -9,3 +9,6 @@ install-sh missing inputproto.pc *~ +inputproto-*.tar.* +ChangeLog +tags diff --git a/Makefile.am b/Makefile.am index 1d103ff..f87498e 100644 --- a/Makefile.am +++ b/Makefile.am @@ -6,7 +6,7 @@ input_HEADERS = \ pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = inputproto.pc -EXTRA_DIST = autogen.sh inputproto.pc.in +EXTRA_DIST = inputproto.pc.in EXTRA_DIST += ChangeLog MAINTAINERCLEANFILES = ChangeLog @@ -14,6 +14,6 @@ MAINTAINERCLEANFILES = ChangeLog .PHONY: ChangeLog ChangeLog: - (GIT_DIR=$(top_srcdir)/.git git-log > .changelog.tmp && mv .changelog.tmp ChangeLog; rm -f .changelog.tmp) || (touch ChangeLog; echo 'git directory not found: installing possibly empty changelog.' >&2) + $(CHANGELOG_CMD) dist-hook: ChangeLog diff --git a/configure.ac b/configure.ac index 17d46d1..a0de8ad 100644 --- a/configure.ac +++ b/configure.ac @@ -2,7 +2,11 @@ AC_PREREQ([2.57]) AC_INIT([InputProto], [1.9.99.6], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) +# Require xorg-macros: XORG_CHANGELOG +m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.2 or later before running autoconf/autogen])]) +XORG_MACROS_VERSION(1.2) XORG_RELEASE_VERSION +XORG_CHANGELOG AC_OUTPUT([Makefile inputproto.pc]) From f39d3c8d6035fe65ad788987e291b99ad22448dd Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 4 Feb 2009 15:21:55 +1000 Subject: [PATCH 103/388] Whitespace cleanups. Yep. Slow day today. --- XIproto.h | 1066 ++++++++++++++++++++++++++--------------------------- 1 file changed, 533 insertions(+), 533 deletions(-) diff --git a/XIproto.h b/XIproto.h index 7238fa6..c6604eb 100644 --- a/XIproto.h +++ b/XIproto.h @@ -80,7 +80,7 @@ SOFTWARE. typedef struct _XExtEventInfo { Mask mask; - BYTE type; + BYTE type; BYTE word; } XExtEventInfo; @@ -133,15 +133,15 @@ struct tmask #define X_OpenDevice 3 #define X_CloseDevice 4 #define X_SetDeviceMode 5 -#define X_SelectExtensionEvent 6 +#define X_SelectExtensionEvent 6 #define X_GetSelectedExtensionEvents 7 #define X_ChangeDeviceDontPropagateList 8 -#define X_GetDeviceDontPropagateList 9 -#define X_GetDeviceMotionEvents 10 +#define X_GetDeviceDontPropagateList 9 +#define X_GetDeviceMotionEvents 10 #define X_ChangeKeyboardDevice 11 #define X_ChangePointerDevice 12 -#define X_GrabDevice 13 -#define X_UngrabDevice 14 +#define X_GrabDevice 13 +#define X_UngrabDevice 14 #define X_GrabDeviceKey 15 #define X_UngrabDeviceKey 16 #define X_GrabDeviceButton 17 @@ -157,8 +157,8 @@ struct tmask #define X_SetDeviceModifierMapping 27 #define X_GetDeviceButtonMapping 28 #define X_SetDeviceButtonMapping 29 -#define X_QueryDeviceState 30 -#define X_SendExtensionEvent 31 +#define X_QueryDeviceState 30 +#define X_SendExtensionEvent 31 #define X_DeviceBell 32 #define X_SetDeviceValuators 33 #define X_GetDeviceControl 34 @@ -191,27 +191,27 @@ struct tmask */ typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_GetExtensionVersion */ - CARD16 length B16; - CARD16 nbytes B16; + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GetExtensionVersion */ + CARD16 length B16; + CARD16 nbytes B16; CARD8 majorVersion; /* As supported by client if nbytes is 0 */ CARD8 minorVersion; /* As supported by client if nbytes is 0 */ } xGetExtensionVersionReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_GetExtensionVersion */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD16 major_version B16; - CARD16 minor_version B16; - BOOL present; - CARD8 pad1, pad2, pad3; - CARD32 pad01 B32; - CARD32 pad02 B32; - CARD32 pad03 B32; - CARD32 pad04 B32; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetExtensionVersion */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD16 major_version B16; + CARD16 minor_version B16; + BOOL present; + CARD8 pad1, pad2, pad3; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; } xGetExtensionVersionReply; /********************************************************* @@ -221,23 +221,23 @@ typedef struct { */ typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_ListInputDevices */ - CARD16 length B16; + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_ListInputDevices */ + CARD16 length B16; } xListInputDevicesReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_ListInputDevices */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD8 ndevices; - CARD8 pad1, pad2, pad3; - CARD32 pad01 B32; - CARD32 pad02 B32; - CARD32 pad03 B32; - CARD32 pad04 B32; - CARD32 pad05 B32; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_ListInputDevices */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 ndevices; + CARD8 pad1, pad2, pad3; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; } xListInputDevicesReply; typedef struct _xDeviceInfo *xDeviceInfoPtr; @@ -246,68 +246,68 @@ typedef struct _xAnyClassinfo *xAnyClassPtr; typedef struct _xAnyClassinfo { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; + CARD8 c_class; #else - CARD8 class; + CARD8 class; #endif - CARD8 length; + CARD8 length; } xAnyClassInfo; typedef struct _xDeviceInfo { CARD32 type B32; CARD8 id; - CARD8 num_classes; - CARD8 use; /* IsXPointer | IsXKeyboard | IsXExtension... */ - CARD8 attached; /* id of master dev (if IsXExtension..) */ + CARD8 num_classes; + CARD8 use; /* IsXPointer | IsXKeyboard | IsXExtension... */ + CARD8 attached; /* id of master dev (if IsXExtension..) */ } xDeviceInfo; typedef struct _xKeyInfo *xKeyInfoPtr; typedef struct _xKeyInfo { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; + CARD8 c_class; #else - CARD8 class; + CARD8 class; #endif - CARD8 length; - KeyCode min_keycode; - KeyCode max_keycode; - CARD16 num_keys B16; - CARD8 pad1,pad2; + CARD8 length; + KeyCode min_keycode; + KeyCode max_keycode; + CARD16 num_keys B16; + CARD8 pad1,pad2; } xKeyInfo; typedef struct _xButtonInfo *xButtonInfoPtr; typedef struct _xButtonInfo { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; + CARD8 c_class; #else - CARD8 class; + CARD8 class; #endif - CARD8 length; - CARD16 num_buttons B16; + CARD8 length; + CARD16 num_buttons B16; } xButtonInfo; typedef struct _xValuatorInfo *xValuatorInfoPtr; typedef struct _xValuatorInfo { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; + CARD8 c_class; #else - CARD8 class; + CARD8 class; #endif - CARD8 length; - CARD8 num_axes; - CARD8 mode; - CARD32 motion_buffer_size B32; + CARD8 length; + CARD8 num_axes; + CARD8 mode; + CARD32 motion_buffer_size B32; } xValuatorInfo; typedef struct _xAxisInfo *xAxisInfoPtr; typedef struct _xAxisInfo { - CARD32 resolution B32; - CARD32 min_value B32; - CARD32 max_value B32; + CARD32 resolution B32; + CARD32 min_value B32; + CARD32 max_value B32; } xAxisInfo; /********************************************************* @@ -318,33 +318,33 @@ typedef struct _xAxisInfo { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_OpenDevice */ - CARD16 length B16; + CARD8 ReqType; /* always X_OpenDevice */ + CARD16 length B16; CARD8 deviceid; BYTE pad1, pad2, pad3; } xOpenDeviceReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_OpenDevice */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD8 num_classes; - BYTE pad1, pad2, pad3; - CARD32 pad00 B32; - CARD32 pad01 B32; - CARD32 pad02 B32; - CARD32 pad03 B32; - CARD32 pad04 B32; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_OpenDevice */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 num_classes; + BYTE pad1, pad2, pad3; + CARD32 pad00 B32; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; } xOpenDeviceReply; typedef struct { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; + CARD8 c_class; #else - CARD8 class; + CARD8 class; #endif - CARD8 event_type_base; + CARD8 event_type_base; } xInputClassInfo; /********************************************************* @@ -355,8 +355,8 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_CloseDevice */ - CARD16 length B16; + CARD8 ReqType; /* always X_CloseDevice */ + CARD16 length B16; CARD8 deviceid; BYTE pad1, pad2, pad3; } xCloseDeviceReq; @@ -368,26 +368,26 @@ typedef struct { */ typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_SetDeviceMode */ - CARD16 length B16; + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_SetDeviceMode */ + CARD16 length B16; CARD8 deviceid; CARD8 mode; - BYTE pad1, pad2; + BYTE pad1, pad2; } xSetDeviceModeReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_SetDeviceMode */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD8 status; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_SetDeviceMode */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 status; BYTE pad1, pad2, pad3; - CARD32 pad01 B32; - CARD32 pad02 B32; - CARD32 pad03 B32; - CARD32 pad04 B32; - CARD32 pad05 B32; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; } xSetDeviceModeReply; /********************************************************* @@ -398,9 +398,9 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_SelectExtensionEvent */ - CARD16 length B16; - Window window B32; + CARD8 ReqType; /* always X_SelectExtensionEvent */ + CARD16 length B16; + Window window B32; CARD16 count B16; CARD16 pad00 B16; } xSelectExtensionEventReq; @@ -413,23 +413,23 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* X_GetSelectedExtensionEvents */ - CARD16 length B16; + CARD8 ReqType; /* X_GetSelectedExtensionEvents */ + CARD16 length B16; Window window B32; } xGetSelectedExtensionEventsReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* GetSelectedExtensionEvents */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD16 this_client_count B16; - CARD16 all_clients_count B16; - CARD32 pad01 B32; - CARD32 pad02 B32; - CARD32 pad03 B32; - CARD32 pad04 B32; - CARD32 pad05 B32; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* GetSelectedExtensionEvents */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD16 this_client_count B16; + CARD16 all_clients_count B16; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; } xGetSelectedExtensionEventsReply; /********************************************************* @@ -440,11 +440,11 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* X_ChangeDeviceDontPropagateList */ - CARD16 length B16; + CARD8 ReqType; /* X_ChangeDeviceDontPropagateList */ + CARD16 length B16; Window window B32; - CARD16 count B16; - CARD8 mode; + CARD16 count B16; + CARD8 mode; BYTE pad; } xChangeDeviceDontPropagateListReq; @@ -456,23 +456,23 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* X_GetDeviceDontPropagateList */ - CARD16 length B16; + CARD8 ReqType; /* X_GetDeviceDontPropagateList */ + CARD16 length B16; Window window B32; } xGetDeviceDontPropagateListReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* GetDeviceDontPropagateList */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD16 count B16; - CARD16 pad00 B16; - CARD32 pad01 B32; - CARD32 pad02 B32; - CARD32 pad03 B32; - CARD32 pad04 B32; - CARD32 pad05 B32; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* GetDeviceDontPropagateList */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD16 count B16; + CARD16 pad00 B16; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; } xGetDeviceDontPropagateListReply; /********************************************************* @@ -482,28 +482,28 @@ typedef struct { */ typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_GetDeviceMotionEvents*/ - CARD16 length B16; - Time start B32; + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GetDeviceMotionEvents*/ + CARD16 length B16; + Time start B32; Time stop B32; CARD8 deviceid; BYTE pad1, pad2, pad3; } xGetDeviceMotionEventsReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_GetDeviceMotionEvents */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD32 nEvents B32; - CARD8 axes; - CARD8 mode; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetDeviceMotionEvents */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD32 nEvents B32; + CARD8 axes; + CARD8 mode; BYTE pad1, pad2; - CARD32 pad01 B32; - CARD32 pad02 B32; - CARD32 pad03 B32; - CARD32 pad04 B32; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; } xGetDeviceMotionEventsReply; /********************************************************* @@ -514,24 +514,24 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* X_ChangeKeyboardDevice */ - CARD16 length B16; - CARD8 deviceid; + CARD8 ReqType; /* X_ChangeKeyboardDevice */ + CARD16 length B16; + CARD8 deviceid; BYTE pad1, pad2, pad3; } xChangeKeyboardDeviceReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_ChangeKeyboardDevice*/ - CARD16 sequenceNumber B16; - CARD32 length B32; /* 0 */ - CARD8 status; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_ChangeKeyboardDevice*/ + CARD16 sequenceNumber B16; + CARD32 length B32; /* 0 */ + CARD8 status; BYTE pad1, pad2, pad3; - CARD32 pad01 B32; - CARD32 pad02 B32; - CARD32 pad03 B32; - CARD32 pad04 B32; - CARD32 pad05 B32; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; } xChangeKeyboardDeviceReply; /********************************************************* @@ -542,26 +542,26 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* X_ChangePointerDevice */ - CARD16 length B16; - CARD8 xaxis; - CARD8 yaxis; - CARD8 deviceid; + CARD8 ReqType; /* X_ChangePointerDevice */ + CARD16 length B16; + CARD8 xaxis; + CARD8 yaxis; + CARD8 deviceid; BYTE pad1; } xChangePointerDeviceReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_ChangePointerDevice */ - CARD16 sequenceNumber B16; - CARD32 length B32; /* 0 */ - CARD8 status; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_ChangePointerDevice */ + CARD16 sequenceNumber B16; + CARD32 length B32; /* 0 */ + CARD8 status; BYTE pad1, pad2, pad3; - CARD32 pad01 B32; - CARD32 pad02 B32; - CARD32 pad03 B32; - CARD32 pad04 B32; - CARD32 pad05 B32; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; } xChangePointerDeviceReply; /********************************************************* @@ -572,30 +572,30 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_GrabDevice */ - CARD16 length B16; - Window grabWindow B32; - Time time B32; + CARD8 ReqType; /* always X_GrabDevice */ + CARD16 length B16; + Window grabWindow B32; + Time time B32; CARD16 event_count B16; CARD8 this_device_mode; CARD8 other_devices_mode; - BOOL ownerEvents; - CARD8 deviceid; - CARD16 pad01 B16; + BOOL ownerEvents; + CARD8 deviceid; + CARD16 pad01 B16; } xGrabDeviceReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_GrabDevice */ - CARD16 sequenceNumber B16; - CARD32 length B32; /* 0 */ - CARD8 status; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GrabDevice */ + CARD16 sequenceNumber B16; + CARD32 length B32; /* 0 */ + CARD8 status; BYTE pad1, pad2, pad3; - CARD32 pad01 B32; - CARD32 pad02 B32; - CARD32 pad03 B32; - CARD32 pad04 B32; - CARD32 pad05 B32; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; } xGrabDeviceReply; /********************************************************* @@ -606,10 +606,10 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_UnGrabDevice */ - CARD16 length B16; - Time time B32; - CARD8 deviceid; + CARD8 ReqType; /* always X_UnGrabDevice */ + CARD16 length B16; + Time time B32; + CARD8 deviceid; BYTE pad1, pad2, pad3; } xUngrabDeviceReq; @@ -621,17 +621,17 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_GrabDeviceKey */ - CARD16 length B16; - Window grabWindow B32; + CARD8 ReqType; /* always X_GrabDeviceKey */ + CARD16 length B16; + Window grabWindow B32; CARD16 event_count B16; - CARD16 modifiers B16; + CARD16 modifiers B16; CARD8 modifier_device; CARD8 grabbed_device; CARD8 key; - BYTE this_device_mode; - BYTE other_devices_mode; - BOOL ownerEvents; + BYTE this_device_mode; + BYTE other_devices_mode; + BOOL ownerEvents; BYTE pad1, pad2; } xGrabDeviceKeyReq; @@ -643,11 +643,11 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_UngrabDeviceKey */ - CARD16 length B16; - Window grabWindow B32; + CARD8 ReqType; /* always X_UngrabDeviceKey */ + CARD16 length B16; + Window grabWindow B32; CARD16 modifiers B16; - CARD8 modifier_device; + CARD8 modifier_device; CARD8 key; CARD8 grabbed_device; BYTE pad1, pad2, pad3; @@ -661,17 +661,17 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_GrabDeviceButton */ - CARD16 length B16; - Window grabWindow B32; + CARD8 ReqType; /* always X_GrabDeviceButton */ + CARD16 length B16; + Window grabWindow B32; CARD8 grabbed_device; CARD8 modifier_device; - CARD16 event_count B16; - CARD16 modifiers B16; - BYTE this_device_mode; - BYTE other_devices_mode; - CARD8 button; - BOOL ownerEvents; + CARD16 event_count B16; + CARD16 modifiers B16; + BYTE this_device_mode; + BYTE other_devices_mode; + CARD8 button; + BOOL ownerEvents; BYTE pad1, pad2; } xGrabDeviceButtonReq; @@ -683,13 +683,13 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_UngrabDeviceButton */ - CARD16 length B16; - Window grabWindow B32; - CARD16 modifiers B16; - CARD8 modifier_device; - CARD8 button; - CARD8 grabbed_device; + CARD8 ReqType; /* always X_UngrabDeviceButton */ + CARD16 length B16; + Window grabWindow B32; + CARD16 modifiers B16; + CARD8 modifier_device; + CARD8 button; + CARD8 grabbed_device; BYTE pad1, pad2, pad3; } xUngrabDeviceButtonReq; @@ -701,11 +701,11 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_AllowDeviceEvents */ - CARD16 length B16; - Time time B32; + CARD8 ReqType; /* always X_AllowDeviceEvents */ + CARD16 length B16; + Time time B32; CARD8 mode; - CARD8 deviceid; + CARD8 deviceid; BYTE pad1, pad2; } xAllowDeviceEventsReq; @@ -716,25 +716,25 @@ typedef struct { */ typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_GetDeviceFocus */ - CARD16 length B16; - CARD8 deviceid; - BYTE pad1, pad2, pad3; + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GetDeviceFocus */ + CARD16 length B16; + CARD8 deviceid; + BYTE pad1, pad2, pad3; } xGetDeviceFocusReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_GetDeviceFocus */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD32 focus B32; - Time time B32; - CARD8 revertTo; - BYTE pad1, pad2, pad3; - CARD32 pad01 B32; - CARD32 pad02 B32; - CARD32 pad03 B32; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetDeviceFocus */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD32 focus B32; + Time time B32; + CARD8 revertTo; + BYTE pad1, pad2, pad3; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; } xGetDeviceFocusReply; /********************************************************* @@ -744,14 +744,14 @@ typedef struct { */ typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_SetDeviceFocus */ - CARD16 length B16; - Window focus B32; - Time time B32; - CARD8 revertTo; - CARD8 device; - CARD16 pad01 B16; + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_SetDeviceFocus */ + CARD16 length B16; + Window focus B32; + Time time B32; + CARD8 revertTo; + CARD8 device; + CARD16 pad01 B16; } xSetDeviceFocusReq; /********************************************************* @@ -762,17 +762,17 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* X_GetFeedbackControl */ - CARD16 length B16; - CARD8 deviceid; + CARD8 ReqType; /* X_GetFeedbackControl */ + CARD16 length B16; + CARD8 deviceid; BYTE pad1, pad2, pad3; } xGetFeedbackControlReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_GetFeedbackControl */ - CARD16 sequenceNumber B16; - CARD32 length B32; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetFeedbackControl */ + CARD16 sequenceNumber B16; + CARD32 length B32; CARD16 num_feedbacks B16; CARD16 pad01 B16; CARD32 pad02 B32; @@ -784,12 +784,12 @@ typedef struct { typedef struct { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; /* feedback class */ + CARD8 c_class; /* feedback class */ #else - CARD8 class; /* feedback class */ + CARD8 class; /* feedback class */ #endif - CARD8 id; /* feedback id */ - CARD16 length B16; /* feedback length */ + CARD8 id; /* feedback id */ + CARD16 length B16; /* feedback length */ } xFeedbackState; typedef struct { @@ -827,12 +827,12 @@ typedef struct { typedef struct { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; /* feedback class id */ + CARD8 c_class; /* feedback class id */ #else - CARD8 class; /* feedback class id */ + CARD8 class; /* feedback class id */ #endif - CARD8 id; - CARD16 length B16; /* feedback length */ + CARD8 id; + CARD16 length B16; /* feedback length */ CARD32 resolution B32; INT32 min_value B32; INT32 max_value B32; @@ -840,24 +840,24 @@ typedef struct { typedef struct { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; /* feedback class id */ + CARD8 c_class; /* feedback class id */ #else - CARD8 class; /* feedback class id */ + CARD8 class; /* feedback class id */ #endif - CARD8 id; - CARD16 length B16; /* feedback length */ + CARD8 id; + CARD16 length B16; /* feedback length */ CARD16 max_symbols B16; CARD16 num_syms_supported B16; } xStringFeedbackState; typedef struct { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; /* feedback class id */ + CARD8 c_class; /* feedback class id */ #else - CARD8 class; /* feedback class id */ + CARD8 class; /* feedback class id */ #endif CARD8 id; - CARD16 length B16; /* feedback length */ + CARD16 length B16; /* feedback length */ CARD8 percent; BYTE pad1, pad2, pad3; CARD16 pitch B16; @@ -866,12 +866,12 @@ typedef struct { typedef struct { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; /* feedback class id */ + CARD8 c_class; /* feedback class id */ #else - CARD8 class; /* feedback class id */ + CARD8 class; /* feedback class id */ #endif CARD8 id; - CARD16 length B16; /* feedback length */ + CARD16 length B16; /* feedback length */ CARD32 led_mask B32; CARD32 led_values B32; } xLedFeedbackState; @@ -884,33 +884,33 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* X_ChangeFeedbackControl */ - CARD16 length B16; + CARD8 ReqType; /* X_ChangeFeedbackControl */ + CARD16 length B16; CARD32 mask B32; - CARD8 deviceid; - CARD8 feedbackid; + CARD8 deviceid; + CARD8 feedbackid; BYTE pad1, pad2; } xChangeFeedbackControlReq; typedef struct { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; /* feedback class id */ + CARD8 c_class; /* feedback class id */ #else - CARD8 class; /* feedback class id */ + CARD8 class; /* feedback class id */ #endif - CARD8 id; /* feedback id */ - CARD16 length B16; /* feedback length */ + CARD8 id; /* feedback id */ + CARD16 length B16; /* feedback length */ } xFeedbackCtl; typedef struct { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; /* feedback class id */ + CARD8 c_class; /* feedback class id */ #else - CARD8 class; /* feedback class id */ + CARD8 class; /* feedback class id */ #endif - CARD8 id; /* feedback length */ - CARD16 length B16; /* feedback length */ - KeyCode key; + CARD8 id; /* feedback length */ + CARD16 length B16; /* feedback length */ + KeyCode key; CARD8 auto_repeat_mode; INT8 click; INT8 percent; @@ -922,13 +922,13 @@ typedef struct { typedef struct { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; /* feedback class id */ + CARD8 c_class; /* feedback class id */ #else - CARD8 class; /* feedback class id */ + CARD8 class; /* feedback class id */ #endif - CARD8 id; /* feedback id */ - CARD16 length B16; /* feedback length */ - CARD8 pad1,pad2; + CARD8 id; /* feedback id */ + CARD16 length B16; /* feedback length */ + CARD8 pad1,pad2; INT16 num B16; INT16 denom B16; INT16 thresh B16; @@ -936,35 +936,35 @@ typedef struct { typedef struct { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; /* feedback class id */ + CARD8 c_class; /* feedback class id */ #else - CARD8 class; /* feedback class id */ + CARD8 class; /* feedback class id */ #endif - CARD8 id; /* feedback id */ - CARD16 length B16; /* feedback length */ + CARD8 id; /* feedback id */ + CARD16 length B16; /* feedback length */ INT32 int_to_display B32; } xIntegerFeedbackCtl; typedef struct { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; /* feedback class id */ + CARD8 c_class; /* feedback class id */ #else - CARD8 class; /* feedback class id */ + CARD8 class; /* feedback class id */ #endif - CARD8 id; /* feedback id */ - CARD16 length B16; /* feedback length */ - CARD8 pad1,pad2; + CARD8 id; /* feedback id */ + CARD16 length B16; /* feedback length */ + CARD8 pad1,pad2; CARD16 num_keysyms B16; } xStringFeedbackCtl; typedef struct { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; /* feedback class id */ + CARD8 c_class; /* feedback class id */ #else - CARD8 class; /* feedback class id */ + CARD8 class; /* feedback class id */ #endif - CARD8 id; /* feedback id */ - CARD16 length B16; /* feedback length */ + CARD8 id; /* feedback id */ + CARD16 length B16; /* feedback length */ INT8 percent; BYTE pad1, pad2, pad3; INT16 pitch B16; @@ -973,12 +973,12 @@ typedef struct { typedef struct { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; /* feedback class id */ + CARD8 c_class; /* feedback class id */ #else - CARD8 class; /* feedback class id */ + CARD8 class; /* feedback class id */ #endif - CARD8 id; /* feedback id */ - CARD16 length B16; /* feedback length */ + CARD8 id; /* feedback id */ + CARD16 length B16; /* feedback length */ CARD32 led_mask B32; CARD32 led_values B32; } xLedFeedbackCtl; @@ -990,28 +990,28 @@ typedef struct { */ typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_GetDeviceKeyMapping */ - CARD16 length B16; - CARD8 deviceid; - KeyCode firstKeyCode; - CARD8 count; + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GetDeviceKeyMapping */ + CARD16 length B16; + CARD8 deviceid; + KeyCode firstKeyCode; + CARD8 count; BYTE pad1; } xGetDeviceKeyMappingReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_GetDeviceKeyMapping */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD8 keySymsPerKeyCode; - CARD8 pad0; - CARD16 pad1 B16; - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; - CARD32 pad6 B32; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetDeviceKeyMapping */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 keySymsPerKeyCode; + CARD8 pad0; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; } xGetDeviceKeyMappingReply; /********************************************************* @@ -1021,13 +1021,13 @@ typedef struct { */ typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_ChangeDeviceKeyMapping */ - CARD16 length B16; - CARD8 deviceid; - KeyCode firstKeyCode; - CARD8 keySymsPerKeyCode; - CARD8 keyCodes; + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_ChangeDeviceKeyMapping */ + CARD16 length B16; + CARD8 deviceid; + KeyCode firstKeyCode; + CARD8 keySymsPerKeyCode; + CARD8 keyCodes; } xChangeDeviceKeyMappingReq; /********************************************************* @@ -1037,26 +1037,26 @@ typedef struct { */ typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_GetDeviceModifierMapping */ - CARD16 length B16; - CARD8 deviceid; + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GetDeviceModifierMapping */ + CARD16 length B16; + CARD8 deviceid; BYTE pad1, pad2, pad3; } xGetDeviceModifierMappingReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_GetDeviceModifierMapping */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD8 numKeyPerModifier; - CARD8 pad0; - CARD16 pad1 B16; - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; - CARD32 pad6 B32; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetDeviceModifierMapping */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 numKeyPerModifier; + CARD8 pad0; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; } xGetDeviceModifierMappingReply; /********************************************************* @@ -1066,27 +1066,27 @@ typedef struct { */ typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_SetDeviceModifierMapping */ - CARD16 length B16; - CARD8 deviceid; - CARD8 numKeyPerModifier; - CARD16 pad1 B16; + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_SetDeviceModifierMapping */ + CARD16 length B16; + CARD8 deviceid; + CARD8 numKeyPerModifier; + CARD16 pad1 B16; } xSetDeviceModifierMappingReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_SetDeviceModifierMapping */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD8 success; - CARD8 pad0; - CARD16 pad1 B16; - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; - CARD32 pad6 B32; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_SetDeviceModifierMapping */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 success; + CARD8 pad0; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; } xSetDeviceModifierMappingReply; /********************************************************* @@ -1097,24 +1097,24 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* X_GetDeviceButtonMapping */ - CARD16 length B16; - CARD8 deviceid; + CARD8 ReqType; /* X_GetDeviceButtonMapping */ + CARD16 length B16; + CARD8 deviceid; BYTE pad1, pad2, pad3; } xGetDeviceButtonMappingReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_GetDeviceButtonMapping */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD8 nElts; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetDeviceButtonMapping */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 nElts; BYTE pad1, pad2, pad3; - CARD32 pad01 B32; - CARD32 pad02 B32; - CARD32 pad03 B32; - CARD32 pad04 B32; - CARD32 pad05 B32; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; } xGetDeviceButtonMappingReply; /********************************************************* @@ -1125,26 +1125,26 @@ typedef struct { typedef struct { CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* X_SetDeviceButtonMapping */ - CARD16 length B16; - CARD8 deviceid; - CARD8 map_length; + CARD8 ReqType; /* X_SetDeviceButtonMapping */ + CARD16 length B16; + CARD8 deviceid; + CARD8 map_length; BYTE pad1, pad2; } xSetDeviceButtonMappingReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_SetDeviceButtonMapping */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD8 status; - BYTE pad0; - CARD16 pad1 B16; - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; - CARD32 pad6 B32; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_SetDeviceButtonMapping */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 status; + BYTE pad0; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; } xSetDeviceButtonMappingReply; /********************************************************* @@ -1155,59 +1155,59 @@ typedef struct { typedef struct { CARD8 reqType; - CARD8 ReqType; /* always X_QueryDeviceState */ - CARD16 length B16; - CARD8 deviceid; + CARD8 ReqType; /* always X_QueryDeviceState */ + CARD16 length B16; + CARD8 deviceid; BYTE pad1, pad2, pad3; } xQueryDeviceStateReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_QueryDeviceState */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD8 num_classes; - BYTE pad0; - CARD16 pad1 B16; - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; - CARD32 pad6 B32; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_QueryDeviceState */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 num_classes; + BYTE pad0; + CARD16 pad1 B16; + CARD32 pad2 B32; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; } xQueryDeviceStateReply; typedef struct { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; + CARD8 c_class; #else - CARD8 class; + CARD8 class; #endif - CARD8 length; + CARD8 length; CARD8 num_keys; - BYTE pad1; - CARD8 keys[32]; + BYTE pad1; + CARD8 keys[32]; } xKeyState; typedef struct { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; + CARD8 c_class; #else - CARD8 class; + CARD8 class; #endif - CARD8 length; + CARD8 length; CARD8 num_buttons; - BYTE pad1; - CARD8 buttons[32]; + BYTE pad1; + CARD8 buttons[32]; } xButtonState; typedef struct { #if defined(__cplusplus) || defined(c_plusplus) - CARD8 c_class; + CARD8 c_class; #else - CARD8 class; + CARD8 class; #endif - CARD8 length; - CARD8 num_valuators; + CARD8 length; + CARD8 num_valuators; CARD8 mode; } xValuatorState; @@ -1221,11 +1221,11 @@ typedef struct { typedef struct { CARD8 reqType; - CARD8 ReqType; /* always X_SendExtensionEvent */ - CARD16 length B16; + CARD8 ReqType; /* always X_SendExtensionEvent */ + CARD16 length B16; Window destination B32; - CARD8 deviceid; - BOOL propagate; + CARD8 deviceid; + BOOL propagate; CARD16 count B16; CARD8 num_events; BYTE pad1,pad2,pad3; @@ -1239,9 +1239,9 @@ typedef struct { typedef struct { CARD8 reqType; - CARD8 ReqType; /* always X_DeviceBell */ - CARD16 length B16; - CARD8 deviceid; + CARD8 ReqType; /* always X_DeviceBell */ + CARD16 length B16; + CARD8 deviceid; CARD8 feedbackid; CARD8 feedbackclass; INT8 percent; @@ -1254,27 +1254,27 @@ typedef struct { */ typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_SetDeviceValuators */ - CARD16 length B16; + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_SetDeviceValuators */ + CARD16 length B16; CARD8 deviceid; CARD8 first_valuator; CARD8 num_valuators; - BYTE pad1; + BYTE pad1; } xSetDeviceValuatorsReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_SetDeviceValuators */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD8 status; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_SetDeviceValuators */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 status; BYTE pad1, pad2, pad3; - CARD32 pad01 B32; - CARD32 pad02 B32; - CARD32 pad03 B32; - CARD32 pad04 B32; - CARD32 pad05 B32; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; } xSetDeviceValuatorsReply; /********************************************************* @@ -1284,37 +1284,37 @@ typedef struct { */ typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_GetDeviceControl */ - CARD16 length B16; + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GetDeviceControl */ + CARD16 length B16; CARD16 control B16; CARD8 deviceid; - BYTE pad2; + BYTE pad2; } xGetDeviceControlReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_GetDeviceControl */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD8 status; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GetDeviceControl */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 status; BYTE pad1, pad2, pad3; - CARD32 pad01 B32; - CARD32 pad02 B32; - CARD32 pad03 B32; - CARD32 pad04 B32; - CARD32 pad05 B32; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; } xGetDeviceControlReply; typedef struct { - CARD16 control B16; /* control type */ - CARD16 length B16; /* control length */ + CARD16 control B16; /* control type */ + CARD16 length B16; /* control length */ } xDeviceState; typedef struct { - CARD16 control B16; /* control type */ - CARD16 length B16; /* control length */ - CARD32 num_valuators B32; /* number of valuators */ + CARD16 control B16; /* control type */ + CARD16 length B16; /* control length */ + CARD32 num_valuators B32; /* number of valuators */ } xDeviceResolutionState; typedef struct { @@ -1364,39 +1364,39 @@ typedef struct { */ typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_ChangeDeviceControl */ - CARD16 length B16; + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_ChangeDeviceControl */ + CARD16 length B16; CARD16 control B16; CARD8 deviceid; BYTE pad0; } xChangeDeviceControlReq; typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_ChangeDeviceControl */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD8 status; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_ChangeDeviceControl */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD8 status; BYTE pad1, pad2, pad3; - CARD32 pad01 B32; - CARD32 pad02 B32; - CARD32 pad03 B32; - CARD32 pad04 B32; - CARD32 pad05 B32; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; + CARD32 pad05 B32; } xChangeDeviceControlReply; typedef struct { - CARD16 control B16; /* control type */ - CARD16 length B16; /* control length */ + CARD16 control B16; /* control type */ + CARD16 length B16; /* control length */ } xDeviceCtl; typedef struct { - CARD16 control B16; /* control type */ - CARD16 length B16; /* control length */ - CARD8 first_valuator; /* first valuator to change */ - CARD8 num_valuators; /* number of valuators to change*/ - CARD8 pad1,pad2; + CARD16 control B16; /* control type */ + CARD16 length B16; /* control length */ + CARD8 first_valuator; /* first valuator to change */ + CARD8 num_valuators; /* number of valuators to change*/ + CARD8 pad1,pad2; } xDeviceResolutionCtl; typedef struct { @@ -1553,9 +1553,9 @@ typedef struct { */ typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_QueryDevicePointer */ - CARD16 length B16; + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_QueryDevicePointer */ + CARD16 length B16; Window win; CARD8 deviceid; CARD8 pad0; @@ -1564,12 +1564,12 @@ typedef struct { typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_QueryDevicePointer */ - CARD16 sequenceNumber B16; - CARD32 length B32; - Window root B32; - Window child B32; + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_QueryDevicePointer */ + CARD16 sequenceNumber B16; + CARD32 length B32; + Window root B32; + Window child B32; INT16 rootX B16; INT16 rootY B16; INT16 winX B16; @@ -1588,9 +1588,9 @@ typedef struct { */ typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_WarpDevicePointer */ - CARD16 length B16; + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_WarpDevicePointer */ + CARD16 length B16; Window src_win B32; Window dst_win B32; INT16 src_x B16; @@ -1611,9 +1611,9 @@ typedef struct { */ typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_ChangeDeviceCursor */ - CARD16 length B16; + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_ChangeDeviceCursor */ + CARD16 length B16; Window win B32; Cursor cursor B32; CARD8 deviceid; @@ -1641,7 +1641,7 @@ typedef struct { CARD16 length B16; /* in bytes */ } xAnyHierarchyChangeInfo; -/* Create a new master device. +/* Create a new master device. * Name of new master follows struct (4-byte padded) */ typedef struct { @@ -1653,7 +1653,7 @@ typedef struct { } xCreateMasterInfo; /* Delete a master device. Will automatically delete the master device paired - * with the given master device. + * with the given master device. */ typedef struct { CARD16 type B16; /* Always CH_RemoveMasterDevice */ @@ -1664,7 +1664,7 @@ typedef struct { CARD8 returnKeyboard; /* keyboard to attach slave keybd devices to*/ } xRemoveMasterInfo; -/* Change a device's attachment. +/* Change a device's attachment. * NewMaster has to be of same type (pointer->pointer, keyboard->keyboard); */ typedef struct { @@ -1792,18 +1792,18 @@ typedef struct { typedef struct { - BYTE type; + BYTE type; CARD8 deviceid; - CARD16 sequenceNumber B16; + CARD16 sequenceNumber B16; KeyButMask device_state B16; CARD8 num_valuators; CARD8 first_valuator; - INT32 valuator0 B32; - INT32 valuator1 B32; - INT32 valuator2 B32; - INT32 valuator3 B32; - INT32 valuator4 B32; - INT32 valuator5 B32; + INT32 valuator0 B32; + INT32 valuator1 B32; + INT32 valuator2 B32; + INT32 valuator3 B32; + INT32 valuator4 B32; + INT32 valuator5 B32; } deviceValuator; /********************************************************** @@ -1814,14 +1814,14 @@ typedef struct * DeviceButtonPress, DeviceButtonRelease, * ProximityIn, ProximityOut * DeviceMotionNotify, - * + * */ typedef struct { - BYTE type; + BYTE type; BYTE detail; - CARD16 sequenceNumber B16; + CARD16 sequenceNumber B16; Time time B32; Window root B32; Window event B32; @@ -1843,9 +1843,9 @@ typedef struct typedef struct { - BYTE type; + BYTE type; BYTE detail; - CARD16 sequenceNumber B16; + CARD16 sequenceNumber B16; Time time B32; Window window B32; BYTE mode; @@ -1869,9 +1869,9 @@ typedef struct typedef struct { - BYTE type; + BYTE type; BYTE deviceid; - CARD16 sequenceNumber B16; + CARD16 sequenceNumber B16; Time time B32; CARD8 num_keys; CARD8 num_buttons; @@ -1892,9 +1892,9 @@ typedef struct typedef struct { - BYTE type; + BYTE type; BYTE deviceid; - CARD16 sequenceNumber B16; + CARD16 sequenceNumber B16; CARD8 keys[28]; } deviceKeyStateNotify; @@ -1906,9 +1906,9 @@ typedef struct typedef struct { - BYTE type; + BYTE type; BYTE deviceid; - CARD16 sequenceNumber B16; + CARD16 sequenceNumber B16; CARD8 buttons[28]; } deviceButtonStateNotify; @@ -1921,9 +1921,9 @@ typedef struct typedef struct { - BYTE type; + BYTE type; BYTE deviceid; - CARD16 sequenceNumber B16; + CARD16 sequenceNumber B16; CARD8 request; KeyCode firstKeyCode; CARD8 count; @@ -1944,9 +1944,9 @@ typedef struct typedef struct { - BYTE type; + BYTE type; BYTE deviceid; - CARD16 sequenceNumber B16; + CARD16 sequenceNumber B16; Time time B32; CARD8 request; BYTE pad1, pad2, pad3; @@ -1965,9 +1965,9 @@ typedef struct typedef struct { - BYTE type; + BYTE type; BYTE pad00; - CARD16 sequenceNumber B16; + CARD16 sequenceNumber B16; Time time B32; BYTE devchange; /* Device{Added|Removed|Enabled|Disabled|ControlChanged} */ BYTE deviceid; @@ -1984,14 +1984,14 @@ typedef struct * * deviceEnterNotify. * This has a slightly different layout than the core event. - * + * */ typedef struct { - BYTE type; + BYTE type; BYTE detail; - CARD16 sequenceNumber B16; + CARD16 sequenceNumber B16; Time time B32; Window root B32; Window event B32; @@ -2035,12 +2035,12 @@ typedef struct /********************************************************* * DeviceHierarchyChangedEvent. - * + * * Intended as a notification event only, the client is expected to query the * server for input devices after receipt of this event. */ -typedef struct +typedef struct { BYTE type; /* always GenericEvent */ BYTE extension; /* XI extension offset */ From 27dc5a8313d48a78a628563132142a97f7a47843 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 5 Feb 2009 14:18:28 +1000 Subject: [PATCH 104/388] Add XI2 protocol specification document. --- XI2proto.txt | 896 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 896 insertions(+) create mode 100644 XI2proto.txt diff --git a/XI2proto.txt b/XI2proto.txt new file mode 100644 index 0000000..bf405ee --- /dev/null +++ b/XI2proto.txt @@ -0,0 +1,896 @@ + + The X Input Extension + Version 2.0 + + Peter Hutterer + peter.hutterer@redhat.com + Red Hat, Inc. + + + +1. Introduction + +The X Input Extension version 2.0 (XI2) is the second major release of the X +Input Extension. + +FIXME + ❧❧❧❧❧❧❧❧❧❧❧ + +2. 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 } + + ❧❧❧❧❧❧❧❧❧❧❧ + +3. Interoperability between version 1.x and 2.0 + +FIXME + + ❧❧❧❧❧❧❧❧❧❧❧ + +4. 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 +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 +or as master keyboards. A master pointer is represented by a visible cursor on +the screen. A master keyboard is represented by a keyboard focus. + +Each master pointer is paired with the respective master keyboard and vice +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 +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 +type (e.g. a physical pointer device can be attached to any master pointer). + +If an event is generated by an SD +- if the SD is attached to a master pointer, it changes the position and/or + button state of the master pointer. +- if the SD is attached to a master keyboard, it sends events to this + keyboard's focus window (if applicable) and/or changes the modifier state of + this keyboard. +- if the SD is not attached to an SD ("floating"), it does not change the + any master device. The SD has its own (invisible) sprite and its own focus. + Both the sprite and the focus must be managed explicitly by the client + program. + +4.3 Event processing for attached slave devices + +Whenever an SD changes its logical state, +- the event is delivered as an XI event to any interested clients. If the + device is floating, event processing stops. + Otherwise, if the device is attached, +- the master device changes its classes to reflect the SD's capabilities. All + interested clients are notified of this device change. +- then, the event is delivered as an XI event from the MD to any interested + clients. If the event has been delivered, event processing stops. + Otherwise, +- the event is delivered as a core event to any interested clients. + +Given that W is the event window, and P the parent window of W, event delivery +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. + + ❧❧❧❧❧❧❧❧❧❧❧ +5. Data types + +BUTTONMASK + A binary mask defined as (1 << button number). + A SETofBUTTONMASK is a binary OR of zero or more BUTTONMASK. + +DEVICE { DEVICEID, AllDevices, AllMasterDevices } + A DEVICE specifies either a DEVICEID or AllDevices or + AllMasterDevices. + +DEVICEID { CARD16 } + A DEVICEID is a numerical ID for a device currently available in the + server. The server may re-use a device ID after a device's removal. + The device IDs 0 and 1 are reserved. + AllDevices ........ 0 + AllMasterDevices .. 1 + +DEVICEUSE { MasterPointer, MasterKeyboard, SlavePointer, + SlaveKeyboard, FloatingSlave } + A DEVICEUSE field specifies the current use of a device in the MD/SD + device hierarchy. See Section 4 for more information. + +EVENTMASK + An EVENTMASK is a binary mask defined as (1 << event type). + A SETofEVENTMASK is a binary OR of zero or more EVENTMASK. + +FP1616 + Fixed point decimal in 16.16 format as 32 bit integer in the form of + (value * 10e15). The client is required to convert to 16.16 decimal + format. + +FP3232 + Fixed point decimal in 32.32 format as one INT32 and one CARD32. + The INT32 contains the integral part, the CARD32 the decimal fraction + shifted by 32. + +VALUATORMASK + A binary mask defined as (1 << valuator number). + A SETofVALUATORMASK is a binary OR of zero or more VALUATORMASK. + + ❧❧❧❧❧❧❧❧❧❧❧ +6. Errors + +Errors are sent using core X error reports. + +Device + A value for a DEVICE argument does not specify a valid DEVICE. + + ❧❧❧❧❧❧❧❧❧❧❧ +7. 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 +protocol reply from the connection, even if the reply is longer than defined +for the XI2 version supported by the client. +Additional bytes in a request may include data supported in later versions of +XI2. Clients should ignore this data. + +7.1 Requests introduced in version 2.0 + + ┌─── + XIQueryVersion + major_version: CARD16 + minor_version: CARD16 + ▶ + major_version: CARD16 + minor_version: CARD16 + └─── + + The client sends the highest supported version to the server and the + server sends the highest version it supports, but no higher than the + requested version. Major versions changes can introduce incompatibilities + in existing functionality, minor version changes introduce only backward + compatible changes. It is the clients responsibility to ensure that the + server supports a version which is compatible with its expectations. + + major_version + Major XI2 version. + minor_version + Minor XI2 version. + + ┌─── + XIQueryDevice + DEVICE deviceid + ▶ + num_devices: CARD16 + deviceinfo: LISTofDEVICEINFO + └─── + + DEVICEINFO { deviceid: DEVICEID + use: DEVICEUSE + attachment: DEVICEID + enabled: BOOL + num_classes: CARD16 + name_len: CARD16 + name: LISTofCHAR8 + classes: LISTofCLASS } + + CLASS { BUTTONCLASS KEYCLASS, AXISCLASS } + + BUTTONCLASS { type: ButtonClass + length: CARD16 + num_buttons: CARD16 + buttons: LISTofATOM } + + KEYCLASS { type: KeyClass + length: CARD16 + num_keys: CARD16 + keys: LISTofCARD32 } + + AXISCLASS { type: AxisClass + length: CARD16 + axisnumber: CARD16 + axisname: ATOM + min: FP3232 + max: FP3232 + resolution: CARD32 } + + XIQueryDevices details information about the requested input devices. + + devices + The device to list. If 'devices' is AllDevices, all enabled and + disabled devices are listed. If 'devices' is AllMasterDevices, all + enabled and disabled master devices are listed. If 'devices' is a + valid DEVICE, only this DEVICE is listed and 'num_devices' is 1. + num_devices + The number of 'deviceinfos' returned. + + Each 'deviceinfo' is detailed as follows: + deviceid + The unique ID of the device. Device IDs may get re-used when a device + is removed. + use + If the device is a master pointer, 'use' is MasterPointer. + If the device is a master keyboard, 'use' is MasterKeyboard. + If the device is a slave pointer, 'use' is SlavePointer. + If the device is a slave keyboard, 'use' is SlaveKeyboard. + If the device is a floating slave, 'use' is FloatingSlave. + + attachment + If the device is a master pointer or a master keyboard, 'attachment' + specifies the paired master keyboard, or the paired master pointer, + respectively. If the device is a non-floating slave device + 'attachment' specifies the master device this device is attached to. + If the device is a floating slave, 'attachment' is undefined. + + enabled + Zero if the device is disabled, non-zero otherwise. + num_classes + Number of 'classes' provided. + name_len + Length of the name in bytes. + classes + Details the available classes provided by the device in an undefined + order. + name + The device's name, padded to a multiple of 4 bytes. + + For all classes, 'type' specifies the device class. Clients are required + to ignore unknown device classes. The 'length' field specifies the length + of the class in 4 byte units. + The following classes may occur only once: ButtonClass, KeyClass + + ButtonClass: + type + Always ButtonClass. + length + Length in 4 byte units. + num_buttons + Number of buttons provided by the device. + buttons + List of Atoms specifying the type of each button. An atom of None + specifies an unnamed button. Buttons are listed in the device-native + order and potential button mappings are ignored. + + KeyClass: + type + Always KeyClass. + length + Length in 4 byte units. + num_keys + Number of keycodes provided by the device. + keys + List of keycodes provided. + + AxisClass: + type + Always AxisClass. + length + Length in 4 byte units. + axisnumber + Axis number of this axis. The axis number is in device-native + order and potential axis mappings are ignored. + axisname + Atom specifying the axis name. An Atom of None specifies an unnamed + axis. + min + Minimum value. + max + Minimum value. + resolution + Resolution in counts/meter. + mode + Relative or Absolute. + + 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. + + ┌─── + XISelectEvents + window: Window + num_masks: CARD16 + masks: LISTofDEVICEEVENTMASK + + └─── + + DEVICEEVENTMASK { deviceid: DEVICE, + mask_len: CARD16, + mask: SETofEVENTMASK + + window + The window to select the events on. + num_masks + Number of items in mask. + deviceid + Numerical deviceid, or AllDevices, or AllMasterDevices. + mask_len + Length of mask in 4 byte units. + mask + Event mask. An event mask for an event type T is defined as (1 << T). + + XISelectEvents selects for XI2 events on 'window'. + + If 'num_masks' is 0, a BadValue error occurs. + + Each 'mask' sets the (and overwrites a previous) event mask for the DEVICE + specified through 'deviceid'. The device 'AllDevices' or + 'AllMasterDevices' is treated as a separate device by server. A client's + event mask is the union of 'AllDevices', 'AllMasterDevices' and the + per-device event mask. + The removal of device from the server unsets the event masks for the + device. If an event mask is set for AllDevices or AllMasterDevices, the + event mask is not cleared on device removal and affects all future + devices. + + If 'mask_len' is 0, the event mask for the given device is cleared. + + ┌─── + XIQueryDevicePointer + window: Window + deviceid: DEVICEID + ▶ + root: Window + child: Window + root_x: FP1616 + root_y: FP1616 + win_x: FP1616 + win_y: FP1616 + same_screen: BOOL + └─── + + Query a master pointer device for its current position. + + root + The root window the pointer is logically on. + child + The child window of 'window' that contains the pointer or None. + root_x + root_y + Pointer position relative to the root window's origin. + win_x + win_y + Pointer position relative to 'window' or 0 if 'same_screen' is false. + same_screen + TRUE if 'window' is on the same screen as the pointer. + + ┌─── + XIWarpDevicePointer + src_win: Window + dst_win: Window + src_x: FP1616 + src_y: FP1616 + src_width: INT16 + src_height: INT16 + dst_x: FP1616 + dst_y: FP1616 + deviceid: DEVICEID + └─── + + WarpDevicePointer moves the pointer of 'deviceid' as if the user had moved + the pointer. WarpDevicePointer can only be called for MasterPointer and + FloatingSlave devices. + + src_win + If src_window is not None, the move only takes place if src_window + contains the pointer and the pointer is contained in the specified + rectangle of src_window. + dst_win + If dst_win is None, this request moves the pointer by offsets + 'dst_x'/'dst_y' relative to the current position of the pointer. If + dst_window is a window, this request moves the pointer to + 'dst_x'/'dst_y' relative to dst_win's origin. + src_x + src_y + src_width + src_height + Specifies the source window rectangle. + dst_x + dst_y + The relative coordinates to move the pointer if 'dst_win' is None, or + the absolute coordinates if 'dst_win' is a window. + deviceid + The device to warp. + + This request cannot be used to move the pointer outside the confine-to + window of an active pointer grab. An attempt will only move the pointer as + 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. + + ┌─── + XIChangeDeviceCursor + win: Window + cursor: Cursor + deviceid: DEVICEID + └─── + + Change a master pointer's cursor on the specified window. + + window + The window. + cursor + The new cursor or None. + deviceid + The master pointer device. + + 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 + protocol's window attributes, display cursor C(w). + - repeat on parent window until a cursor has been found. + + ┌─── + XIChangeDeviceHierarchy + num_changes: CARD8 + changes: LISTofHIERARCHYCHANGES + └─── + + HIERARCHYCHANGE { CREATEMASTER, REMOVEMASTER, ATTACHSLAVE, DETACHSLAVE } + + HIERARCHYCHANGETYPE { CreateMaster, RemoveMaster, AttachSlave, DetachSlave } + + CHANGEMODE { Float, Attach } + + CREATEMASTER { type: HIERARCHYCHANGETYPE + length: CARD16 + name_len: CARD16 + send_core: BOOL + enable: BOOL + name: LISTofCHAR8 } + + REMOVEMASTER { type: HIERARCHYCHANGETYPE + length: CARD16 + deviceid: DEVICEID + return_mode: CHANGEMODE + return_pointer: DEVICEID + return_keyboard: DEVICEID } + + ATTACHSLAVE { type: HIERARCHYCHANGETYPE + length: CARD16 + deviceid: DEVICEID + master: DEVICEID } + + DETACHSLAVE { type: HIERARCHYCHANGETYPE + length: CARD16 + deviceid: DEVICEID } + + XIChangeDeviceHierarchy allows a client to modify the MD/SD device + hierarchy (see Section 4). + + num_changes + The number of changes to apply to the current hierarchy. + changes + The list of changes. + + The server processes the changes one by one and applies changes + immediately. If an error occurs, processing stops at the current change + and returns the number of successfully applied changes in the error. + + CREATEMASTER creates a pair of master devices. + type + Always CreateMaster. + length + Length in 4 byte units. + name_len + Length of 'name' in bytes. + send_core + TRUE if the device should send core events. + enable + TRUE if the device is to be enabled immediately. + name + The name for the new master devices. The master pointer's name is + automatically appended with " pointer", the master keyboard's name is + automatically appended with " keyboard". + + REMOVEMASTER removes an existing master device. + type + Always RemoveMaster. + length + Length in 4 byte units. + deviceid + The device to remove. + return_mode + Return mode for attached slave devices. + If 'return_mode' is Float, all slave devices are set to floating. + If 'return_mode' is Attach, slave pointers are attached to + 'return_pointer' and slave keyboards are attached to + 'return_keyboard'. + return_pointer + return_keyboard + The master pointer and master keyboard to attach slave devices to, if + 'return_mode' is Attach. + + Removing a master pointer removes the paired master keyboard and vice + versa. + + ATTACHSLAVE attaches a slave device to a given master device. + type + Always ChangeAttachment. + length + Length in 4 byte units. + deviceid + Deviceid of the slave device. + master + The new master device to attach this slave device to. + + DETACHSLAVE detaches a slave device from its current master device. + type + Always ChangeAttachment. + length + Length in 4 byte units. + deviceid + Deviceid of the slave device. + + ┌─── + XISetClientPointer + win: Window + deviceid: DEVICEID + └─── + + Set the ClientPointer for the client owning 'win' to the given device. + + win + Window or client ID. + deviceid + The master pointer or master keyboard that acts as ClientPointer. + + Some protocol requests are ambiguous and the server has to choose a device + to provide data for a request or a reply. By default, the server will + choose a client's ClientPointer device to provide the data, unless the + client currently has a grab on another device. + + ┌─── + XIGetClientPointer + win: Window + ▶ + set: BOOL + deviceid: DEVICEID + └─── + + Query the ClientPointer for the client owning 'win'. + + win + The window or client ID. + set + TRUE if the client has an explicitly set ClientPointer. + deviceid + The master pointer that acts as a ClientPointer if 'set' is TRUE. + +8. Events: + +An event specifies its length in 4-byte units after the initial 32 bytes. +Future versions of the protocol may provide additional information +in the same event, thus increasing the event size. Clients are required to +always read the number of bytes specified by the event, not the size of the +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 + RawEvent + Enter + Leave + +All events have a set of common fields specified as EVENTHEADER. + + +EVENTHEADER { type: BYTE + extension: BYTE + sequenceNumber: CARD16 + length: CARD32 + evtype: CARD16 + deviceid: DEVICEID + time: Time } + + type + Always GenericEvent. + extension + Always the X Input extension offset. + sequenceNumber + Sequence number of last request processed by the server. + length + Length in 4-byte units after the initial 32 bytes. + evtype + XI-specific event type. + deviceid + Numerical device id for a device. + time + Time in ms. + + + ┌─── + DeviceHierarchyEvent: + EVENTHEADER + flags: SETofHIERARCHYMASK + num_devices: CARD16 + deviceinfo: LISTofHIERARCHYINFO + └─── + + + HIERARCHYMASK { MasterAdded, MasterRemoved, SlaveAttached, SlaveDetached, + SlaveAdded, SlaveRemoved, DeviceEnabled, DeviceDisabled } + + HIERARCHYINFO { deviceid: DEVICEID, + attachment: DEVICEID, + type: DEVICEUSE + enabled: BOOL } + + flags + Set of the changes that have occured, causing this event. + num_devices + The number of devices present in the hierarchy. + devices + The current hierarchy layout for each device. + + An XDeviceHierarchyEvent is sent whenever the device hierarchy been + changed. The 'flags' specify all types of hierarchy modifiations that have + occured. + For all devices, 'deviceinfo' details the hierarchy information after the + modification of the hierarchy has occured. For each device specified with + 'deviceid': + - if 'type' is MasterPointer or MasterKeyboard, 'attachment' decribes the + pairing of this device. + - if 'type' is SlavePointer or SlaveKeyboard, 'attachment' describes the + master device this device is attached to. + - if 'type' is FloatingSlave device, 'attachment' is undefined. + + enabled + TRUE if the device is enabled and can send events. A disabled master + device will not forward events from an attached, enabled slave + device. + + Note: Multiple devices may be affected in one hierarchy change, + 'deviceid' in an XDeviceHierarchyChangedEvent is always the first affected + device. Clients should ignore deviceid and instead use the 'devices' list. + + ┌─── + DeviceChangedEvent: + EVENTHEADER + reason: CHANGEREASON + source: DEVICEID + num_classes: CARD16 + classes: LISTofCLASS + └─── + + CHANGEREASON { SlaveSwitch, DeviceChange } + + A DeviceChangeEvent is sent whenever a device changes it's capabilities. + This can happen either by a new slave device sending events through a + master device, or by a physical device changing capabilities at runtime. + + reason + The reason for generating this event. + If 'reason' is SlaveSwitch, the slave device sending events through + this device has changed and 'source' specifies the new slave device. + A SlaveSwitch 'reason' can only occur on a master device. + If 'reason' is DeviceChange, the device itself has changed through + other means (e.g. a physical device change) and 'source' is + undefined. A DeviceChange can only occur on a slave device. + source + The source of the new classes. Only defined in 'reason' is + SlaveSwitch. + num_classes + Number of 'classes' provided. + classes + 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 XQueryInputDevice + request. + + ┌─── + DeviceEvent: + EVENTHEADER + detail: CARD32 + root: Window + event: Window + child: Window + root_x: FP1616 + root_y: FP1616 + event_x: FP1616 + event_y: FP1616 + buttons_len: CARD16 + valuators_len: CARD16 + sourceid: DEVICEID + mods: MODIFIERINFO + group: GROUPINFO + buttons: SETofBUTTONMASK + valuators: SETofVALUATORMASK + axisvalues: LISTofFP3232 + └─── + + BUTTONBIT { (1 << Button1), (1 << Button2), ... , (1 << ButtonN) } + VALUATORBIT { (1 << 1), ( 1 << 2), ... ( 1 << n) } + + MODIFIERINFO { base_mods: CARD32, + latched_mods: CARD32, + locked_mods: CARD32} + GROUPINFO { base_group: CARD8, + latched_group: CARD8, + locked_group: CARD8 } + + An XDeviceEvent 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. + + detail + The button number or key code, or 0. + root + event + child + The root window, event window or subwindow, respectively. See core + protocol specification for more detail. + root_x + root_y + The position of the pointer in screen coordinates (16.16 fixed point). + event_x + event_y + The position of the pointer in screen coordinates relative to the + event window (16.16 fixed point). + + buttons_len + The length of 'buttons' in 4 byte units. + valuators_len + The length of 'valuators' in 4 byte units. + sourceid + The source device that originally generated the event. + mods + XKB modifier state before the event occured. + group + XKB group state before the event. + buttons + Button state before the event. + valuators + Bitmask of valuators provided in 'axisvalues'. + axisvalues + Valuator data in device-native resolution. + + Modifier state in 'mods' is detailed as follows: + base_mods + XKB base modifier state. + latched_mods + XKB latched modifier state. + locked_mods + XKB locked modifier state. + + Group state in 'group' is detailed as follows: + base_group + XKB base group state. + latched_group + XKB latched group state. + locked_group + XKB locked group state. + + ┌─── + RawEvent + EVENTHEADER + eventtype: RAWTYPE + detail: CARD32 + buttons_len: CARD16 + valuators_len: CARD16 + buttons: SETofBUTTONMASK + valuators: SETofVALUATORMASK + axisvalues: LISTofFP3232 + axisvalues_raw: LISTofFP3232 + └─── + + RAWTYPE { Motion, KeyPress, KeyRelease, ButtonPress, ButtonRelease } + + A RawDevice event provides the information provided by the driver to the + client. RawDevice events are only generated for slave devices and provide + both the raw data as supplied by the driver and 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. + RawDeviceEvents are sent exclusively to all root windows or to the client + that grabbed the device only. + + eventtype + The type of event that occured on the device. + detail + The button number or keycode. + buttons_len + The length of 'buttons' in 4 byte units. + valuators_len + The length of 'valuators' in 4 byte units. + buttons + Button state before the event. + valuators + Bitmask of valuators provided in 'axisvalues' and 'axisvalues_raw'. + axisvalues + Valuator data in device-native resolution. + axisvalues_raw + Untransformed valuator data in device-native resolution. + + ┌─── + Enter or Leave + EVENTHEADER + root: Window + event: Window + child: Window + sourceid: DEVICEID + root_x: FP1616 + root_y: FP1616 + event_x FP1616 + event_y: FP1616 + mode: NOTIFYMODE + detail: NOTIFYDETAIL + same_screen: BOOL + focus: BOOL + └─── + + NOTIFYMODE { Normal, Grab, Ungrab } + NOTIFYDETAIL { Ancestor, Virtual, Inferior, Nonlinear, NonlinearVirtual, + Pointer, PointerRoot, None } + + Enter or Leave events are sent whenever a device's pointer enters or + leaves a window. + The enter/leave model is described in the core protocol specification, + Section 11. (EnterNotify, LeaveNotify events). + + root + event + child + The root window, event window, and child window, respectively. See the + core protocol specification for more detail. + sourceid + The device that caused the pointer to move. + root_x + root_y + The pointer coordinates relative to the root window. + event_x + event_y + The pointer coordinates relative to the event window. + mode + Normal pointer motion events have mode Normal. Pseudo-motion events + when a grab activates have mode Grab, and pseudo-motion events when a + grab deactivates have mode Ungrab. + detail + Specifies the relation of the event window to the window the pointer + entered or left. See the core protocol spec for details. + same_screen + TRUE if the event window is on the same screen as the pointer's root + window. + focus + If the event window is the focus window or an inferior of the focus + window, then focus is True. Otherwise, focus is False. + + ❧❧❧❧❧❧❧❧❧❧❧ From 69f5b8a3ff8258cc6d50cca7d5382b0fe9fed893 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 5 Feb 2009 15:57:56 +1000 Subject: [PATCH 105/388] Add XI2.h and XI2proto.h, and a few required defines to XI.h --- Makefile.am | 6 +- XI2.h | 103 +++++++++ XI2proto.h | 617 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 724 insertions(+), 2 deletions(-) create mode 100644 XI2.h create mode 100644 XI2proto.h diff --git a/Makefile.am b/Makefile.am index f87498e..f41d768 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,14 +1,16 @@ inputdir = $(includedir)/X11/extensions input_HEADERS = \ XI.h \ - XIproto.h + XIproto.h \ + XI2.h \ + XI2proto.h pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = inputproto.pc EXTRA_DIST = inputproto.pc.in -EXTRA_DIST += ChangeLog +EXTRA_DIST += ChangeLog XI2proto.txt MAINTAINERCLEANFILES = ChangeLog .PHONY: ChangeLog diff --git a/XI2.h b/XI2.h new file mode 100644 index 0000000..f612759 --- /dev/null +++ b/XI2.h @@ -0,0 +1,103 @@ +/* + * Copyright © 2009 Red Hat, Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + */ + +#ifndef _XI2_H_ +#define _XI2_H_ + +/* DeviceChangedEvent change reasons */ +#define SlaveSwitch 1 +#define DeviceChange 2 + +/* Hierarchy flags */ +#define HF_MasterAdded (1 << 0) +#define HF_MasterRemoved (1 << 1) +#define HF_SlaveAdded (1 << 2) +#define HF_SlaveRemoved (1 << 3) +#define HF_SlaveAttached (1 << 4) +#define HF_SlaveDetached (1 << 5) +#define HF_DeviceEnabled (1 << 6) +#define HF_DeviceDisabled (1 << 7) + +/* Valuator modes */ +#define ModeRelative 0 +#define ModeAbsolute 1 + +/* Device types */ +#define MasterPointer 1 +#define MasterKeyboard 2 +#define SlavePointer 3 +#define SlaveKeyboard 4 +#define FloatingSlave 5 + +/* Device classes */ +/* These may be defined if XI.h is included first */ +#ifndef KeyClass +#define KeyClass 0 +#endif +#ifndef ButtonClass +#define ButtonClass 1 +#endif +#ifndef ValuatorClass +#define ValuatorClass 2 +#endif + +/* XI2 mask macro */ +#define XIMASK(event) (1 << (event)) + +#define AllDevices 0 +#define AllMasterDevices 1 + +/* Event types */ +#define XI_DeviceChanged 1 +#define XI_KeyPress 2 +#define XI_KeyRelease 3 +#define XI_ButtonPress 4 +#define XI_ButtonRelease 5 +#define XI_Motion 6 +#define XI_Enter 7 +#define XI_Leave 8 +#define XI_FocusIn 9 +#define XI_FocusOut 10 +#define XI_HierarchyChanged 11 +#define XI_RawEvent 12 +#define XI_LASTEVENT XI_RawEvent + +/* Event masks. + * Note: the protocol spec defines a mask to be of (1 << type). Clients are + * free to create masks by bitshifting instead of using these defines. + */ +#define XI_DeviceChangedMask (1 << XI_DeviceChanged) +#define XI_KeyPressMask (1 << XI_KeyPress) +#define XI_KeyReleaseMask (1 << XI_KeyRelease) +#define XI_ButtonPressMask (1 << XI_ButtonPress) +#define XI_ButtonReleaseMask (1 << XI_ButtonRelease) +#define XI_MotionMask (1 << XI_Motion) +#define XI_EnterMask (1 << XI_Enter) +#define XI_LeaveMask (1 << XI_Leave) +#define XI_FocusInMask (1 << XI_FocusIn) +#define XI_FocusOutMask (1 << XI_FocusOut) +#define XI_HierarchyChangedMask (1 << XI_HierarchyChanged) +#define XI_RawEventMask (1 << XI_RawEvent) + +#endif /* _XI2_H_ */ diff --git a/XI2proto.h b/XI2proto.h new file mode 100644 index 0000000..e54b145 --- /dev/null +++ b/XI2proto.h @@ -0,0 +1,617 @@ +/* + * Copyright © 2009 Red Hat, Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + */ + +/** + * @file XI2proto.h + * Protocol definitions for the XI2 protocol. + * + * This file should not be included by clients that merely use XI2, but do not + * need the wire protocol. Such clients should include XI2.h, or the matching + * header from the library. + * + */ +#ifndef _XI2PROTO_H_ +#define _XI2PROTO_H_ + +#include +#include +#include + +/* make sure types have right sizes for protocol structures. */ +#define Window CARD32 +#define Time CARD32 +#define KeyCode CARD8 +#define Mask CARD32 +#define Atom CARD32 +#define FP1616 INT32 /* 16.16 packed fixed point */ + +/* Request opcodes */ +#define X_XIQueryDevicePointer 40 +#define X_XIWarpDevicePointer 41 +#define X_XIChangeDeviceCursor 42 +#define X_XIChangeDeviceHierarchy 43 +#define X_XISetClientPointer 44 +#define X_XIGetClientPointer 45 +#define X_XISelectEvents 46 +#define X_XIQueryVersion 47 +#define X_XIQueryDevice 48 + +#define XI2REQUESTS (X_XIQueryDevice - X_XIQueryDevicePointer + 1) +#define XI2EVENTS (XI_LASTEVENT + 1) + +/************************************************************************************* + * * + * COMMON STRUCTS * + * * + *************************************************************************************/ + +/** + * Struct to describe a device. + * + * For a MasterPointer or a MasterKeyboard, 'attachment' desviced + * + * @see XIQueryDevices + */ +typedef struct { + uint16_t deviceid; + uint16_t use; /**< ::MasterPointer, ::MasterKeyboard, + ::SlavePointer, ::SlaveKeyboard, + ::FloatingSlave */ + uint16_t attachment; /**< Current attachment or pairing.*/ + uint16_t num_classes; /**< Number of classes following this struct. */ + uint16_t name_len; /**< Length of name in bytes. */ + uint8_t enabled; /**< TRUE if device is enabled. */ + uint8_t pad; +} xXIDeviceInfo; + +/** + * Default template for a device class. + * A device class is equivalent to a device's capabilities. Multiple classes + * are supported per device. + * + * @see XIQueryDevices + * @see XIDeviceChangedEvent + */ +typedef struct { + uint16_t type; /**< One of *class */ + uint16_t length; /**< Length in 4 byte units */ +} xXIAnyInfo; + +/** + * Denotes button capability on a device. + * Struct is followed by num_buttons * Atom that names the buttons in the + * device-native setup (i.e. ignoring button mappings). + * + * @see XIQueryDevices + * @see XIDeviceChangedEvent + */ +typedef struct { + uint16_t type; /**< Always ButtonClass */ + uint16_t length; /**< Length in 4 byte units */ + uint16_t num_buttons; /**< Number of buttons provide */ + uint16_t pad; +} xXIButtonInfo; + +/** + * Denotes key capability on a device. + * Struct is followed by num_keys * CARD32 that lists the keycodes available + * on the device. + * + * @see XIQueryDevices + * @see XIDeviceChangedEvent + */ +typedef struct { + uint16_t type; /**< Always KeyClass */ + uint16_t length; /**< Length in 4 byte units */ + uint16_t num_keycodes; /**< Number of keys provided */ + uint16_t pad; +} xXIKeyInfo; + +/** + * Denotes an valuator capability on a device. + * One XIValuatorInfo describes exactly one valuator (axis) on the device. + * + * @see XIQueryDevices + * @see XIDeviceChangedEvent + */ +typedef struct { + uint16_t type; /**< Always ValuatorClass */ + uint16_t length; /**< Length in 4 byte units */ + Atom name; /**< Valuator name */ + int32_t min; /**< Min value, integral part */ + uint32_t min_frac; /**< Min value, fractional part */ + int32_t max; /**< Max value, integral part */ + uint32_t max_frac; /**< Max value, fractional part */ + uint32_t resolution; /**< Resolutions in units/m */ + uint16_t number; /**< Valuator number */ + uint8_t mode; /**< ModeRelative or ModeAbsolute */ + uint8_t pad; +} xXIValuatorInfo; + + +/** + * Used to select for events on a given window. + * Struct is followed by (mask_len * CARD8), with each bit set representing + * the event mask for the given type. A mask bit represents an event type if + * (mask == (1 << type)). + * + * @see XISelectEvents + */ +typedef struct { + uint16_t deviceid; /**< Device id to select for */ + uint16_t mask_len; /**< Length of mask in 4 byte units */ +} xXIDeviceEventMask; + +/************************************************************************************* + * * + * REQUESTS * + * * + *************************************************************************************/ + +/********************************************************** + * XIQueryVersion. + * Query the server for the supported X Input Extension version. + * + */ + +typedef struct { + uint8_t reqType; /* input extension major code */ + uint8_t ReqType; /* always X_XIQueryVersion */ + uint16_t length; + uint16_t major_version; + uint16_t minor_version; +} xXIQueryVersionReq; +#define sz_xXIQueryVersionReq 8 + +typedef struct { + uint8_t repType; /* X_Reply */ + uint8_t RepType; /* always X_XIQueryVersion */ + uint16_t sequenceNumber; + uint32_t length; + uint16_t major_version; + uint16_t minor_version; + uint32_t pad1; + uint32_t pad2; + uint32_t pad3; + uint32_t pad4; + uint32_t pad5; +} xXIQueryVersionReply; +#define sz_xXIQueryVersionReply 32 + +/********************************************************** + * + * XIQueryDevice + * Query the server for information about a specific device or all input + * devices. + * + */ + +typedef struct { + uint8_t reqType; /* input extension major code */ + uint8_t ReqType; /* always X_XIQueryDevice */ + uint16_t length; + uint16_t deviceid; + uint16_t pad; +} xXIQueryDeviceReq; +#define sz_xXIQueryDeviceReq 8 + +typedef struct { + uint8_t repType; /* X_Reply */ + uint8_t RepType; /* always X_XIQueryDevice */ + uint16_t sequenceNumber; + uint32_t length; + uint16_t num_devices; + uint16_t pad0; + uint32_t pad1; + uint32_t pad2; + uint32_t pad3; + uint32_t pad4; + uint32_t pad5; +} xXIQueryDeviceReply; +#define sz_xXIQueryDeviceReply 32 + +/********************************************************** + * + * XISelectEvents + * + */ +typedef struct { + uint8_t reqType; /* input extension major code */ + uint8_t ReqType; /* always X_XISelectEvents */ + uint16_t length; + Window window; + uint16_t num_masks; + uint16_t pad; +} xXISelectEventsReq; +#define sz_xXISelectEventsReq 12 + + +/********************************************************** + * + * QueryDevicePointer. + * + */ + +typedef struct { + uint8_t reqType; /* input extension major code */ + uint8_t ReqType; /* always X_QueryDevicePointer */ + uint16_t length; + Window win; + uint16_t deviceid; + uint16_t pad1; +} xXIQueryDevicePointerReq; +#define sz_xXIQueryDevicePointerReq 12 + + +typedef struct { + uint8_t repType; /* X_Reply */ + uint8_t RepType; /* always X_QueryDevicePointer */ + uint16_t sequenceNumber; + uint32_t length; + Window root; + Window child; + FP1616 root_x; + FP1616 root_y; + FP1616 win_x; + FP1616 win_y; + uint16_t mask; + uint16_t deviceid; + uint8_t same_screen; + uint8_t pad0; + uint16_t pad1; +} xXIQueryDevicePointerReply; +#define sz_xXIQueryDevicePointerReply 40 + +/********************************************************** + * + * WarpDevicePointer. + * + */ + +typedef struct { + uint8_t reqType; /* input extension major code */ + uint8_t ReqType; /* always X_WarpDevicePointer */ + uint16_t length; + Window src_win; + Window dst_win; + INT16 src_x; + INT16 src_y; + uint16_t src_width; + uint16_t src_height; + INT16 dst_x; + INT16 dst_y; + uint16_t deviceid; + uint16_t pad1; +} xXIWarpDevicePointerReq; +#define sz_xXIWarpDevicePointerReq 28 + +/********************************************************** + * + * ChangeDeviceCursor. + * + */ + +typedef struct { + uint8_t reqType; /* input extension major code */ + uint8_t ReqType; /* always X_ChangeDeviceCursor */ + uint16_t length; + Window win; + Cursor cursor; + uint16_t deviceid; + uint16_t pad1; +} xXIChangeDeviceCursorReq; +#define sz_xXIChangeDeviceCursorReq 16 + +/********************************************************** + * + * ChangeDeviceHierarchy + * + */ + +typedef struct { + uint8_t reqType; /* input extension major code */ + uint8_t ReqType; /* always X_ChangeDeviceHierarchy */ + uint16_t length; + uint8_t num_changes; + uint8_t pad0; + uint16_t pad1; +} xXIChangeDeviceHierarchyReq; +#define sz_xXIChangeDeviceHierarchyReq 8 + +typedef struct { + uint16_t type; + uint16_t length; /* in 4 byte units */ +} xXIAnyHierarchyChangeInfo; + +/** + * Create a new master device. + * Name of new master follows struct (4-byte padded) + */ +typedef struct { + uint16_t type; /* Always CH_CreateMasterDevice */ + uint16_t length; /* 2 + (namelen + padding)/4 */ + uint16_t name_len; + uint8_t send_core; + uint8_t enable; +} xXICreateMasterInfo; + +/** + * Delete a master device. Will automatically delete the master device paired + * with the given master device. + */ +typedef struct { + uint16_t type; /* Always CH_RemoveMasterDevice */ + uint16_t length; /* 3 */ + uint16_t deviceid; + uint8_t return_mode; /* AttachToMaster, Floating */ + uint8_t pad; + uint16_t return_pointer; /* Pointer to attach slave ptr devices to */ + uint16_t return_keyboard; /* keyboard to attach slave keybd devices to*/ +} xXIRemoveMasterInfo; + +/* Attach an SD to a new device. + * NewMaster has to be of same type (pointer->pointer, keyboard->keyboard); + */ +typedef struct { + uint16_t type; /* Always CH_AttachSlave */ + uint16_t length; /* 2 */ + uint16_t deviceid; + uint16_t new_master; /* id of new master device */ +} xXIAttachSlaveInfo; + +/* Detach an SD from its current master device. + */ +typedef struct { + uint16_t type; /* Always CH_DetachSlave */ + uint16_t length; /* 2 */ + uint16_t deviceid; + uint16_t pad; +} xXIDetachSlaveInfo; + + +/********************************************************** + * + * SetClientPointer. + * + */ + +typedef struct { + uint8_t reqType; + uint8_t ReqType; /* Always X_SetClientPointer */ + uint16_t length; + Window win; + uint16_t deviceid; + uint16_t pad1; +} xXISetClientPointerReq; +#define sz_xXISetClientPointerReq 12 + +/********************************************************** + * + * GetClientPointer. + * + */ +typedef struct { + uint8_t reqType; + uint8_t ReqType; /* Always X_GetClientPointer */ + uint16_t length; + Window win; +} xXIGetClientPointerReq; +#define sz_xXIGetClientPointerReq 8 + +typedef struct { + uint8_t repType; /* input extension major opcode */ + uint8_t RepType; /* Always X_GetClientPointer */ + uint16_t sequenceNumber; + uint32_t length; + BOOL set; /* client pointer is set */ + uint8_t pad0; + uint16_t deviceid; + uint32_t pad1; + uint32_t pad2; + uint32_t pad3; + uint32_t pad4; + uint32_t pad5; +} xXIGetClientPointerReply; +#define sz_xXIGetClientPointerReply 32 + +/************************************************************************************* + * * + * EVENTS * + * * + *************************************************************************************/ + +typedef struct +{ + uint8_t type; + uint8_t extension; /* XI extension offset */ + uint16_t sequenceNumber; + uint32_t length; + uint16_t evtype; + uint16_t deviceid; + uint32_t time; +} xXIGenericDeviceEvent; + +/*********************************************************** + * DeviceHierarchyEvent + * + */ +typedef struct +{ + uint16_t deviceid; + uint16_t attachment; + uint8_t use; + BOOL enabled; + uint16_t pad; +} xXIHierarchyInfo; + +typedef struct +{ + uint8_t type; /* always GenericEvent */ + uint8_t extension; /* XI extension offset */ + uint16_t sequenceNumber; + uint32_t length; + uint16_t evtype; /* XI_Hierarchy */ + uint16_t deviceid; + uint32_t time; + uint32_t flags; /* MasterAdded, MasterDeleted, + SlaveAttached, SlaveDetached, + SlaveAdded, SlaveRemoved, + DeviceEnabled, DeviceDisabled */ + uint16_t num_devices; + uint16_t pad0; + uint32_t pad1; + uint32_t pad2; +} xXIDeviceHierarchyEvent; + +/*********************************************************** + * DeviceChangedEvent + * + */ + +typedef struct +{ + uint8_t type; /* always GenericEvent */ + uint8_t extension; /* XI extension offset */ + uint16_t sequenceNumber; + uint32_t length; + uint16_t evtype; /* XI_DeviceChanged */ + uint16_t deviceid; /* id of master */ + uint32_t time; + uint16_t num_classes; /* classes that have changed */ + uint16_t sourceid; /* Source for the new classes*/ + uint8_t reason; /* SlaveSwitch, DeviceChange */ + uint8_t pad0; + uint16_t pad1; + uint32_t pad2; + uint32_t pad3; +} xXIDeviceChangedEvent; + +/*********************************************************** + * DeviceEvent + * + */ + +typedef struct +{ + uint32_t base_mods; + uint32_t latched_mods; + uint32_t locked_mods; +} xXIModifierInfo; + +typedef struct +{ + uint8_t base_group; + uint8_t latched_group; + uint8_t locked_group; + uint8_t pad0; +} xXIGroupInfo; + +typedef struct +{ + uint8_t type; /* always GenericEvent */ + uint8_t extension; /* XI extension offset */ + uint16_t sequenceNumber; + uint32_t length; + uint16_t evtype; + uint16_t deviceid; + Time time; + uint32_t detail; /* keycode or button */ + Window root; + Window event; + Window child; +/* └──────── 32 byte boundary ────────┘ */ + FP1616 root_x; /* always screen coords, 16.16 fixed point */ + FP1616 root_y; + FP1616 event_x; /* always screen coords, 16.16 fixed point */ + FP1616 event_y; + uint16_t buttons_len; /* len of button flags in 4 b units */ + uint16_t valuators_len; /* len of val. flags in 4 b units */ + uint16_t sourceid; /* the source device */ + uint16_t pad0; + xXIModifierInfo mods; + xXIGroupInfo group; +} xXIDeviceEvent; + + + +/*********************************************************** + * RawEvent + * + */ + +typedef struct +{ + uint8_t type; /* always GenericEvent */ + uint8_t extension; /* XI extension offset */ + uint16_t sequenceNumber; + uint32_t length; + uint16_t evtype; /* XI_RawEvent */ + uint16_t deviceid; + Time time; + uint32_t detail; + uint16_t eventtype; /* XI_Motion, XI_ButtonPress, + XI_ButtonRelease, XI_KeyPress, + XI_KeyRelease */ + uint16_t buttons_len; + uint16_t valuators_len; + uint16_t pad0; + uint32_t pad1; +} xXIRawDeviceEvent; + +/*********************************************************** + * Enter/LeaveEvents + * + * Note that the layout of root, event, child, root_x, root_y, event_x, + * event_y must be identical to the xXIDeviceEvent. + * + */ + +typedef struct +{ + uint8_t type; /* always GenericEvent */ + uint8_t extension; /* XI extension offset */ + uint16_t sequenceNumber; + uint32_t length; + uint16_t evtype; /* XI_Enter */ + uint16_t deviceid; + Time time; + uint16_t sourceid; + uint8_t mode; + uint8_t detail; + Window root; + Window event; + Window child; +/* └──────── 32 byte boundary ────────┘ */ + FP1616 root_x; + FP1616 root_y; + FP1616 event_x; + FP1616 event_y; + BOOL same_screen; + BOOL focus; + uint16_t pad0; +} xXIEnterEvent; + +typedef xXIEnterEvent xXILeaveEvent; + +#endif /* _XI2PROTO_H_ */ From d2ba9af0517f54fb58358e41859f5e4ead9b64f2 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 26 Feb 2009 15:10:28 +1000 Subject: [PATCH 106/388] Split CH_ChangeAttachment into CH_AttachSlave and CH_DetachSlave CH_ChangeAttachment is still there, but won't be for long. --- XI.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/XI.h b/XI.h index a95945b..358a4c8 100644 --- a/XI.h +++ b/XI.h @@ -289,8 +289,13 @@ SOFTWARE. /* ChangeHierarchy constants */ #define CH_CreateMasterDevice 1 #define CH_RemoveMasterDevice 2 +#define CH_AttachSlave 3 +#define CH_DetachSlave 4 + +/* XXX: do not use, will be removed */ #define CH_ChangeAttachment 3 + #define AttachToMaster 1 #define Floating 2 From fc7f67959ad72c76e852827963d6a42b7d533b89 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 10 Mar 2009 12:26:18 +1000 Subject: [PATCH 107/388] XI2: remove button state from the RawEvent. A RawEvent is supposed to represent the state posted by the device. If a client needs button state, then the client must keep track of it. --- XI2proto.h | 3 +-- XI2proto.txt | 6 ------ 2 files changed, 1 insertion(+), 8 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index e54b145..21a8240 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -573,10 +573,9 @@ typedef struct uint16_t eventtype; /* XI_Motion, XI_ButtonPress, XI_ButtonRelease, XI_KeyPress, XI_KeyRelease */ - uint16_t buttons_len; uint16_t valuators_len; - uint16_t pad0; uint32_t pad1; + uint32_t pad2; } xXIRawDeviceEvent; /*********************************************************** diff --git a/XI2proto.txt b/XI2proto.txt index bf405ee..a3edcb9 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -803,9 +803,7 @@ EVENTHEADER { type: BYTE EVENTHEADER eventtype: RAWTYPE detail: CARD32 - buttons_len: CARD16 valuators_len: CARD16 - buttons: SETofBUTTONMASK valuators: SETofVALUATORMASK axisvalues: LISTofFP3232 axisvalues_raw: LISTofFP3232 @@ -827,12 +825,8 @@ EVENTHEADER { type: BYTE The type of event that occured on the device. detail The button number or keycode. - buttons_len - The length of 'buttons' in 4 byte units. valuators_len The length of 'valuators' in 4 byte units. - buttons - Button state before the event. valuators Bitmask of valuators provided in 'axisvalues' and 'axisvalues_raw'. axisvalues From cac1bcbf6d544f29c3379bc0462bb237e8ff8399 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 10 Mar 2009 15:35:04 +1000 Subject: [PATCH 108/388] Add FP3232 typedef. --- XI2proto.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/XI2proto.h b/XI2proto.h index 21a8240..3862932 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -65,6 +65,11 @@ * COMMON STRUCTS * * * *************************************************************************************/ +/* Fixed point 32.32 */ +typedef struct { + int32_t integral; + uint32_t frac; +} FP3232; /** * Struct to describe a device. From 2339bc5b0eea89e676ac58a38ac5eb6a8ae6e6f9 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 10 Mar 2009 15:42:28 +1000 Subject: [PATCH 109/388] ValuatorInfo moved to FP3232 --- XI2proto.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index 3862932..6680b4b 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -144,10 +144,8 @@ typedef struct { uint16_t type; /**< Always ValuatorClass */ uint16_t length; /**< Length in 4 byte units */ Atom name; /**< Valuator name */ - int32_t min; /**< Min value, integral part */ - uint32_t min_frac; /**< Min value, fractional part */ - int32_t max; /**< Max value, integral part */ - uint32_t max_frac; /**< Max value, fractional part */ + FP3232 min; /**< Min value */ + FP3232 max; /**< Max value */ uint32_t resolution; /**< Resolutions in units/m */ uint16_t number; /**< Valuator number */ uint8_t mode; /**< ModeRelative or ModeAbsolute */ From c9ebfba4a128f0d0eda920a02af013b795adfec5 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 11 Mar 2009 12:30:16 +1000 Subject: [PATCH 110/388] Define FP1616 as one int16_t, one uint16_t. --- XI2proto.h | 8 +++++++- XI2proto.txt | 6 +++--- 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index 6680b4b..e34d3c8 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -44,7 +44,6 @@ #define KeyCode CARD8 #define Mask CARD32 #define Atom CARD32 -#define FP1616 INT32 /* 16.16 packed fixed point */ /* Request opcodes */ #define X_XIQueryDevicePointer 40 @@ -65,6 +64,13 @@ * COMMON STRUCTS * * * *************************************************************************************/ +/* Fixed point 16.16 */ +typedef struct +{ + int16_t integral; + uint16_t frac; +} FP1616; + /* Fixed point 32.32 */ typedef struct { int32_t integral; diff --git a/XI2proto.txt b/XI2proto.txt index a3edcb9..b99d14e 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -130,9 +130,9 @@ EVENTMASK A SETofEVENTMASK is a binary OR of zero or more EVENTMASK. FP1616 - Fixed point decimal in 16.16 format as 32 bit integer in the form of - (value * 10e15). The client is required to convert to 16.16 decimal - format. + Fixed point decimal in 16.16 format as one INT16 and one CARD16. + The INT16 contains the integral part, the CARD32 the decimal fraction + shifted by 16. FP3232 Fixed point decimal in 32.32 format as one INT32 and one CARD32. From da74983b7d18ad06fe828040072d4a985ce4d448 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 11 Mar 2009 13:32:09 +1000 Subject: [PATCH 111/388] Add buttons + modifier/group information to enter/leave events. --- XI2proto.h | 4 +++- XI2proto.txt | 12 ++++++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/XI2proto.h b/XI2proto.h index e34d3c8..394f49b 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -617,7 +617,9 @@ typedef struct FP1616 event_y; BOOL same_screen; BOOL focus; - uint16_t pad0; + uint16_t buttons_len; + xXIModifierInfo mods; + xXIGroupInfo group; } xXIEnterEvent; typedef xXIEnterEvent xXILeaveEvent; diff --git a/XI2proto.txt b/XI2proto.txt index b99d14e..d1daeaf 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -849,6 +849,10 @@ EVENTHEADER { type: BYTE detail: NOTIFYDETAIL same_screen: BOOL focus: BOOL + mods: MODIFIERINFO + group: GROUPINFO + buttons_len: CARD16 + buttons: SETofBUTTONMASK └─── NOTIFYMODE { Normal, Grab, Ungrab } @@ -886,5 +890,13 @@ EVENTHEADER { type: BYTE focus If the event window is the focus window or an inferior of the focus window, then focus is True. Otherwise, focus is False. + mods + XKB modifier state before the event occured. + group + XKB group state before the event. + buttons_len + The length of 'buttons' in 4 byte units. + buttons + Button state before the event. ❧❧❧❧❧❧❧❧❧❧❧ From 0ca1de737aa5cd714a4df3a45422dce415f9df55 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 11 Mar 2009 16:32:06 +1000 Subject: [PATCH 112/388] Add focus events --- XI2proto.h | 2 ++ XI2proto.txt | 21 +++++++++++++++++---- 2 files changed, 19 insertions(+), 4 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index 394f49b..bbac039 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -623,5 +623,7 @@ typedef struct } xXIEnterEvent; typedef xXIEnterEvent xXILeaveEvent; +typedef xXIEnterEvent xXIFocusInEvent; +typedef xXIEnterEvent xXIFocusOutEvent; #endif /* _XI2PROTO_H_ */ diff --git a/XI2proto.txt b/XI2proto.txt index d1daeaf..e865d35 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -835,7 +835,7 @@ EVENTHEADER { type: BYTE Untransformed valuator data in device-native resolution. ┌─── - Enter or Leave + Enter or Leave or FocusIn or FocusOut EVENTHEADER root: Window event: Window @@ -861,8 +861,20 @@ EVENTHEADER { type: BYTE Enter or Leave events are sent whenever a device's pointer enters or leaves a window. - The enter/leave model is described in the core protocol specification, - Section 11. (EnterNotify, LeaveNotify events). + FocusIn or FocusOut events are sent whenever a device's focus is set to or + away from a window. + The enter/leave and focus in/out model is described in the core protocol + specification, Section 11. (EnterNotify, LeaveNotify events). + + For enter and leave events, the modifier and group state is the state of + the paired master device if the device is a master device, or the state of + the attached master keyboard if the device is an attached slave device, or + zero if the device is a floating slave device. + + For focus in and out events, the button state is the state of the paired + master device if the device is a master device, or the state of the + attached master keyboard if the device is an attached slave device, or + zero if the device is a floating slave device. root event @@ -889,7 +901,8 @@ EVENTHEADER { type: BYTE window. focus If the event window is the focus window or an inferior of the focus - window, then focus is True. Otherwise, focus is False. + window, then focus is True. Otherwise, focus is False. This field is + unspecified for focus in/out events. mods XKB modifier state before the event occured. group From 7a73c3c64b1affa946deb66dd22042ee12fd747d Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 12 Mar 2009 15:43:26 +1000 Subject: [PATCH 113/388] Add XISetDeviceFocus and XIGetDeviceFocus requests --- XI2proto.h | 48 +++++++++++++++++++++++++++++++++++++++++++++++- XI2proto.txt | 40 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 87 insertions(+), 1 deletion(-) diff --git a/XI2proto.h b/XI2proto.h index bbac039..5cad6da 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -55,8 +55,10 @@ #define X_XISelectEvents 46 #define X_XIQueryVersion 47 #define X_XIQueryDevice 48 +#define X_XISetDeviceFocus 49 +#define X_XIGetDeviceFocus 50 -#define XI2REQUESTS (X_XIQueryDevice - X_XIQueryDevicePointer + 1) +#define XI2REQUESTS (X_XIGetDeviceFocus - X_XIQueryDevicePointer + 1) #define XI2EVENTS (XI_LASTEVENT + 1) /************************************************************************************* @@ -444,6 +446,50 @@ typedef struct { } xXIGetClientPointerReply; #define sz_xXIGetClientPointerReply 32 +/********************************************************** + * + * SetDeviceFocus. + * + */ +typedef struct { + uint8_t reqType; + uint8_t ReqType; /* Always X_XISetDeviceFocus */ + uint16_t length; + Window focus; + Time time; + uint16_t deviceid; + uint16_t pad0; +} xXISetDeviceFocusReq; +#define sz_xXISetDeviceFocusReq 16 + +/********************************************************** + * + * GetDeviceFocus. + * + */ +typedef struct { + uint8_t reqType; + uint8_t ReqType; /* Always X_XIGetDeviceFocus */ + uint16_t length; + uint16_t deviceid; + uint16_t pad0; +} xXIGetDeviceFocusReq; +#define sz_xXIGetDeviceFocusReq 8 + +typedef struct { + uint8_t repType; /* input extension major opcode */ + uint8_t RepType; /* Always X_XIGetDeviceFocus */ + uint16_t sequenceNumber; + uint32_t length; + Window focus; + uint32_t pad1; + uint32_t pad2; + uint32_t pad3; + uint32_t pad4; + uint32_t pad5; +} xXIGetDeviceFocusReply; +#define sz_xXIGetDeviceFocusReply 32 + /************************************************************************************* * * * EVENTS * diff --git a/XI2proto.txt b/XI2proto.txt index e865d35..5faa730 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -585,6 +585,46 @@ XI2. Clients should ignore this data. deviceid The master pointer that acts as a ClientPointer if 'set' is TRUE. + ┌─── + XISetDeviceFocus + focus: Window + deviceid: DEVICEID + time: Time + └─── + + Set the focus for the given device to the given window. Future key events + from this device are sent to this window. + This request generates FocusIn and FocusOut events. + + focus + A viewable window or None. + deviceid + The device to modify the focus window for. + time + Specifies the time to change the focus or CurrentTime. + + If focus is None, key events from this device are discarded until a new + focus window is set. If focus is a viewable window, key events from this + device are sent to this window. If the window becomes unviewable, the + window's first viewable ancestor automatically becomes the focus window + and FocusIn and FocusOut events are sent as if a client had changed the + focus window. + This is equivalent to RevertToParent in the core XSetInputFocus window. + + 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. + + ┌─── + XIGetDeviceFocus + deviceid: DEVICEID + ▶ + focus: Window + └─── + + Return the current focus window for the given device. + + 8. Events: An event specifies its length in 4-byte units after the initial 32 bytes. From 05f997e68921a1443728a9c58050eb82b73eaea8 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 26 Feb 2009 15:22:55 +1000 Subject: [PATCH 114/388] Bump to 1.9.99.7 --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index a0de8ad..8fc5357 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.6], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.7], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) # Require xorg-macros: XORG_CHANGELOG From 5aa07308a10315f9305cd9637c71f98432c75ecf Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 4 Feb 2009 14:33:57 +1000 Subject: [PATCH 115/388] Remove XI2 requests from XIproto.h All requests been moved to XI2proto.h. Only ExtendedGrabDevice is gone for good. --- XI.h | 19 --- XIproto.h | 338 +----------------------------------------------------- 2 files changed, 2 insertions(+), 355 deletions(-) diff --git a/XI.h b/XI.h index 358a4c8..2a885ea 100644 --- a/XI.h +++ b/XI.h @@ -112,17 +112,6 @@ SOFTWARE. #define sz_xDeleteDevicePropertyReq 12 #define sz_xGetDevicePropertyReq 24 #define sz_xGetDevicePropertyReply 32 -#define sz_xQueryDevicePointerReq 12 -#define sz_xQueryDevicePointerReply 32 -#define sz_xWarpDevicePointerReq 28 -#define sz_xChangeDeviceCursorReq 16 -#define sz_xChangeDeviceHierarchyReq 8 -#define sz_xSetClientPointerReq 12 -#define sz_xGetClientPointerReq 8 -#define sz_xGetClientPointerReply 32 -#define sz_xXiSelectEventReq 16 -#define sz_xExtendedGrabDeviceReq 28 -#define sz_xExtendedGrabDeviceReply 32 #define INAME "XInputExtension" @@ -292,10 +281,6 @@ SOFTWARE. #define CH_AttachSlave 3 #define CH_DetachSlave 4 -/* XXX: do not use, will be removed */ -#define CH_ChangeAttachment 3 - - #define AttachToMaster 1 #define Floating 2 @@ -306,10 +291,6 @@ SOFTWARE. #define XI_DeviceBusy 3 #define XI_BadClass 4 -/* GE masks */ -#define XI_DeviceHierarchyChangedMask (1 << 0) -#define XI_DeviceClassesChangedMask (1 << 1) - /* * Make XEventClass be a CARD32 for 64 bit servers. Don't affect client * definition of XEventClass since that would be a library interface change. diff --git a/XIproto.h b/XIproto.h index c6604eb..21303ba 100644 --- a/XIproto.h +++ b/XIproto.h @@ -71,9 +71,9 @@ SOFTWARE. #define numInputClasses 7 -#define IEVENTS 19 /* does NOT include generic events */ +#define IEVENTS 17 /* does NOT include generic events */ #define IERRORS 5 -#define IREQUESTS 49 +#define IREQUESTS 48 #define CLIENT_REQ 1 @@ -115,12 +115,6 @@ struct tmask #define XI_DeviceButtonstateNotify 14 #define XI_DevicePresenceNotify 15 #define XI_DevicePropertyNotify 16 -#define XI_DeviceEnterNotify 17 -#define XI_DeviceLeaveNotify 18 - -/* GE events */ -#define XI_DeviceHierarchyChangedNotify 0 -#define XI_DeviceClassesChangedNotify 1 /********************************************************* * @@ -168,15 +162,6 @@ struct tmask #define X_ChangeDeviceProperty 37 #define X_DeleteDeviceProperty 38 #define X_GetDeviceProperty 39 -/* XI 2 */ -#define X_QueryDevicePointer 40 -#define X_WarpDevicePointer 41 -#define X_ChangeDeviceCursor 42 -#define X_ChangeDeviceHierarchy 43 -#define X_SetClientPointer 44 -#define X_GetClientPointer 45 -#define X_XiSelectEvent 46 -#define X_ExtendedGrabDevice 47 /********************************************************* * @@ -1543,244 +1528,6 @@ typedef struct { CARD32 pad3 B32; } xGetDevicePropertyReply; -/* XI 2.0 */ - - -/********************************************************** - * - * QueryDevicePointer. - * - */ - -typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_QueryDevicePointer */ - CARD16 length B16; - Window win; - CARD8 deviceid; - CARD8 pad0; - CARD16 pad1 B16; -} xQueryDevicePointerReq; - - -typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_QueryDevicePointer */ - CARD16 sequenceNumber B16; - CARD32 length B32; - Window root B32; - Window child B32; - INT16 rootX B16; - INT16 rootY B16; - INT16 winX B16; - INT16 winY B16; - CARD16 mask B16; - BYTE sameScreen; - CARD8 deviceid; - CARD32 pad0 B32; -} xQueryDevicePointerReply; - - -/********************************************************** - * - * WarpDevicePointer. - * - */ - -typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_WarpDevicePointer */ - CARD16 length B16; - Window src_win B32; - Window dst_win B32; - INT16 src_x B16; - INT16 src_y B16; - CARD16 src_width B16; - CARD16 src_height B16; - INT16 dst_x B16; - INT16 dst_y B16; - CARD8 deviceid; - CARD8 pad0; - CARD16 pad1 B16; -} xWarpDevicePointerReq; - -/********************************************************** - * - * ChangeDeviceCursor. - * - */ - -typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_ChangeDeviceCursor */ - CARD16 length B16; - Window win B32; - Cursor cursor B32; - CARD8 deviceid; - CARD8 pad0; - CARD16 pad1; -} xChangeDeviceCursorReq; - -/********************************************************** - * - * ChangeDeviceHierarchy - * - */ - -typedef struct { - CARD8 reqType; /* input extension major code */ - CARD8 ReqType; /* always X_ChangeDeviceHierarchy */ - CARD16 length B16; - CARD8 num_changes; - CARD8 pad0; - CARD16 pad1 B16; -} xChangeDeviceHierarchyReq; - -typedef struct { - CARD16 type B16; - CARD16 length B16; /* in bytes */ -} xAnyHierarchyChangeInfo; - -/* Create a new master device. - * Name of new master follows struct (4-byte padded) - */ -typedef struct { - CARD16 type B16; /* Always CH_CreateMasterDevice */ - CARD16 length B16; /* 8 + (namelen + padding) */ - CARD16 namelen; - CARD8 sendCore; - CARD8 enable; -} xCreateMasterInfo; - -/* Delete a master device. Will automatically delete the master device paired - * with the given master device. - */ -typedef struct { - CARD16 type B16; /* Always CH_RemoveMasterDevice */ - CARD16 length B16; /* 8 */ - CARD8 deviceid; - CARD8 returnMode; /* AttachToMaster, Floating */ - CARD8 returnPointer; /* Pointer to attach slave ptr devices to */ - CARD8 returnKeyboard; /* keyboard to attach slave keybd devices to*/ -} xRemoveMasterInfo; - -/* Change a device's attachment. - * NewMaster has to be of same type (pointer->pointer, keyboard->keyboard); - */ -typedef struct { - CARD16 type B16; /* Always CH_ChangeAttachment */ - CARD16 length B16; /* 8 */ - CARD8 deviceid; - CARD8 changeMode; /* AttachToMaster, Floating */ - CARD8 newMaster; /* id of new master device */ - CARD8 pad0; -} xChangeAttachmentInfo; - - - -/********************************************************** - * - * SetClientPointer. - * - */ - -typedef struct { - CARD8 reqType; - CARD8 ReqType; /* Always X_SetClientPointer */ - CARD16 length B16; - Window win B32; - CARD8 deviceid; - CARD8 pad0; - CARD16 pad1 B16; -} xSetClientPointerReq; - - -/********************************************************** - * - * GetClientPointer. - * - */ -typedef struct { - CARD8 reqType; - CARD8 ReqType; /* Always X_GetClientPointer */ - CARD16 length B16; - Window win B32; -} xGetClientPointerReq; - -typedef struct { - CARD8 repType; /* input extension major opcode */ - CARD8 RepType; /* Always X_GetClientPointer */ - CARD16 sequenceNumber B16; - CARD32 length B32; - BOOL set; /* client pointer is set */ - CARD8 deviceid; - CARD16 pad0 B16; - CARD32 pad1 B32; - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; -} xGetClientPointerReply; - - -/********************************************************** - * - * XiSelectevent. - * - */ - -typedef struct { - CARD8 reqType; /* input extension major opcode */ - CARD8 ReqType; /* always X_XiSelectEvent */ - CARD16 length B16; - Window window B32; /* window to be changed */ - Mask mask B32; /* mask to be applied */ - CARD8 deviceid; - CARD8 pad0; - CARD16 pad1 B16; -} xXiSelectEventReq; - - -/************************************************************ - * - * ExtendedGrabDevice. - * - * This is a grab request to acommodate GE events. - * Event is followed by (event_count * XEventClass) bytes, followed by - * (ge_event_masks * GenericEventMask) bytes. - * - */ - -typedef struct { - CARD8 reqType; /* input extension major opcode */ - CARD8 ReqType; /* always X_ExtendedGrabDevice */ - CARD16 length B16; - CARD32 grab_window B32; - Time time B32; - CARD8 deviceid; - CARD8 device_mode; /* GrabModeSync or GrabModeAsync */ - BOOL owner_events; - CARD8 pad0; - Window confine_to B32; - Cursor cursor B32; - CARD16 event_count B16; - CARD16 generic_event_count B16; -} xExtendedGrabDeviceReq; - -typedef struct { - CARD8 repType; /* X_Reply */ - CARD8 RepType; /* always X_ExtendedGrabDevice */ - CARD16 sequenceNumber B16; - CARD32 length B32; /* 0 */ - CARD8 status; - BYTE pad1, pad2, pad3; - CARD32 pad01 B32; - CARD32 pad02 B32; - CARD32 pad03 B32; - CARD32 pad04 B32; - CARD32 pad05 B32; -} xExtendedGrabDeviceReply; - /********************************************************** * @@ -1980,34 +1727,6 @@ typedef struct } devicePresenceNotify; -/********************************************************** - * - * deviceEnterNotify. - * This has a slightly different layout than the core event. - * - */ - -typedef struct - { - BYTE type; - BYTE detail; - CARD16 sequenceNumber B16; - Time time B32; - Window root B32; - Window event B32; - Window child B32; - INT16 rootX B16; - INT16 rootY B16; - INT16 eventX B16; - INT16 eventY B16; - KeyButMask state B16; - BYTE mode; - CARD8 deviceid; - } deviceEnterNotify; - -typedef deviceEnterNotify deviceLeaveNotify; - - /********************************************************* * DevicePropertyNotifyEvent * @@ -2031,59 +1750,6 @@ typedef struct CARD8 deviceid; /* id of device */ } devicePropertyNotify; - - -/********************************************************* - * DeviceHierarchyChangedEvent. - * - * Intended as a notification event only, the client is expected to query the - * server for input devices after receipt of this event. - */ - -typedef struct - { - BYTE type; /* always GenericEvent */ - BYTE extension; /* XI extension offset */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD16 evtype B16; /* XI_DeviceHierarchyChangedNotify */ - CARD16 pad0 B16; - CARD32 time B32; - CARD32 pad2 B32; - CARD32 pad3 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; - } deviceHierarchyChangedEvent; - -/********************************************************* - * DeviceClassesChangedEvent - * - * Send whenever a master device changes classes (due to another slave device - * sending events). - * - * Event is followed by the same type of class list as used in the - * ListInputDevices request. - */ - -typedef struct - { - BYTE type; /* always GenericEvent */ - BYTE extension; /* XI extension offset */ - CARD16 sequenceNumber B16; - CARD32 length B32; - CARD16 evtype B16; /* XI_DeviceClassesChangedNotify */ - CARD8 deviceid; /* id of master */ - CARD8 new_slave; /* id of new slave */ - CARD32 time B32; - CARD8 num_classes; - CARD8 pad0; - CARD16 pad1 B16; - CARD32 pad2 B32; - CARD32 pad4 B32; - CARD32 pad5 B32; - } deviceClassesChangedEvent; - - #undef Window #undef Time #undef KeyCode From 1d933800acfa31f0a8f014224c1708f0076f3db0 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 3 Mar 2009 15:58:24 +1000 Subject: [PATCH 116/388] Move CH_* constants to xi2 --- XI.h | 7 ------- XI2.h | 6 ++++++ 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/XI.h b/XI.h index 2a885ea..727621a 100644 --- a/XI.h +++ b/XI.h @@ -274,13 +274,6 @@ SOFTWARE. #define DeviceUnrecoverable 4 #define DeviceControlChanged 5 - -/* ChangeHierarchy constants */ -#define CH_CreateMasterDevice 1 -#define CH_RemoveMasterDevice 2 -#define CH_AttachSlave 3 -#define CH_DetachSlave 4 - #define AttachToMaster 1 #define Floating 2 diff --git a/XI2.h b/XI2.h index f612759..ac6e0ed 100644 --- a/XI2.h +++ b/XI2.h @@ -39,6 +39,12 @@ #define HF_DeviceEnabled (1 << 6) #define HF_DeviceDisabled (1 << 7) +/* ChangeHierarchy constants */ +#define CH_CreateMasterDevice 1 +#define CH_RemoveMasterDevice 2 +#define CH_AttachSlave 3 +#define CH_DetachSlave 4 + /* Valuator modes */ #define ModeRelative 0 #define ModeAbsolute 1 From 2570457174fb951d3f5f725f87e8f7f45059158b Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 3 Mar 2009 16:13:05 +1000 Subject: [PATCH 117/388] Move AttachToMaster, Floating to XI2.h --- XI.h | 3 --- XI2.h | 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/XI.h b/XI.h index 727621a..93b5e34 100644 --- a/XI.h +++ b/XI.h @@ -274,9 +274,6 @@ SOFTWARE. #define DeviceUnrecoverable 4 #define DeviceControlChanged 5 -#define AttachToMaster 1 -#define Floating 2 - /* XI Errors */ #define XI_BadDevice 0 #define XI_BadEvent 1 diff --git a/XI2.h b/XI2.h index ac6e0ed..9c7a6b9 100644 --- a/XI2.h +++ b/XI2.h @@ -45,6 +45,9 @@ #define CH_AttachSlave 3 #define CH_DetachSlave 4 +#define AttachToMaster 1 +#define Floating 2 + /* Valuator modes */ #define ModeRelative 0 #define ModeAbsolute 1 From 069880638b1c2af821c6d84fde4119668c533063 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 3 Mar 2009 15:13:22 +1000 Subject: [PATCH 118/388] Move XI_2_Major/Minor to XI2.h --- XI.h | 3 --- XI2.h | 4 ++++ 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/XI.h b/XI.h index 93b5e34..c47713e 100644 --- a/XI.h +++ b/XI.h @@ -165,9 +165,6 @@ SOFTWARE. #define XI_Add_DeviceProperties_Major 1 #define XI_Add_DeviceProperties_Minor 5 -#define XI_2_Major 2 -#define XI_2_Minor 0 - #define DEVICE_RESOLUTION 1 #define DEVICE_ABS_CALIB 2 #define DEVICE_CORE 3 diff --git a/XI2.h b/XI2.h index 9c7a6b9..8a87d89 100644 --- a/XI2.h +++ b/XI2.h @@ -25,6 +25,10 @@ #ifndef _XI2_H_ #define _XI2_H_ +#define XI_2_Major 2 +#define XI_2_Minor 0 + + /* DeviceChangedEvent change reasons */ #define SlaveSwitch 1 #define DeviceChange 2 From 6c9785ea2581924fc748f61160a2faa4ab8eded0 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 3 Mar 2009 15:15:50 +1000 Subject: [PATCH 119/388] Remove IsFloating - we don't need this in XI 1.x anymore. --- XI.h | 1 - 1 file changed, 1 deletion(-) diff --git a/XI.h b/XI.h index c47713e..dca949c 100644 --- a/XI.h +++ b/XI.h @@ -183,7 +183,6 @@ SOFTWARE. #define XKEYBOARD 1 #define UseXKeyboard 0xFF -#define IsFloating (1 << 7) #define IsXPointer 0 #define IsXKeyboard 1 From 75daa0db2c87d065e80afdf248965f34f7073cd5 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 10 Apr 2009 14:17:02 +1000 Subject: [PATCH 120/388] Undef Window, Time, etc. after usage again to avoid pollution. Signed-off-by: Peter Hutterer --- XI2proto.h | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/XI2proto.h b/XI2proto.h index 5cad6da..ad628c6 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -672,4 +672,11 @@ typedef xXIEnterEvent xXILeaveEvent; typedef xXIEnterEvent xXIFocusInEvent; typedef xXIEnterEvent xXIFocusOutEvent; + +#undef Window +#undef Time +#undef KeyCode +#undef Mask +#undef Atom + #endif /* _XI2PROTO_H_ */ From d5105dc8516dd89cad0cd841081ff85d0a672bae Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 10 Apr 2009 14:17:51 +1000 Subject: [PATCH 121/388] We don't need to define KeyCode and Mask. Signed-off-by: Peter Hutterer --- XI2proto.h | 4 ---- 1 file changed, 4 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index ad628c6..0a2c2a3 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -41,8 +41,6 @@ /* make sure types have right sizes for protocol structures. */ #define Window CARD32 #define Time CARD32 -#define KeyCode CARD8 -#define Mask CARD32 #define Atom CARD32 /* Request opcodes */ @@ -675,8 +673,6 @@ typedef xXIEnterEvent xXIFocusOutEvent; #undef Window #undef Time -#undef KeyCode -#undef Mask #undef Atom #endif /* _XI2PROTO_H_ */ From 55ee1f97d446403b9c2ed2e3c321afa4d683c93f Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 10 Apr 2009 14:35:00 +1000 Subject: [PATCH 122/388] XI2proto.txt: fix typo Signed-off-by: Peter Hutterer --- XI2proto.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XI2proto.txt b/XI2proto.txt index 5faa730..8938017 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -79,7 +79,7 @@ If an event is generated by an SD - if the SD is attached to a master keyboard, it sends events to this keyboard's focus window (if applicable) and/or changes the modifier state of this keyboard. -- if the SD is not attached to an SD ("floating"), it does not change the +- if the SD is not attached to an SD ("floating"), it does not change any master device. The SD has its own (invisible) sprite and its own focus. Both the sprite and the focus must be managed explicitly by the client program. From 1956df7e45a49464dee2d7beff36f38ea00e9cb8 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 10 Apr 2009 14:56:20 +1000 Subject: [PATCH 123/388] Revert "Add major/minor version as supported by client to GetExtensionVersionReq." This reverts commit f6e41306f76de966884d4b72c5fb5e5d6d534ce4. Sending the supported version hidden in another request is potentially dangerous, so let's not do it. Signed-off-by: Peter Hutterer --- XIproto.h | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/XIproto.h b/XIproto.h index 21303ba..b7d0da0 100644 --- a/XIproto.h +++ b/XIproto.h @@ -169,10 +169,6 @@ struct tmask * * GetExtensionVersion. * - * For versioning support and to not break old clients, note that if nbytes is - * non-zero, majorVersion and minorVersion will be ignored. Otherwise, if - * nbytes is zero, majorVersion and minorVersion specify the version the - * client supports. */ typedef struct { @@ -180,8 +176,7 @@ typedef struct { CARD8 ReqType; /* always X_GetExtensionVersion */ CARD16 length B16; CARD16 nbytes B16; - CARD8 majorVersion; /* As supported by client if nbytes is 0 */ - CARD8 minorVersion; /* As supported by client if nbytes is 0 */ + CARD8 pad1, pad2; } xGetExtensionVersionReq; typedef struct { From 8914a9a2a99e334f66d6040d05b3d5f5b603780f Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 10 Apr 2009 17:31:05 +1000 Subject: [PATCH 124/388] Add GrabDevice and UngrabDevice XI2 requests. --- XI2proto.h | 57 ++++++++++++++++++++++++++++++++++++- XI2proto.txt | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++ XIproto.h | 2 +- 3 files changed, 136 insertions(+), 2 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index 0a2c2a3..58873bb 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -55,8 +55,10 @@ #define X_XIQueryDevice 48 #define X_XISetDeviceFocus 49 #define X_XIGetDeviceFocus 50 +#define X_XIGrabDevice 51 +#define X_XIUngrabDevice 52 -#define XI2REQUESTS (X_XIGetDeviceFocus - X_XIQueryDevicePointer + 1) +#define XI2REQUESTS (X_XIUngrabDevice - X_XIQueryDevicePointer + 1) #define XI2EVENTS (XI_LASTEVENT + 1) /************************************************************************************* @@ -488,6 +490,59 @@ typedef struct { } xXIGetDeviceFocusReply; #define sz_xXIGetDeviceFocusReply 32 + +/********************************************************** + * + * GrabDevice + * + */ +typedef struct { + uint8_t reqType; + uint8_t ReqType; /* Always X_XIGrabDevice */ + uint16_t length; + Window grab_window; + Time time; + Cursor cursor; + uint16_t deviceid; + uint8_t grab_mode; + uint8_t paired_device_mode; + uint8_t owner_events; + uint8_t pad; + uint16_t mask_len; +} xXIGrabDeviceReq; +#define sz_xXIGrabDeviceReq 24 + +typedef struct { + uint8_t repType; /* input extension major opcode */ + uint8_t RepType; /* Always X_XIGrabDevice */ + uint16_t sequenceNumber; + uint32_t length; + uint8_t status; + uint8_t pad0; + uint16_t pad1; + uint32_t pad2; + uint32_t pad3; + uint32_t pad4; + uint32_t pad5; + uint32_t pad6; +} xXIGrabDeviceReply; +#define sz_xXIGrabDeviceReply 32 + +/********************************************************** + * + * UngrabDevice + * + */ +typedef struct { + uint8_t reqType; + uint8_t ReqType; /* Always X_XIUngrabDevice */ + uint16_t length; + Time time; + uint16_t deviceid; + uint16_t pad; +} xXIUngrabDeviceReq; +#define sz_xXIUngrabDeviceReq 12 + /************************************************************************************* * * * EVENTS * diff --git a/XI2proto.txt b/XI2proto.txt index 8938017..4fbc716 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -624,6 +624,85 @@ XI2. Clients should ignore this data. Return the current focus window for the given device. + ┌─── + XIGrabDevice + deviceid: DEVICEID + grab-window: Window + owner-events: BOOL + grab-mode: { Synchronous, Asynchronous } + paired-device-mode: { Synchronous, Asynchronous } + time: TIMESTAMP or CurrentTime + mask_len: CARD16 + masks: SETofEVENTMASK + ▶ + status: Success, AlreadyGrabbed, Frozen, InvalidTime, NotViewable + └─── + + This request actively grabs control of the specified input device. Further + input evens from this device are reported only to the grabbing client. + This request overides any previous active grab by this client for this + device. + + The masks parameter specifies which events the client wishes to receive + while the device is grabbed. + + If owner-events is False, input events generated from this device are + reported with respect to grab-window, and are only reported if selected by + being included in the event-list. If owner-events is True, then if a + generated event would normally be reported to this client, it is reported + normally, otherwise the event is reported with respect to the grab-window, + and is only reported if selected by being included in the event-list. For + either value of owner-events, unreported events are discarded. + + If grab-mode is Asynchronous, device event processing continues normally. + If the device is currently frozen by this client, then processing of + device events is resumed. If grab-mode is Synchronous, the state of the + grabbed device (as seen by means of the protocol) appears to freeze, + and no further device events are 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. + + If the device is a slave device, the paired-device-mode is ignored. + Otherwise, if this device is a master device and paired-device-mode is + Asynchronous, event processing is unaffected by activation of the grab. If + this device is a master device and paired-device-mode is Synchronous, the + state of the master device paired with this device (as seen by means of the + protocol) appears to freeze, and no further events are generated by the + server until the grabbing client issues a releasing XIAllowEvents request + or until the device grab is released. Actual events are not lost while the + devices are frozen; they are simply queued for later processing. + + This request fails and returns: + AlreadyGrabbed: If the device is actively grabbed by some other client. + NotViewable: If grab-window is not viewable. + InvalidTime: If the specified time is earlier than the last-grab-time for + the specified device or later than the current X server time. + Otherwise, the last-grab-time for the specified device is set + to the specified time and CurrentTime is replaced by the + current X server time. + Frozen: If the device is frozen by an active grab of another client. + + To release a grab of an extension device, use UngrabDevice. + + ┌─── + XIUngrabDevice + deviceid: DEVICEID + time: TIMESTAMP or CurrentTime + └─── + + Errors: Device + + This request releases the device if this client has it actively grabbed + (from either XIGrabDevice, XIGrabDeviceKey or XIGrabDeviceButton) and + releases any queued events. If any devices were frozen by the grab, + XIUngrabDevice thaws them. + + The request has no effect if the specified time is earlier + than the last-device-grab time or is later than the current server time. + This request generates DeviceFocusIn and DeviceFocusOut events. + An XIUngrabDevice is performed automatically if the event window for an + active device grab becomes not viewable. 8. Events: diff --git a/XIproto.h b/XIproto.h index b7d0da0..2561eeb 100644 --- a/XIproto.h +++ b/XIproto.h @@ -73,7 +73,7 @@ SOFTWARE. #define IEVENTS 17 /* does NOT include generic events */ #define IERRORS 5 -#define IREQUESTS 48 +#define IREQUESTS 39 #define CLIENT_REQ 1 From 3c273d7145ed5f53b54d2812ad2ac8430d449555 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Sun, 19 Apr 2009 21:33:42 +1000 Subject: [PATCH 125/388] Change FP1616 into a single int32_t. --- XI2proto.h | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index 58873bb..da41df2 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -67,11 +67,7 @@ * * *************************************************************************************/ /* Fixed point 16.16 */ -typedef struct -{ - int16_t integral; - uint16_t frac; -} FP1616; +typedef int32_t FP1616; /* Fixed point 32.32 */ typedef struct { From 3380ae0ac0220c7f8fea9df855113819b472a233 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 16 Apr 2009 11:37:20 +1000 Subject: [PATCH 126/388] Add XIAllowEvents. Basically the same as the core protocol AllowEvents. --- XI2.h | 7 +++++ XI2proto.h | 20 +++++++++++- XI2proto.txt | 86 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 112 insertions(+), 1 deletion(-) diff --git a/XI2.h b/XI2.h index 8a87d89..e50db00 100644 --- a/XI2.h +++ b/XI2.h @@ -28,6 +28,13 @@ #define XI_2_Major 2 #define XI_2_Minor 0 +/* XIAllowEvents event-modes */ +#define AsyncDevice 0 +#define SyncDevice 1 +#define ReplayDevice 2 +#define AsyncPairedDevice 3 +#define AsyncPair 4 +#define SyncPair 5 /* DeviceChangedEvent change reasons */ #define SlaveSwitch 1 diff --git a/XI2proto.h b/XI2proto.h index da41df2..4206d2d 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -57,8 +57,9 @@ #define X_XIGetDeviceFocus 50 #define X_XIGrabDevice 51 #define X_XIUngrabDevice 52 +#define X_XIAllowEvents 53 -#define XI2REQUESTS (X_XIUngrabDevice - X_XIQueryDevicePointer + 1) +#define XI2REQUESTS (X_XIAllowEvents - X_XIQueryDevicePointer + 1) #define XI2EVENTS (XI_LASTEVENT + 1) /************************************************************************************* @@ -539,6 +540,23 @@ typedef struct { } xXIUngrabDeviceReq; #define sz_xXIUngrabDeviceReq 12 + +/********************************************************** + * + * AllowEvents + * + */ +typedef struct { + uint8_t reqType; + uint8_t ReqType; /* Always X_XIAllowEvents */ + uint16_t length; + Time time; + uint16_t deviceid; + uint8_t mode; + uint8_t pad; +} xXIAllowEventsReq; +#define sz_xXIAllowEventsReq 12 + /************************************************************************************* * * * EVENTS * diff --git a/XI2proto.txt b/XI2proto.txt index 4fbc716..cbf0ef7 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -704,6 +704,92 @@ XI2. Clients should ignore this data. An XIUngrabDevice is performed automatically if the event window for an active device grab becomes not viewable. + ┌─── + XIAllowEvents: + deviceid: DEVICEID + time: TIMESTAMP or CurrentTime + event-mode: { AsyncDevice, SyncDevice, + AsyncPairedDevice, SyncPairedDevice, + ReplayDevice, AsyncPair, SyncPair } + └─── + + Errors: Device, Value + + The AllowDeviceEvents request releases some queued events if the client + has caused a device to freeze. 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 following describes the processing that occurs depending on what constant + you pass to the event-mode argument: + AsyncDevice: + If the specified device is frozen by the client, event processing for that + device continues as usual. If the device is frozen multiple times by the + client on behalf of multiple separate grabs, AsyncThisDevice thaws for + all. + AsyncDevice has no effect if the specified device is not frozen by the + client, but the device need not be grabbed by the client. + SyncDevice: + If the specified device is frozen and actively grabbed by the client, + event processing for that device continues normally until the next + event is reported to the client. At this time, the specified device + again appears to freeze. However, if the reported event causes the + grab to be released, the specified device does not freeze. + SyncDevice has no effect if the specified device is not frozen by the + client or is not grabbed by the client. + ReplayDevice: + If the specified device is actively grabbed by the client and is frozen + as the result of an event having been sent to the client (either from + the activation of a XIGrabButton or from a previous XIAllowEvents with + mode SyncDevice, but not from a Grab), the grab is released and + that event is completely reprocessed. This time, however, the request + ignores any passive grabs at or above (towards the root) the + grab-window of the grab just released. + The request has no effect if the specified device is not grabbed by + the client or if it is not frozen as the result of an event. + AsyncPairedDevice + If the paired master device is frozen by the client, event processing + for it continues as usual. If the paired device is frozen multiple + times by the client on behalf of multiple separate grabs, + AsyncPairedDevice thaws for all. + AsyncPairedDevice has no effect if the device is not frozen by the + client, but those devices need not be grabbed by the client. + AsyncPairedDevice has no effect if deviceid specifies a slave device. + SyncPairedDevice + If the paired master device is frozen by the client, event processing (for + the paired master device) continues normally until the next button or key + event is reported to the client for the grabbed device (button event for + the grabbed device, key or motion event for the device), at which time + the device again appears to freeze. However, if the reported event causes + the grab to be released, then the device does not freeze. + SyncPairedDevice has no effect if the specified device is not grabbed + by the client or if it is no frozen as the result of an event. + SyncPairedDevice has no effect if deviceid specifies a slave device. + SyncPair + If both the device and the paired master device are frozen by the + client, event processing (for both devices) continues normally until + the next XIButtonPress, XIButtonRelease, XIKeyPress, or XIKeyRelease + event is reported to the client for a grabbed device (button event for + a pointer, key event for a keyboard), at which time the devices again + appear to freeze. However, if the reported event causes the grab to be + released, then the devices do not freeze (but if the other device is + still grabbed, then a subsequent event for it will still cause both + devices to freeze). + SyncPair has no effect unless both the device and the paired master + device are frozen by the client. If the device or paired master device + is frozen twice by the client on behalf of two separate grabs, + SyncPair thaws for both (but a subsequent freeze for SyncPair will + only freeze each device once). + SyncPair has no effect if deviceid specifies a slave device. + AsyncPair + If the device and the paired master device are frozen by the client, + event processing for both devices continues normally. If a device is + frozen twice by the client on behalf of two separate grabs, AsyncBoth + 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. + 8. Events: An event specifies its length in 4-byte units after the initial 32 bytes. From 589dc6ffa509c1c7da2d94dc89b2246c3dfdc81d Mon Sep 17 00:00:00 2001 From: "Paul \"TBBle\" Hampson" Date: Wed, 22 Apr 2009 09:00:14 +1000 Subject: [PATCH 127/388] Fix typo in XI2proto.txt Signed-off-by: Peter Hutterer --- XI2proto.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/XI2proto.txt b/XI2proto.txt index cbf0ef7..9cacd18 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -79,7 +79,7 @@ If an event is generated by an SD - if the SD is attached to a master keyboard, it sends events to this keyboard's focus window (if applicable) and/or changes the modifier state of this keyboard. -- if the SD is not attached to an SD ("floating"), it does not change +- if the SD is not attached to an MD ("floating"), it does not change any master device. The SD has its own (invisible) sprite and its own focus. Both the sprite and the focus must be managed explicitly by the client program. @@ -639,7 +639,7 @@ XI2. Clients should ignore this data. └─── This request actively grabs control of the specified input device. Further - input evens from this device are reported only to the grabbing client. + 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. @@ -715,7 +715,7 @@ XI2. Clients should ignore this data. Errors: Device, Value - The AllowDeviceEvents request releases some queued events if the client + The XIAllowEvents request releases some queued events if the client has caused a device to freeze. 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 @@ -726,7 +726,7 @@ XI2. Clients should ignore this data. AsyncDevice: If the specified device is frozen by the client, event processing for that device continues as usual. If the device is frozen multiple times by the - client on behalf of multiple separate grabs, AsyncThisDevice thaws for + client on behalf of multiple separate grabs, AsyncDevice thaws for all. AsyncDevice has no effect if the specified device is not frozen by the client, but the device need not be grabbed by the client. From 6d28cb22ada7a1abb6ab11863c82c9834d1a4b00 Mon Sep 17 00:00:00 2001 From: Benjamin Close Date: Wed, 22 Apr 2009 13:10:50 +0930 Subject: [PATCH 128/388] Define the Cursor datasize correctly On 64 bit machines, without Cursor defined Xlib would allocate 64 bits rather than 32 to any structs using Cursor. This led to data not correctly being available on the wire hence the Xserver would do strange things. We hence define Cursor to what it should be and make sure we undefine it after we've finished to users of XIproto.h aren't affected Fix-by: Peter Hutterer Signed-off-by: Benjamin Close Signed-off-by: Peter Hutterer --- XIproto.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/XIproto.h b/XIproto.h index 2561eeb..e00ab61 100644 --- a/XIproto.h +++ b/XIproto.h @@ -56,6 +56,7 @@ SOFTWARE. #define KeyCode CARD8 #define Mask CARD32 #define Atom CARD32 +#define Cursor CARD32 /********************************************************* * @@ -1750,5 +1751,6 @@ typedef struct #undef KeyCode #undef Mask #undef Atom +#undef Cursor #endif From 5d60550fdeb375a88ac9da42bcad4ee69b0df64a Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Sat, 25 Apr 2009 10:43:43 +1000 Subject: [PATCH 129/388] XI2 spec: Add some more Grab/Ungrab/AllowEvents documentation. --- XI2proto.txt | 66 +++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 52 insertions(+), 14 deletions(-) diff --git a/XI2proto.txt b/XI2proto.txt index 9cacd18..38a3a5d 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -627,11 +627,12 @@ XI2. Clients should ignore this data. ┌─── XIGrabDevice deviceid: DEVICEID - grab-window: Window - owner-events: BOOL - grab-mode: { Synchronous, Asynchronous } - paired-device-mode: { Synchronous, Asynchronous } + grab_window: Window + owner_events: BOOL + grab_mode: { Synchronous, Asynchronous } + paired_device_mode: { Synchronous, Asynchronous } time: TIMESTAMP or CurrentTime + cursor: Cursor mask_len: CARD16 masks: SETofEVENTMASK ▶ @@ -643,6 +644,30 @@ XI2. Clients should ignore this data. This request overides any previous active grab by this client for this device. + deviceid + The device to grab. + grab_window + Events are reported relative to the grab window. + owner_events + Specifies whether event will be reported normally or relative to the + grab window. + grab_mode + Specifies if this device will be frozen as a result of the grab. + paired_device_mode + Specifies if the master device paired with this device will be frozen + as a result of the grab. + time + A valid server time or CurrentTime. + cursor + The cursor to display for the duration of the grab or None. + mask_len + Length of mask in 4 byte units. + mask + Event mask. An event mask for an event type T is defined as (1 << T). + status + Success or the reason why the grab could not be established. + + The masks parameter specifies which events the client wishes to receive while the device is grabbed. @@ -673,6 +698,9 @@ XI2. Clients should ignore this data. or until the device grab is released. Actual events are not lost while the devices are frozen; they are simply queued for later processing. + If the cursor is not None and the device is a master pointer device, the + cursor will be displayed until the device is ungrabbed. + This request fails and returns: AlreadyGrabbed: If the device is actively grabbed by some other client. NotViewable: If grab-window is not viewable. @@ -683,7 +711,7 @@ XI2. Clients should ignore this data. current X server time. Frozen: If the device is frozen by an active grab of another client. - To release a grab of an extension device, use UngrabDevice. + To release a grab of a device, use XIUngrabDevice. ┌─── XIUngrabDevice @@ -691,13 +719,16 @@ XI2. Clients should ignore this data. time: TIMESTAMP or CurrentTime └─── - Errors: Device - This request releases the device if this client has it actively grabbed (from either XIGrabDevice, XIGrabDeviceKey or XIGrabDeviceButton) and releases any queued events. If any devices were frozen by the grab, XIUngrabDevice thaws them. + deviceid + The device to grab. + time + A valid server time or CurrentTime. + The request has no effect if the specified time is earlier than the last-device-grab time or is later than the current server time. This request generates DeviceFocusIn and DeviceFocusOut events. @@ -708,18 +739,25 @@ XI2. Clients should ignore this data. XIAllowEvents: deviceid: DEVICEID time: TIMESTAMP or CurrentTime - event-mode: { AsyncDevice, SyncDevice, + event_mode: { AsyncDevice, SyncDevice, AsyncPairedDevice, SyncPairedDevice, ReplayDevice, AsyncPair, SyncPair } └─── - Errors: Device, Value - The XIAllowEvents request releases some queued events if the client - has caused a device to freeze. 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. + has caused a device to freeze. + + deviceid + The device to grab. + time + A valid server time or CurrentTime. + event_mode + Specifies whether a device is to be thawed and events are to be + replayed. + + 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 following describes the processing that occurs depending on what constant you pass to the event-mode argument: From 504b480c946fe4c4a96500ef8c5da100b787ab32 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Sat, 25 Apr 2009 11:08:21 +1000 Subject: [PATCH 130/388] XI2: add passive grabs. Most notably XI2 provides keysym grabs instead of keycode grabs. --- XI2.h | 7 +++ XI2proto.h | 67 ++++++++++++++++++++++++++- XI2proto.txt | 128 +++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 201 insertions(+), 1 deletion(-) diff --git a/XI2.h b/XI2.h index e50db00..0bb988d 100644 --- a/XI2.h +++ b/XI2.h @@ -28,6 +28,13 @@ #define XI_2_Major 2 #define XI_2_Minor 0 +/* Passive grab types */ +#define GrabtypeButton 0 +#define GrabtypeKeysym 1 + +/* Passive grab modifier */ +#define XIAnyModifier (1 << 31) + /* XIAllowEvents event-modes */ #define AsyncDevice 0 #define SyncDevice 1 diff --git a/XI2proto.h b/XI2proto.h index 4206d2d..7e87327 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -58,8 +58,10 @@ #define X_XIGrabDevice 51 #define X_XIUngrabDevice 52 #define X_XIAllowEvents 53 +#define X_XIPassiveGrabDevice 54 +#define X_XIPassiveUngrabDevice 55 -#define XI2REQUESTS (X_XIAllowEvents - X_XIQueryDevicePointer + 1) +#define XI2REQUESTS (X_XIPassiveUngrabDevice - X_XIQueryDevicePointer + 1) #define XI2EVENTS (XI_LASTEVENT + 1) /************************************************************************************* @@ -171,6 +173,15 @@ typedef struct { uint16_t mask_len; /**< Length of mask in 4 byte units */ } xXIDeviceEventMask; + + +typedef struct { + uint32_t modifiers; + uint8_t status; + uint8_t pad0; + uint16_t pad1; +} xXIGrabModifierInfo; + /************************************************************************************* * * * REQUESTS * @@ -557,6 +568,60 @@ typedef struct { } xXIAllowEventsReq; #define sz_xXIAllowEventsReq 12 + +/********************************************************** + * + * PassiveGrabDevice + * + */ +typedef struct { + uint8_t reqType; + uint8_t ReqType; /* Always X_XIPassiveGrabDevice */ + uint16_t length; + Time time; + Window grab_window; + Cursor cursor; + uint32_t detail; + uint16_t deviceid; + uint16_t num_modifiers; + uint16_t mask_len; + uint8_t grab_type; + uint8_t grab_mode; + uint8_t paired_device_mode; + uint8_t owner_events; + uint16_t pad1; +} xXIPassiveGrabDeviceReq; +#define sz_xXIPassiveGrabDeviceReq 32 + +typedef struct { + uint8_t repType; /* input extension major opcode */ + uint8_t RepType; /* Always X_XIPassiveGrabDevice */ + uint16_t sequenceNumber; + uint32_t length; + uint16_t num_modifiers; + uint16_t pad1; + uint32_t pad2; + uint32_t pad3; + uint32_t pad4; + uint32_t pad5; + uint32_t pad6; +} xXIPassiveGrabDeviceReply; +#define sz_xXIPassiveGrabDeviceReply 32 + +typedef struct { + uint8_t reqType; + uint8_t ReqType; /* Always X_XIPassiveUngrabDevice */ + uint16_t length; + Window grab_window; + uint32_t detail; + uint16_t deviceid; + uint16_t num_modifiers; + uint8_t grab_type; + uint8_t pad0; + uint16_t pad1; +} xXIPassiveUngrabDeviceReq; +#define sz_xXIPassiveUngrabDeviceReq 20 + /************************************************************************************* * * * EVENTS * diff --git a/XI2proto.txt b/XI2proto.txt index 38a3a5d..903ebe7 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -828,6 +828,134 @@ XI2. Clients should ignore this data. paired master device frozen by the client. AsyncPair has no effect if deviceid specifies a slave device. + ┌─── + XIPassiveGrabDevice + deviceid: DEVICEID + detail: CARD32 + grab_type: { GrabtypeButton, GrabtypeKeysym } + grab_window: Window + cursor: Cursor + owner_events: Bool + grab_mode: { Synchronous, Asynchronous } + paired_device_mode: { Synchronous, Asynchronous } + num_modifiers: INT16 + mask_len: CARD16 + masks: SETofEVENTMASK + modifiers: CARD32 or GrabAnyModifier + ▶ + num_modifiers_return: INT16 + modifiers_return: GRABMODIFIERINFO + └─── + + GRABMODIFIERINFO { status: Access + modifiers: CARD32 } + + Establish an explicit passive grab for a button or keycode or keysym + on the specified input device. + + cursor + The cursor to display for the duration of the grab. If grab_type + is not GrabtypeButton, this argument is ignored. + deviceid + The device to establish the passive grab on. + detail + The button number, or key symbol to grab for. + grab_type + The type of grab to establish. + grab_window + Events are reported relative to the grab window. + grab_mode + If grab-mode is Asynchronous, device event processing continues + normally. If the device is currently frozen by this client, then + processing of device events is resumed. If grab-mode is + Synchronous, the state of the grabbed device (as seen by means of + the protocol) appears to freeze, and no further device events are + 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. + mask_len + Length of mask in 4 byte units. + mask + Event mask. An event mask for an event type T is defined as (1 << T). + modifiers + XKB modifier state to activate this passive grab. + num_modifiers + Number of elements in modifiers. + owner_events + Specifies whether event will be reported normally or relative to the + grab window. + num_modifiers_return + Number of elements in modifiers_return + modifiers_return + XKB modifier state that could not be grabbed. + + If owner-events is False, input events generated from this device are + reported with respect to grab-window, and are only reported if + selected by being included in the event-list. If owner-events is + True, then if a generated event would normally be reported to this + client, it is reported normally, otherwise the event is reported + with respect to the grab-window, and is only reported if selected + by being included in the event-list. For either value of + owner-events, unreported events are discarded. + + In the future, the device is actively grabbed if: + - the device is not grabbed, and + - the specified modifier keys are down, and + - the grab_type is GrabtypeButton and the button specified in detail + is logically pressed or the grab_type is GrabtypeKeysym and the + keysym specified in detail is logically pressed, and + - the grab_window contains the pointer, and + - a passive grab on the same button/keycode/keysym + modifier + combination does not exist on an ancestor of grab_window. + + 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 + combinations in the same request. + + The grab is released when all buttons or keycodes or keysyms are + released, independent of the state of modifier keys. 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. + This request overrides all previous passive grabs by the same client + on the same button/key combinations on the same window. + + If some other client already has issued a XIPassiveGrabDevice request + with the same button/keycode/keysym and modifier combination, the + failed modifier combinations is returned in modifiers_return. If + num_modifiers_return is zero, all passive grabs have been successful. + + ┌─── + XIPassiveUngrabDevice + deviceid: DEVICEID + detail: CARD32 + grab_type: { ButtonGrab, KeycodeGrab, KeysymGrab } + grab_window: Window + num_modifiers: INT16 + modifiers: MODIFIERINFO + └─── + + Release an explicit passive grab for a button or keycode or keysym on + the specified input device. + + deviceid + The device to establish the passive grab on. + detail + The button number or key symbol to ungrab. + grab_type + The type of grab to establish. + grab_window + Events are reported relative to the grab window. + modifiers + XKB modifier state to activate this passive grab. + num_modifiers + Number of elements in modifiers. + + This request has no effect if the matching button/keycode/keysym and + modifier combination is not grabbed b this client. + + 8. Events: An event specifies its length in 4-byte units after the initial 32 bytes. From 2edc35c032c2792d9528a396f596d466d4f10764 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 6 May 2009 16:33:34 +1000 Subject: [PATCH 131/388] Add XI2 property requests. Basically the same as XI 1.5, save the 16 bit deviceids. --- XI2.h | 8 ++- XI2proto.h | 129 ++++++++++++++++++++++++++++++++++++++++- XI2proto.txt | 161 +++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 296 insertions(+), 2 deletions(-) diff --git a/XI2.h b/XI2.h index 0bb988d..4a62eb4 100644 --- a/XI2.h +++ b/XI2.h @@ -28,6 +28,10 @@ #define XI_2_Major 2 #define XI_2_Minor 0 +#define XIPropertyDeleted 0 +#define XIPropertyCreated 1 +#define XIPropertyModified 2 + /* Passive grab types */ #define GrabtypeButton 0 #define GrabtypeKeysym 1 @@ -108,7 +112,8 @@ #define XI_FocusOut 10 #define XI_HierarchyChanged 11 #define XI_RawEvent 12 -#define XI_LASTEVENT XI_RawEvent +#define XI_PropertyEvent 13 +#define XI_LASTEVENT XI_PropertyEvent /* Event masks. * Note: the protocol spec defines a mask to be of (1 << type). Clients are @@ -126,5 +131,6 @@ #define XI_FocusOutMask (1 << XI_FocusOut) #define XI_HierarchyChangedMask (1 << XI_HierarchyChanged) #define XI_RawEventMask (1 << XI_RawEvent) +#define XI_PropertyEventMask (1 << XI_PropertyEvent) #endif /* _XI2_H_ */ diff --git a/XI2proto.h b/XI2proto.h index 7e87327..14e75a7 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -60,8 +60,12 @@ #define X_XIAllowEvents 53 #define X_XIPassiveGrabDevice 54 #define X_XIPassiveUngrabDevice 55 +#define X_XIListProperties 56 +#define X_XIChangeProperty 57 +#define X_XIDeleteProperty 58 +#define X_XIGetProperty 59 -#define XI2REQUESTS (X_XIPassiveUngrabDevice - X_XIQueryDevicePointer + 1) +#define XI2REQUESTS (X_XIGetProperty - X_XIQueryDevicePointer + 1) #define XI2EVENTS (XI_LASTEVENT + 1) /************************************************************************************* @@ -622,6 +626,107 @@ typedef struct { } xXIPassiveUngrabDeviceReq; #define sz_xXIPassiveUngrabDeviceReq 20 +/********************************************************** + * + * XIListProperties + * + */ +typedef struct { + uint8_t reqType; + uint8_t ReqType; /* Always X_XIListProperties */ + uint16_t length; + uint16_t deviceid; + uint16_t pad; +} xXIListPropertiesReq; +#define sz_xXIListPropertiesReq 8 + +typedef struct { + uint8_t repType; /* input extension major opcode */ + uint8_t RepType; /* Always X_XIListProperties */ + uint16_t sequenceNumber; + uint32_t length; + uint16_t num_properties; + uint16_t pad0; + uint32_t pad1; + uint32_t pad2; + uint32_t pad3; + uint32_t pad4; + uint32_t pad5; +} xXIListPropertiesReply; +#define sz_xXIListPropertiesReply 32 + +/********************************************************** + * + * XIChangeDeviceProperty + * + */ +typedef struct { + uint8_t reqType; + uint8_t ReqType; /* Always X_XIChangeProperty */ + uint16_t length; + uint16_t deviceid; + uint8_t mode; + uint8_t format; + Atom property; + Atom type; + uint32_t num_items; +} xXIChangePropertyReq; +#define sz_xXIChangePropertyReq 20 + +/********************************************************** + * + * XIDeleteProperty + * + */ +typedef struct { + uint8_t reqType; + uint8_t ReqType; /* Always X_XIDeleteProperty */ + uint16_t length; + uint16_t deviceid; + uint16_t pad0; + Atom property; +} xXIDeletePropertyReq; +#define sz_xXIDeletePropertyReq 12 + +/********************************************************** + * + * XIGetProperty + * + */ +typedef struct { + uint8_t reqType; + uint8_t ReqType; /* Always X_XIGetProperty */ + uint16_t length; + uint16_t deviceid; +#if defined(__cplusplus) || defined(c_plusplus) + uint8_t c_delete; +#else + uint8_t delete; +#endif + uint8_t pad0; + Atom property; + Atom type; + uint32_t offset; + uint32_t len; +} xXIGetPropertyReq; +#define sz_xXIGetPropertyReq 24 + +typedef struct { + uint8_t repType; /* input extension major opcode */ + uint8_t RepType; /* Always X_XIGetProperty */ + uint16_t sequenceNumber; + uint32_t length; + Atom type; + uint32_t bytes_after; + uint32_t num_items; + uint8_t format; + uint8_t pad0; + uint16_t pad1; + uint32_t pad2; + uint32_t pad3; +} xXIGetPropertyReply; +#define sz_xXIGetPropertyReply 32 + /************************************************************************************* * * * EVENTS * @@ -804,6 +909,28 @@ typedef xXIEnterEvent xXILeaveEvent; typedef xXIEnterEvent xXIFocusInEvent; typedef xXIEnterEvent xXIFocusOutEvent; +/*********************************************************** + * PropertyEvents + * + */ + +typedef struct +{ + uint8_t type; /* always GenericEvent */ + uint8_t extension; /* XI extension offset */ + uint16_t sequenceNumber; + uint32_t length; + uint16_t evtype; /* XI_PropertyEvent */ + uint16_t deviceid; + Time time; + Atom property; + uint8_t what; + uint8_t pad0; + uint16_t pad1; + uint32_t pad2; + uint32_t pad3; +} xXIPropertyEvent; + #undef Window #undef Time diff --git a/XI2proto.txt b/XI2proto.txt index 903ebe7..be27a92 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -955,6 +955,151 @@ XI2. Clients should ignore this data. This request has no effect if the matching button/keycode/keysym and modifier combination is not grabbed b this client. + ┌─── + XIListProperties + deviceid: DEVICEID + ▶ + num_properties: INT16 + properties: LISTofATOM + └─── + + List the properties associated with the given device. + + deviceid + The device to list the properties for. + num_atoms + Number of atoms in the reply + atoms + All properties on the device. + + ┌─── + XIChangeProperty + deviceid: DEVICEID + property: ATOM + type: ATOM + format: { 8, 16, 32 } + mode: { Append, Prepend, Replace } + num_items: CARD32 + data: LISTofINT8, or LISTofINT16, or LISTofINT32 + └─── + + Change the given property on the given device. + + deviceid + The device to change the property on. + property + The property to modify. + type + The property's type. + mode + One of Append, Prepend, or Replace + num_items + Number of items following this request. + data + Property data (nitems * format/8 bytes) + + The type is uninterpreted by the server. The format specifies whether + the data should be viewed as a list of 8-bit, 16-bit, or 32-bit + quantities so that the server can correctly byte-swap as necessary. + + If the mode is Replace, the previous propert y value is discarded. If + the mode is Prepend or Append, then the type and format must match the + existing property value (or a Match error results). If the property is + undefined, it is treated as defined with the correct type and format + with zero-length data. For Prepend, the data is tacked on to the + beginning of the existing data, and for Append, it is tacked on to the + end of the existing data. + + The lifetime of a property is not tied to the storing client. Properties + remain until explicitly deleted, until the device is removed, or + until server reset. + + A property cannot be deleted by setting nitems to zero. To delete a + property, use XIDeleteDeviceProperty. + + This request generates an XIPropertyEvent. + + ┌─── + XIDeleteProperty + deviceid: DEVICEID + property: ATOM + └─── + + Deletes the given property on the given device. + + deviceid + The device to delete the property on. + property + The property to delete. + + If the property is deleted, an XIPropertyEvent is generated on the device. + If the property does not exist, this request does nothing. + + ┌─── + XIGetProperty + deviceid: DEVICEID + property: ATOM + type: Atom or AnyPropertyType + offset: CARD32 + len: CARD32 + delete: BOOL + ▶ + type: Atom + bytes_after: CARD32 + num_items: CARD32 + format: { 8, 16, 32 } + data: LISTofINT8, or LISTofINT16, or LISTofINT32 + └─── + + Get the data for the given property on the given device. + + deviceid + The device to retrieve the property data from. + property + The property to retrieve the data from.. + type + The property type to retrieve or AnyPropertyType + offset + The offset in 4-byte units. + len + Number of bytes to receive in 4-byte units. + delete + Delete the property after retrieving the data. + bytes_after + Number of unread bytes in the stored property + num_items + Number of items in data + format + 8, 16, or 32 + data + Property data (nitems * format/8 bytes) + + If the specified property does not exist for the specified device, then + the return type is None, the format and bytes-after are zero, and the value is + empty. The delete argument is ignored in this case. If the specified property + exists but its type does not match the specified type, then the return + type is the actual type of the property, the format is the actual format of the + property (never zero), the bytes-after is the length of the property in bytes + (even if the format is 16 or 32), and the value is empty. The delete + argument is ignored in this case. If the specified property exists and + 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: @@ -1283,4 +1428,20 @@ EVENTHEADER { type: BYTE buttons Button state before the event. + ┌─── + XIPropertyEvent + EVENTHEADER + property: ATOM + what: { PropertyCreated, PropertyDeleted, PropertyModified } + └─── + + XIPropertyEvents are sent whenever a device property is created, deleted or + modified by a client. + + property + The property that has been created, deleted, or modified + what + Specifies what has been changed. + + ❧❧❧❧❧❧❧❧❧❧❧ From a47a2b50845499e3f9144739db5644952faf8ea2 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 7 May 2009 16:19:47 +1000 Subject: [PATCH 132/388] Prefix all XI2 constants with "XI" -> inputproto 1.99.9.8 Signed-off-by: Peter Hutterer --- XI2.h | 87 ++++++++++++++++++++++++---------------------------- configure.ac | 2 +- 2 files changed, 41 insertions(+), 48 deletions(-) diff --git a/XI2.h b/XI2.h index 4a62eb4..f686168 100644 --- a/XI2.h +++ b/XI2.h @@ -28,76 +28,69 @@ #define XI_2_Major 2 #define XI_2_Minor 0 -#define XIPropertyDeleted 0 -#define XIPropertyCreated 1 -#define XIPropertyModified 2 +#define XIPropertyDeleted 0 +#define XIPropertyCreated 1 +#define XIPropertyModified 2 /* Passive grab types */ -#define GrabtypeButton 0 -#define GrabtypeKeysym 1 +#define XIGrabtypeButton 0 +#define XIGrabtypeKeysym 1 /* Passive grab modifier */ #define XIAnyModifier (1 << 31) /* XIAllowEvents event-modes */ -#define AsyncDevice 0 -#define SyncDevice 1 -#define ReplayDevice 2 -#define AsyncPairedDevice 3 -#define AsyncPair 4 -#define SyncPair 5 +#define XIAsyncDevice 0 +#define XISyncDevice 1 +#define XIReplayDevice 2 +#define XIAsyncPairedDevice 3 +#define XIAsyncPair 4 +#define XISyncPair 5 /* DeviceChangedEvent change reasons */ -#define SlaveSwitch 1 -#define DeviceChange 2 +#define XISlaveSwitch 1 +#define XIDeviceChange 2 /* Hierarchy flags */ -#define HF_MasterAdded (1 << 0) -#define HF_MasterRemoved (1 << 1) -#define HF_SlaveAdded (1 << 2) -#define HF_SlaveRemoved (1 << 3) -#define HF_SlaveAttached (1 << 4) -#define HF_SlaveDetached (1 << 5) -#define HF_DeviceEnabled (1 << 6) -#define HF_DeviceDisabled (1 << 7) +#define XIMasterAdded (1 << 0) +#define XIMasterRemoved (1 << 1) +#define XISlaveAdded (1 << 2) +#define XISlaveRemoved (1 << 3) +#define XISlaveAttached (1 << 4) +#define XISlaveDetached (1 << 5) +#define XIDeviceEnabled (1 << 6) +#define XIDeviceDisabled (1 << 7) /* ChangeHierarchy constants */ -#define CH_CreateMasterDevice 1 -#define CH_RemoveMasterDevice 2 -#define CH_AttachSlave 3 -#define CH_DetachSlave 4 +#define XICreateMasterDevice 1 +#define XIRemoveMasterDevice 2 +#define XIAttachSlave 3 +#define XIDetachSlave 4 -#define AttachToMaster 1 -#define Floating 2 +#define XIAttachToMaster 1 +#define XIFloating 2 /* Valuator modes */ -#define ModeRelative 0 -#define ModeAbsolute 1 +#define XIModeRelative 0 +#define XIModeAbsolute 1 /* Device types */ -#define MasterPointer 1 -#define MasterKeyboard 2 -#define SlavePointer 3 -#define SlaveKeyboard 4 -#define FloatingSlave 5 +#define XIMasterPointer 1 +#define XIMasterKeyboard 2 +#define XISlavePointer 3 +#define XISlaveKeyboard 4 +#define XIFloatingSlave 5 /* Device classes */ -/* These may be defined if XI.h is included first */ -#ifndef KeyClass -#define KeyClass 0 -#endif -#ifndef ButtonClass -#define ButtonClass 1 -#endif -#ifndef ValuatorClass -#define ValuatorClass 2 -#endif +#define XIKeyClass 0 +#define XIButtonClass 1 +#define XIValuatorClass 2 /* XI2 mask macro */ -#define XIMASK(event) (1 << (event)) +#define XIMASK(event) (1 << (event)) -#define AllDevices 0 -#define AllMasterDevices 1 +#define XIAllDevices 0 +#define XIAllMasterDevices 1 /* Event types */ #define XI_DeviceChanged 1 diff --git a/configure.ac b/configure.ac index 8fc5357..4036868 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.7], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.8], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) # Require xorg-macros: XORG_CHANGELOG From e9dfa4015520abd49779e96e7d54da763a54484b Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 11 May 2009 13:46:53 +1000 Subject: [PATCH 133/388] XI2proto.h: s/uint32_t/Time/ where appropriate --- XI2proto.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index 14e75a7..c90ada0 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -741,7 +741,7 @@ typedef struct uint32_t length; uint16_t evtype; uint16_t deviceid; - uint32_t time; + Time time; } xXIGenericDeviceEvent; /*********************************************************** @@ -765,7 +765,7 @@ typedef struct uint32_t length; uint16_t evtype; /* XI_Hierarchy */ uint16_t deviceid; - uint32_t time; + Time time; uint32_t flags; /* MasterAdded, MasterDeleted, SlaveAttached, SlaveDetached, SlaveAdded, SlaveRemoved, @@ -789,7 +789,7 @@ typedef struct uint32_t length; uint16_t evtype; /* XI_DeviceChanged */ uint16_t deviceid; /* id of master */ - uint32_t time; + Time time; uint16_t num_classes; /* classes that have changed */ uint16_t sourceid; /* Source for the new classes*/ uint8_t reason; /* SlaveSwitch, DeviceChange */ From 32277164bcff6b18a498f12886828187e1f96249 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 11 May 2009 14:35:35 +1000 Subject: [PATCH 134/388] XI2proto.h: doxygen-ify --- XI2.h | 1 + XI2proto.h | 552 ++++++++++++++++++++++++++++------------------------- 2 files changed, 293 insertions(+), 260 deletions(-) diff --git a/XI2.h b/XI2.h index f686168..d0b56b8 100644 --- a/XI2.h +++ b/XI2.h @@ -28,6 +28,7 @@ #define XI_2_Major 2 #define XI_2_Minor 0 +/* Property event flags */ #define XIPropertyDeleted 0 #define XIPropertyCreated 1 #define XIPropertyModified 2 diff --git a/XI2proto.h b/XI2proto.h index c90ada0..e3a5101 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -22,10 +22,13 @@ * */ +/** + * @mainpage + * @include XI2proto.txt + */ /** * @file XI2proto.h * Protocol definitions for the XI2 protocol. - * * This file should not be included by clients that merely use XI2, but do not * need the wire protocol. Such clients should include XI2.h, or the matching * header from the library. @@ -43,7 +46,11 @@ #define Time CARD32 #define Atom CARD32 -/* Request opcodes */ +/** + * XI2 Request opcodes + * @addtogroup XI2Requests + * @{ + */ #define X_XIQueryDevicePointer 40 #define X_XIWarpDevicePointer 41 #define X_XIChangeDeviceCursor 42 @@ -64,8 +71,11 @@ #define X_XIChangeProperty 57 #define X_XIDeleteProperty 58 #define X_XIGetProperty 59 +/*@}*/ +/** Number of XI requests */ #define XI2REQUESTS (X_XIGetProperty - X_XIQueryDevicePointer + 1) +/** Number of XI2 events */ #define XI2EVENTS (XI_LASTEVENT + 1) /************************************************************************************* @@ -73,27 +83,32 @@ * COMMON STRUCTS * * * *************************************************************************************/ -/* Fixed point 16.16 */ +/** Fixed point 16.16 */ typedef int32_t FP1616; -/* Fixed point 32.32 */ +/** Fixed point 32.32 */ typedef struct { int32_t integral; uint32_t frac; } FP3232; /** + * \struct xXIDeviceInfo * Struct to describe a device. * - * For a MasterPointer or a MasterKeyboard, 'attachment' desviced + * For a MasterPointer or a MasterKeyboard, 'attachment' specifies the + * paired master device. + * For a SlaveKeyboard or SlavePointer, 'attachment' specifies the master + * device this device is attached to. + * For a FloatingSlave, 'attachment' is undefined. * - * @see XIQueryDevices + * @see xXIQueryDeviceReq */ typedef struct { uint16_t deviceid; - uint16_t use; /**< ::MasterPointer, ::MasterKeyboard, - ::SlavePointer, ::SlaveKeyboard, - ::FloatingSlave */ + uint16_t use; /**< ::XIMasterPointer, ::XIMasterKeyboard, + ::XISlavePointer, ::XISlaveKeyboard, + ::XIFloatingSlave */ uint16_t attachment; /**< Current attachment or pairing.*/ uint16_t num_classes; /**< Number of classes following this struct. */ uint16_t name_len; /**< Length of name in bytes. */ @@ -102,12 +117,13 @@ typedef struct { } xXIDeviceInfo; /** + * \struct xXIAnyInfo * Default template for a device class. * A device class is equivalent to a device's capabilities. Multiple classes * are supported per device. * - * @see XIQueryDevices - * @see XIDeviceChangedEvent + * @see xXIQueryDeviceReq + * @see xXIDeviceChangedEvent */ typedef struct { uint16_t type; /**< One of *class */ @@ -119,8 +135,8 @@ typedef struct { * Struct is followed by num_buttons * Atom that names the buttons in the * device-native setup (i.e. ignoring button mappings). * - * @see XIQueryDevices - * @see XIDeviceChangedEvent + * @see xXIQueryDeviceReq + * @see xXIDeviceChangedEvent */ typedef struct { uint16_t type; /**< Always ButtonClass */ @@ -134,8 +150,8 @@ typedef struct { * Struct is followed by num_keys * CARD32 that lists the keycodes available * on the device. * - * @see XIQueryDevices - * @see XIDeviceChangedEvent + * @see xXIQueryDeviceReq + * @see xXIDeviceChangedEvent */ typedef struct { uint16_t type; /**< Always KeyClass */ @@ -148,12 +164,12 @@ typedef struct { * Denotes an valuator capability on a device. * One XIValuatorInfo describes exactly one valuator (axis) on the device. * - * @see XIQueryDevices - * @see XIDeviceChangedEvent + * @see xXIQueryDevice + * @see xXIDeviceChangedEvent */ typedef struct { uint16_t type; /**< Always ValuatorClass */ - uint16_t length; /**< Length in 4 byte units */ + uint16_t length; /**< Length in 4 byte units */ Atom name; /**< Valuator name */ FP3232 min; /**< Min value */ FP3232 max; /**< Max value */ @@ -179,37 +195,29 @@ typedef struct { -typedef struct { - uint32_t modifiers; - uint8_t status; - uint8_t pad0; - uint16_t pad1; -} xXIGrabModifierInfo; - /************************************************************************************* * * * REQUESTS * * * *************************************************************************************/ -/********************************************************** - * XIQueryVersion. - * Query the server for the supported X Input Extension version. - * +/** + * @struct xXIQueryVersionReq + * Query the server for the supported X Input extension version. */ typedef struct { - uint8_t reqType; /* input extension major code */ - uint8_t ReqType; /* always X_XIQueryVersion */ - uint16_t length; + uint8_t reqType; /**< Input extension major code */ + uint8_t ReqType; /**< Always ::X_XIQueryVersion */ + uint16_t length; /**< Length in 4 byte units */ uint16_t major_version; uint16_t minor_version; } xXIQueryVersionReq; #define sz_xXIQueryVersionReq 8 typedef struct { - uint8_t repType; /* X_Reply */ - uint8_t RepType; /* always X_XIQueryVersion */ + uint8_t repType; /**< ::X_Reply */ + uint8_t RepType; /**< Always ::X_XIQueryVersion */ uint16_t sequenceNumber; uint32_t length; uint16_t major_version; @@ -222,26 +230,25 @@ typedef struct { } xXIQueryVersionReply; #define sz_xXIQueryVersionReply 32 -/********************************************************** - * - * XIQueryDevice +/** + * @struct xXIQueryDeviceReq * Query the server for information about a specific device or all input * devices. * */ typedef struct { - uint8_t reqType; /* input extension major code */ - uint8_t ReqType; /* always X_XIQueryDevice */ - uint16_t length; + uint8_t reqType; /**< Input extension major code */ + uint8_t ReqType; /**< Always ::X_XIQueryDevice */ + uint16_t length; /**< Length in 4 byte units */ uint16_t deviceid; uint16_t pad; } xXIQueryDeviceReq; #define sz_xXIQueryDeviceReq 8 typedef struct { - uint8_t repType; /* X_Reply */ - uint8_t RepType; /* always X_XIQueryDevice */ + uint8_t repType; /**< ::X_Reply */ + uint8_t RepType; /**< Always ::X_XIQueryDevice */ uint16_t sequenceNumber; uint32_t length; uint16_t num_devices; @@ -254,15 +261,14 @@ typedef struct { } xXIQueryDeviceReply; #define sz_xXIQueryDeviceReply 32 -/********************************************************** - * - * XISelectEvents - * +/** + * @struct xXISelectEventsReq + * Select for events on a given window. */ typedef struct { - uint8_t reqType; /* input extension major code */ - uint8_t ReqType; /* always X_XISelectEvents */ - uint16_t length; + uint8_t reqType; /**< Input extension major code */ + uint8_t ReqType; /**< Always ::X_XISelectEvents */ + uint16_t length; /**< Length in 4 byte units */ Window window; uint16_t num_masks; uint16_t pad; @@ -270,16 +276,15 @@ typedef struct { #define sz_xXISelectEventsReq 12 -/********************************************************** - * - * QueryDevicePointer. - * +/** + * @struct xXIQueryDevicePointerReq + * Query the given device's screen/window coordinates. */ typedef struct { - uint8_t reqType; /* input extension major code */ - uint8_t ReqType; /* always X_QueryDevicePointer */ - uint16_t length; + uint8_t reqType; /**< Input extension major code */ + uint8_t ReqType; /**< Always ::X_XIQueryDevicePointer */ + uint16_t length; /**< Length in 4 byte units */ Window win; uint16_t deviceid; uint16_t pad1; @@ -288,8 +293,8 @@ typedef struct { typedef struct { - uint8_t repType; /* X_Reply */ - uint8_t RepType; /* always X_QueryDevicePointer */ + uint8_t repType; /**< Input extension major opcode */ + uint8_t RepType; /**< Always ::X_XIQueryDevicePointer */ uint16_t sequenceNumber; uint32_t length; Window root; @@ -306,16 +311,15 @@ typedef struct { } xXIQueryDevicePointerReply; #define sz_xXIQueryDevicePointerReply 40 -/********************************************************** - * - * WarpDevicePointer. - * +/** + * @struct xXIWarpDevicePointerReq + * Warp the given device's pointer to the specified position. */ typedef struct { - uint8_t reqType; /* input extension major code */ - uint8_t ReqType; /* always X_WarpDevicePointer */ - uint16_t length; + uint8_t reqType; /**< Input extension major code */ + uint8_t ReqType; /**< Always ::X_XIWarpDevicePointer */ + uint16_t length; /**< Length in 4 byte units */ Window src_win; Window dst_win; INT16 src_x; @@ -329,16 +333,15 @@ typedef struct { } xXIWarpDevicePointerReq; #define sz_xXIWarpDevicePointerReq 28 -/********************************************************** - * - * ChangeDeviceCursor. - * +/** + * @struct xXIChangeDeviceCursorReq + * Change the given device's sprite to the given cursor. */ typedef struct { - uint8_t reqType; /* input extension major code */ - uint8_t ReqType; /* always X_ChangeDeviceCursor */ - uint16_t length; + uint8_t reqType; /**< Input extension major code */ + uint8_t ReqType; /**< Always ::X_XIChangeDeviceCursor */ + uint16_t length; /**< Length in 4 byte units */ Window win; Cursor cursor; uint16_t deviceid; @@ -346,25 +349,27 @@ typedef struct { } xXIChangeDeviceCursorReq; #define sz_xXIChangeDeviceCursorReq 16 -/********************************************************** - * - * ChangeDeviceHierarchy - * +/** + * @struct xXIChangeDeviceHierarchyReq + * Modify the device hierarchy. */ typedef struct { - uint8_t reqType; /* input extension major code */ - uint8_t ReqType; /* always X_ChangeDeviceHierarchy */ - uint16_t length; + uint8_t reqType; /**< Input extension major code */ + uint8_t ReqType; /**< Always ::X_XIChangeDeviceHierarchy */ + uint16_t length; /**< Length in 4 byte units */ uint8_t num_changes; uint8_t pad0; uint16_t pad1; } xXIChangeDeviceHierarchyReq; #define sz_xXIChangeDeviceHierarchyReq 8 +/** + * Generic header for any hierarchy change. + */ typedef struct { uint16_t type; - uint16_t length; /* in 4 byte units */ + uint16_t length; /**< Length in 4 byte units */ } xXIAnyHierarchyChangeInfo; /** @@ -372,8 +377,8 @@ typedef struct { * Name of new master follows struct (4-byte padded) */ typedef struct { - uint16_t type; /* Always CH_CreateMasterDevice */ - uint16_t length; /* 2 + (namelen + padding)/4 */ + uint16_t type; /**< Always ::XICreateMasterDevice */ + uint16_t length; /**< 2 + (namelen + padding)/4 */ uint16_t name_len; uint8_t send_core; uint8_t enable; @@ -384,70 +389,69 @@ typedef struct { * with the given master device. */ typedef struct { - uint16_t type; /* Always CH_RemoveMasterDevice */ - uint16_t length; /* 3 */ + uint16_t type; /**< Always ::XIRemoveMasterDevice */ + uint16_t length; /**< 3 */ uint16_t deviceid; - uint8_t return_mode; /* AttachToMaster, Floating */ + uint8_t return_mode; /**< ::XIAttachToMaster, ::XIFloating */ uint8_t pad; - uint16_t return_pointer; /* Pointer to attach slave ptr devices to */ - uint16_t return_keyboard; /* keyboard to attach slave keybd devices to*/ + uint16_t return_pointer; /**< Pointer to attach slave ptr devices to */ + uint16_t return_keyboard; /**< keyboard to attach slave keybd devices to*/ } xXIRemoveMasterInfo; -/* Attach an SD to a new device. +/** + * Attach an SD to a new device. * NewMaster has to be of same type (pointer->pointer, keyboard->keyboard); */ typedef struct { - uint16_t type; /* Always CH_AttachSlave */ - uint16_t length; /* 2 */ + uint16_t type; /**< Always ::XIAttachSlave */ + uint16_t length; /**< 2 */ uint16_t deviceid; - uint16_t new_master; /* id of new master device */ + uint16_t new_master; /**< id of new master device */ } xXIAttachSlaveInfo; -/* Detach an SD from its current master device. +/** + * Detach an SD from its current master device. */ typedef struct { - uint16_t type; /* Always CH_DetachSlave */ - uint16_t length; /* 2 */ + uint16_t type; /**< Always ::XIDetachSlave */ + uint16_t length; /**< 2 */ uint16_t deviceid; uint16_t pad; } xXIDetachSlaveInfo; -/********************************************************** - * - * SetClientPointer. - * +/** + * @struct xXISetClientPointerReq + * Set the window/client's ClientPointer. */ - typedef struct { uint8_t reqType; - uint8_t ReqType; /* Always X_SetClientPointer */ - uint16_t length; + uint8_t ReqType; /**< Always ::X_XISetClientPointer */ + uint16_t length; /**< Length in 4 byte units */ Window win; uint16_t deviceid; uint16_t pad1; } xXISetClientPointerReq; #define sz_xXISetClientPointerReq 12 -/********************************************************** - * - * GetClientPointer. - * +/** + * @struct xXIGetClientPointerReq + * Query the given window/client's ClientPointer setting. */ typedef struct { uint8_t reqType; - uint8_t ReqType; /* Always X_GetClientPointer */ - uint16_t length; + uint8_t ReqType; /**< Always ::X_GetClientPointer */ + uint16_t length; /**< Length in 4 byte units */ Window win; } xXIGetClientPointerReq; #define sz_xXIGetClientPointerReq 8 typedef struct { - uint8_t repType; /* input extension major opcode */ - uint8_t RepType; /* Always X_GetClientPointer */ + uint8_t repType; /**< Input extension major opcode */ + uint8_t RepType; /**< Always ::X_GetClientPointer */ uint16_t sequenceNumber; uint32_t length; - BOOL set; /* client pointer is set */ + BOOL set; /**< client pointer is set? */ uint8_t pad0; uint16_t deviceid; uint32_t pad1; @@ -458,15 +462,14 @@ typedef struct { } xXIGetClientPointerReply; #define sz_xXIGetClientPointerReply 32 -/********************************************************** - * - * SetDeviceFocus. - * +/** + * @struct xXISetDeviceFocusReq + * Set the input focus to the specified window. */ typedef struct { uint8_t reqType; - uint8_t ReqType; /* Always X_XISetDeviceFocus */ - uint16_t length; + uint8_t ReqType; /**< Always ::X_XISetDeviceFocus */ + uint16_t length; /**< Length in 4 byte units */ Window focus; Time time; uint16_t deviceid; @@ -474,23 +477,22 @@ typedef struct { } xXISetDeviceFocusReq; #define sz_xXISetDeviceFocusReq 16 -/********************************************************** - * - * GetDeviceFocus. - * +/** + * @struct xXIGetDeviceFocusReq + * Query the current input focus. */ typedef struct { uint8_t reqType; - uint8_t ReqType; /* Always X_XIGetDeviceFocus */ - uint16_t length; + uint8_t ReqType; /**< Always ::X_XIGetDeviceFocus */ + uint16_t length; /**< Length in 4 byte units */ uint16_t deviceid; uint16_t pad0; } xXIGetDeviceFocusReq; #define sz_xXIGetDeviceFocusReq 8 typedef struct { - uint8_t repType; /* input extension major opcode */ - uint8_t RepType; /* Always X_XIGetDeviceFocus */ + uint8_t repType; /**< Input extension major opcode */ + uint8_t RepType; /**< Always ::X_XIGetDeviceFocus */ uint16_t sequenceNumber; uint32_t length; Window focus; @@ -503,15 +505,14 @@ typedef struct { #define sz_xXIGetDeviceFocusReply 32 -/********************************************************** - * - * GrabDevice - * +/** + * @struct xXIGrabDeviceReq + * Grab the given device. */ typedef struct { uint8_t reqType; - uint8_t ReqType; /* Always X_XIGrabDevice */ - uint16_t length; + uint8_t ReqType; /**< Always ::X_XIGrabDevice */ + uint16_t length; /**< Length in 4 byte units */ Window grab_window; Time time; Cursor cursor; @@ -524,9 +525,19 @@ typedef struct { } xXIGrabDeviceReq; #define sz_xXIGrabDeviceReq 24 +/** + * Return codes from a XIPassiveGrabDevice request. + */ typedef struct { - uint8_t repType; /* input extension major opcode */ - uint8_t RepType; /* Always X_XIGrabDevice */ + uint32_t modifiers; /**< Modifier state */ + uint8_t status; /**< Grab status code */ + uint8_t pad0; + uint16_t pad1; +} xXIGrabModifierInfo; + +typedef struct { + uint8_t repType; /**< Input extension major opcode */ + uint8_t RepType; /**< Always ::X_XIGrabDevice */ uint16_t sequenceNumber; uint32_t length; uint8_t status; @@ -540,15 +551,15 @@ typedef struct { } xXIGrabDeviceReply; #define sz_xXIGrabDeviceReply 32 -/********************************************************** - * - * UngrabDevice +/** + * @struct xXIUngrabDeviceReq + * Ungrab the specified device. * */ typedef struct { uint8_t reqType; - uint8_t ReqType; /* Always X_XIUngrabDevice */ - uint16_t length; + uint8_t ReqType; /**< Always ::X_XIUngrabDevice */ + uint16_t length; /**< Length in 4 byte units */ Time time; uint16_t deviceid; uint16_t pad; @@ -556,15 +567,14 @@ typedef struct { #define sz_xXIUngrabDeviceReq 12 -/********************************************************** - * - * AllowEvents - * +/** + * @struct xXIAllowEventsReq + * Allow or replay events on the specified grabbed device. */ typedef struct { uint8_t reqType; - uint8_t ReqType; /* Always X_XIAllowEvents */ - uint16_t length; + uint8_t ReqType; /**< Always ::X_XIAllowEvents */ + uint16_t length; /**< Length in 4 byte units */ Time time; uint16_t deviceid; uint8_t mode; @@ -573,15 +583,14 @@ typedef struct { #define sz_xXIAllowEventsReq 12 -/********************************************************** - * - * PassiveGrabDevice - * +/** + * @struct xXIPassiveGrabDeviceReq + * Passively grab the device. */ typedef struct { uint8_t reqType; - uint8_t ReqType; /* Always X_XIPassiveGrabDevice */ - uint16_t length; + uint8_t ReqType; /**< Always ::X_XIPassiveGrabDevice */ + uint16_t length; /**< Length in 4 byte units */ Time time; Window grab_window; Cursor cursor; @@ -598,8 +607,8 @@ typedef struct { #define sz_xXIPassiveGrabDeviceReq 32 typedef struct { - uint8_t repType; /* input extension major opcode */ - uint8_t RepType; /* Always X_XIPassiveGrabDevice */ + uint8_t repType; /**< Input extension major opcode */ + uint8_t RepType; /**< Always ::X_XIPassiveGrabDevice */ uint16_t sequenceNumber; uint32_t length; uint16_t num_modifiers; @@ -612,10 +621,14 @@ typedef struct { } xXIPassiveGrabDeviceReply; #define sz_xXIPassiveGrabDeviceReply 32 +/** + * @struct xXIPassiveUngrabDeviceReq + * Delete a passive grab for the given device. + */ typedef struct { uint8_t reqType; - uint8_t ReqType; /* Always X_XIPassiveUngrabDevice */ - uint16_t length; + uint8_t ReqType; /**< Always ::X_XIPassiveUngrabDevice */ + uint16_t length; /**< Length in 4 byte units */ Window grab_window; uint32_t detail; uint16_t deviceid; @@ -626,23 +639,22 @@ typedef struct { } xXIPassiveUngrabDeviceReq; #define sz_xXIPassiveUngrabDeviceReq 20 -/********************************************************** - * - * XIListProperties - * +/** + * @struct xXIListPropertiesReq + * List all device properties on the specified device. */ typedef struct { uint8_t reqType; - uint8_t ReqType; /* Always X_XIListProperties */ - uint16_t length; + uint8_t ReqType; /**< Always ::X_XIListProperties */ + uint16_t length; /**< Length in 4 byte units */ uint16_t deviceid; uint16_t pad; } xXIListPropertiesReq; #define sz_xXIListPropertiesReq 8 typedef struct { - uint8_t repType; /* input extension major opcode */ - uint8_t RepType; /* Always X_XIListProperties */ + uint8_t repType; /**< Input extension major opcode */ + uint8_t RepType; /**< Always ::X_XIListProperties */ uint16_t sequenceNumber; uint32_t length; uint16_t num_properties; @@ -655,15 +667,14 @@ typedef struct { } xXIListPropertiesReply; #define sz_xXIListPropertiesReply 32 -/********************************************************** - * - * XIChangeDeviceProperty - * +/** + * @struct xXIChangePropertyReq + * Change a property on the specified device. */ typedef struct { uint8_t reqType; - uint8_t ReqType; /* Always X_XIChangeProperty */ - uint16_t length; + uint8_t ReqType; /**< Always ::X_XIChangeProperty */ + uint16_t length; /**< Length in 4 byte units */ uint16_t deviceid; uint8_t mode; uint8_t format; @@ -673,30 +684,28 @@ typedef struct { } xXIChangePropertyReq; #define sz_xXIChangePropertyReq 20 -/********************************************************** - * - * XIDeleteProperty - * +/** + * @struct xXIDeletePropertyReq + * Delete the specified property. */ typedef struct { uint8_t reqType; - uint8_t ReqType; /* Always X_XIDeleteProperty */ - uint16_t length; + uint8_t ReqType; /**< Always X_XIDeleteProperty */ + uint16_t length; /**< Length in 4 byte units */ uint16_t deviceid; uint16_t pad0; Atom property; } xXIDeletePropertyReq; #define sz_xXIDeletePropertyReq 12 -/********************************************************** - * - * XIGetProperty - * +/** + * @struct xXIGetPropertyReq + * Query the specified property's values. */ typedef struct { uint8_t reqType; - uint8_t ReqType; /* Always X_XIGetProperty */ - uint16_t length; + uint8_t ReqType; /**< Always X_XIGetProperty */ + uint16_t length; /**< Length in 4 byte units */ uint16_t deviceid; #if defined(__cplusplus) || defined(c_plusplus) uint8_t c_delete; @@ -712,8 +721,8 @@ typedef struct { #define sz_xXIGetPropertyReq 24 typedef struct { - uint8_t repType; /* input extension major opcode */ - uint8_t RepType; /* Always X_XIGetProperty */ + uint8_t repType; /**< Input extension major opcode */ + uint8_t RepType; /**< Always X_XIGetProperty */ uint16_t sequenceNumber; uint32_t length; Atom type; @@ -733,10 +742,14 @@ typedef struct { * * *************************************************************************************/ +/** + * @struct xXIGenericDeviceEvent + * Generic XI2 event header. All XI2 events use the same header. + */ typedef struct { uint8_t type; - uint8_t extension; /* XI extension offset */ + uint8_t extension; /**< XI extension offset */ uint16_t sequenceNumber; uint32_t length; uint16_t evtype; @@ -744,147 +757,163 @@ typedef struct Time time; } xXIGenericDeviceEvent; -/*********************************************************** - * DeviceHierarchyEvent - * +/** + * @struct xXIDeviceHierarchyEvent + * The device hierarchy has been modified. This event includes the device + * hierarchy after the modification has been applied. + */ + +/** + * Device hierarch information. */ typedef struct { uint16_t deviceid; - uint16_t attachment; - uint8_t use; - BOOL enabled; + uint16_t attachment; /**< ID of master or paired device */ + uint8_t use; /**< ::XIMasterKeyboard, + ::XIMasterPointer, + ::XISlaveKeyboard, + ::XISlavePointer, + ::XIFloatingSlave */ + BOOL enabled; /**< TRUE if the device is enabled */ uint16_t pad; } xXIHierarchyInfo; typedef struct { - uint8_t type; /* always GenericEvent */ - uint8_t extension; /* XI extension offset */ + uint8_t type; /**< Always GenericEvent */ + uint8_t extension; /**< XI extension offset */ uint16_t sequenceNumber; - uint32_t length; - uint16_t evtype; /* XI_Hierarchy */ + uint32_t length; /**< Length in 4 byte units */ + uint16_t evtype; /**< ::XI_Hierarchy */ uint16_t deviceid; Time time; - uint32_t flags; /* MasterAdded, MasterDeleted, - SlaveAttached, SlaveDetached, - SlaveAdded, SlaveRemoved, - DeviceEnabled, DeviceDisabled */ + uint32_t flags; /* ::XIMasterAdded, ::XIMasterDeleted, + ::XISlaveAttached, ::XISlaveDetached, + ::XISlaveAdded, ::XISlaveRemoved, + ::XIDeviceEnabled, ::XIDeviceDisabled */ uint16_t num_devices; uint16_t pad0; uint32_t pad1; uint32_t pad2; } xXIDeviceHierarchyEvent; -/*********************************************************** - * DeviceChangedEvent - * +/** + * @struct xXIDeviceChangedEvent + * A device has changed capabilities. */ - typedef struct { - uint8_t type; /* always GenericEvent */ - uint8_t extension; /* XI extension offset */ + uint8_t type; /**< Always GenericEvent */ + uint8_t extension; /**< XI extension offset */ uint16_t sequenceNumber; - uint32_t length; - uint16_t evtype; /* XI_DeviceChanged */ - uint16_t deviceid; /* id of master */ + uint32_t length; /**< Length in 4 byte units */ + uint16_t evtype; /**< XI_DeviceChanged */ + uint16_t deviceid; /**< Device that has changed */ Time time; - uint16_t num_classes; /* classes that have changed */ - uint16_t sourceid; /* Source for the new classes*/ - uint8_t reason; /* SlaveSwitch, DeviceChange */ + uint16_t num_classes; /**< Number of classes that have changed */ + uint16_t sourceid; /**< Source of the new classes */ + uint8_t reason; /**< ::XISlaveSwitch, ::XIDeviceChange */ uint8_t pad0; uint16_t pad1; uint32_t pad2; uint32_t pad3; } xXIDeviceChangedEvent; -/*********************************************************** - * DeviceEvent - * +/** + * @struct xXIDeviceEvent + * Default input event for pointer or keyboard input. */ +/** + * XKB modifier information. + * The effective modifier is a binary mask of base, latched, and locked + * modifiers. + */ typedef struct { - uint32_t base_mods; - uint32_t latched_mods; - uint32_t locked_mods; + uint32_t base_mods; /**< Logically pressed modifiers */ + uint32_t latched_mods; /**< Logically latched modifiers */ + uint32_t locked_mods; /**< Logically locked modifiers */ } xXIModifierInfo; +/** + * XKB group information. + * The effective group is the mathematical sum of base, latched, and locked + * group after group wrapping is taken into account. + */ typedef struct { - uint8_t base_group; - uint8_t latched_group; - uint8_t locked_group; + uint8_t base_group; /**< Logically "pressed" group */ + uint8_t latched_group; /**< Logically latched group */ + uint8_t locked_group; /**< Logically locked group */ uint8_t pad0; } xXIGroupInfo; typedef struct { - uint8_t type; /* always GenericEvent */ - uint8_t extension; /* XI extension offset */ + uint8_t type; /**< Always GenericEvent */ + uint8_t extension; /**< XI extension offset */ uint16_t sequenceNumber; - uint32_t length; + uint32_t length; /**< Length in 4 byte uints */ uint16_t evtype; uint16_t deviceid; Time time; - uint32_t detail; /* keycode or button */ + uint32_t detail; /**< Keycode or button */ Window root; Window event; Window child; /* └──────── 32 byte boundary ────────┘ */ - FP1616 root_x; /* always screen coords, 16.16 fixed point */ + FP1616 root_x; /**< Always screen coords, 16.16 fixed point */ FP1616 root_y; - FP1616 event_x; /* always screen coords, 16.16 fixed point */ + FP1616 event_x; /**< Always screen coords, 16.16 fixed point */ FP1616 event_y; - uint16_t buttons_len; /* len of button flags in 4 b units */ - uint16_t valuators_len; /* len of val. flags in 4 b units */ - uint16_t sourceid; /* the source device */ + uint16_t buttons_len; /**< Len of button flags in 4 b units */ + uint16_t valuators_len; /**< Len of val. flags in 4 b units */ + uint16_t sourceid; /**< The source device */ uint16_t pad0; xXIModifierInfo mods; xXIGroupInfo group; } xXIDeviceEvent; - -/*********************************************************** - * RawEvent - * +/** + * @struct xXIRawDeviceEvent + * Sent when an input event is generated. RawEvents include valuator + * information in both device-specific data (i.e. unaccelerated) and + * processed data (i.e. accelerated, if applicable). */ - typedef struct { - uint8_t type; /* always GenericEvent */ - uint8_t extension; /* XI extension offset */ + uint8_t type; /**< Always GenericEvent */ + uint8_t extension; /**< XI extension offset */ uint16_t sequenceNumber; - uint32_t length; - uint16_t evtype; /* XI_RawEvent */ + uint32_t length; /**< Length in 4 byte uints */ + uint16_t evtype; /**< ::XI_RawEvent */ uint16_t deviceid; Time time; uint32_t detail; - uint16_t eventtype; /* XI_Motion, XI_ButtonPress, - XI_ButtonRelease, XI_KeyPress, - XI_KeyRelease */ - uint16_t valuators_len; + uint16_t eventtype; /**< ::XI_Motion, ::XI_ButtonPress, + ::XI_ButtonRelease, ::XI_KeyPress, + ::XI_KeyRelease */ + uint16_t valuators_len; /**< Length of trailing valuator + mask in 4 byte units */ uint32_t pad1; uint32_t pad2; } xXIRawDeviceEvent; -/*********************************************************** - * Enter/LeaveEvents - * - * Note that the layout of root, event, child, root_x, root_y, event_x, - * event_y must be identical to the xXIDeviceEvent. - * +/** + * @struct xXIEnterEvent + * Note that the layout of root, event, child, root_x, root_y, event_x, + * event_y must be identical to the xXIDeviceEvent. */ - typedef struct { - uint8_t type; /* always GenericEvent */ - uint8_t extension; /* XI extension offset */ + uint8_t type; /**< Always GenericEvent */ + uint8_t extension; /**< XI extension offset */ uint16_t sequenceNumber; - uint32_t length; - uint16_t evtype; /* XI_Enter */ + uint32_t length; /**< Length in 4 byte uints */ + uint16_t evtype; /**< ::XI_Enter */ uint16_t deviceid; Time time; uint16_t sourceid; @@ -900,7 +929,8 @@ typedef struct FP1616 event_y; BOOL same_screen; BOOL focus; - uint16_t buttons_len; + uint16_t buttons_len; /**< Length of trailing button mask + in 4 byte units */ xXIModifierInfo mods; xXIGroupInfo group; } xXIEnterEvent; @@ -909,22 +939,24 @@ typedef xXIEnterEvent xXILeaveEvent; typedef xXIEnterEvent xXIFocusInEvent; typedef xXIEnterEvent xXIFocusOutEvent; -/*********************************************************** - * PropertyEvents - * +/** + * @struct xXIPropertyEvent + * Sent when a device property is created, modified or deleted. Does not + * include property data, the client is required to query the data. */ - typedef struct { - uint8_t type; /* always GenericEvent */ - uint8_t extension; /* XI extension offset */ + uint8_t type; /**< Always GenericEvent */ + uint8_t extension; /**< XI extension offset */ uint16_t sequenceNumber; - uint32_t length; - uint16_t evtype; /* XI_PropertyEvent */ + uint32_t length; /**< Length in 4 byte uints */ + uint16_t evtype; /**< ::XI_PropertyEvent */ uint16_t deviceid; Time time; Atom property; - uint8_t what; + uint8_t what; /**< ::XIPropertyDeleted, + ::XIPropertyCreated, + ::XIPropertyMotified */ uint8_t pad0; uint16_t pad1; uint32_t pad2; From 886d2aceb77070292e984ed2b25e31ac9c82aba7 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 12 May 2009 13:45:48 +1000 Subject: [PATCH 135/388] Define Cursor as CARD32. Reported-by: Benjamin Close Signed-off-by: Peter Hutterer --- XI2proto.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/XI2proto.h b/XI2proto.h index e3a5101..1ea6270 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -45,6 +45,7 @@ #define Window CARD32 #define Time CARD32 #define Atom CARD32 +#define Cursor CARD32 /** * XI2 Request opcodes @@ -967,5 +968,6 @@ typedef struct #undef Window #undef Time #undef Atom +#undef Cursor #endif /* _XI2PROTO_H_ */ From 12635cbd4aea0ba3b38b96682d63bb71ba8c737e Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 12 May 2009 16:14:01 +1000 Subject: [PATCH 136/388] Add per-device flags to XIDeviceHierarchyEvents --- XI2proto.h | 12 ++++++++---- XI2proto.txt | 3 ++- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index 1ea6270..67502bf 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -778,6 +778,10 @@ typedef struct ::XIFloatingSlave */ BOOL enabled; /**< TRUE if the device is enabled */ uint16_t pad; + uint32_t flags; /**< ::XIMasterAdded, ::XIMasterDeleted, + ::XISlaveAttached, ::XISlaveDetached, + ::XISlaveAdded, ::XISlaveRemoved, + ::XIDeviceEnabled, ::XIDeviceDisabled */ } xXIHierarchyInfo; typedef struct @@ -789,10 +793,10 @@ typedef struct uint16_t evtype; /**< ::XI_Hierarchy */ uint16_t deviceid; Time time; - uint32_t flags; /* ::XIMasterAdded, ::XIMasterDeleted, - ::XISlaveAttached, ::XISlaveDetached, - ::XISlaveAdded, ::XISlaveRemoved, - ::XIDeviceEnabled, ::XIDeviceDisabled */ + uint32_t flags; /**< ::XIMasterAdded, ::XIMasterDeleted, + ::XISlaveAttached, ::XISlaveDetached, + ::XISlaveAdded, ::XISlaveRemoved, + ::XIDeviceEnabled, ::XIDeviceDisabled */ uint16_t num_devices; uint16_t pad0; uint32_t pad1; diff --git a/XI2proto.txt b/XI2proto.txt index be27a92..e4336b6 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -1166,7 +1166,8 @@ EVENTHEADER { type: BYTE HIERARCHYINFO { deviceid: DEVICEID, attachment: DEVICEID, type: DEVICEUSE - enabled: BOOL } + enabled: BOOL + flags: SETofHIERARCHYMASK} flags Set of the changes that have occured, causing this event. From 7aba20ed4c404b80112a0bb28220a2c646f319e4 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 12 May 2009 16:51:05 +1000 Subject: [PATCH 137/388] Remove superfluous "Device" from protocol requests and events. Anything with prefix XI is per-device anyway. --- XI2.h | 4 +-- XI2proto.h | 80 ++++++++++++++++++++++++++-------------------------- XI2proto.txt | 38 ++++++++++++------------- 3 files changed, 61 insertions(+), 61 deletions(-) diff --git a/XI2.h b/XI2.h index d0b56b8..eeee67f 100644 --- a/XI2.h +++ b/XI2.h @@ -63,8 +63,8 @@ #define XIDeviceDisabled (1 << 7) /* ChangeHierarchy constants */ -#define XICreateMasterDevice 1 -#define XIRemoveMasterDevice 2 +#define XICreateMaster 1 +#define XIRemoveMaster 2 #define XIAttachSlave 3 #define XIDetachSlave 4 diff --git a/XI2proto.h b/XI2proto.h index 67502bf..4b808ef 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -52,17 +52,17 @@ * @addtogroup XI2Requests * @{ */ -#define X_XIQueryDevicePointer 40 -#define X_XIWarpDevicePointer 41 -#define X_XIChangeDeviceCursor 42 -#define X_XIChangeDeviceHierarchy 43 +#define X_XIQueryPointer 40 +#define X_XIWarpPointer 41 +#define X_XIChangeCursor 42 +#define X_XIChangeHierarchy 43 #define X_XISetClientPointer 44 #define X_XIGetClientPointer 45 #define X_XISelectEvents 46 #define X_XIQueryVersion 47 #define X_XIQueryDevice 48 -#define X_XISetDeviceFocus 49 -#define X_XIGetDeviceFocus 50 +#define X_XISetFocus 49 +#define X_XIGetFocus 50 #define X_XIGrabDevice 51 #define X_XIUngrabDevice 52 #define X_XIAllowEvents 53 @@ -75,7 +75,7 @@ /*@}*/ /** Number of XI requests */ -#define XI2REQUESTS (X_XIGetProperty - X_XIQueryDevicePointer + 1) +#define XI2REQUESTS (X_XIGetProperty - X_XIQueryPointer + 1) /** Number of XI2 events */ #define XI2EVENTS (XI_LASTEVENT + 1) @@ -192,7 +192,7 @@ typedef struct { typedef struct { uint16_t deviceid; /**< Device id to select for */ uint16_t mask_len; /**< Length of mask in 4 byte units */ -} xXIDeviceEventMask; +} xXIEventMask; @@ -278,24 +278,24 @@ typedef struct { /** - * @struct xXIQueryDevicePointerReq + * @struct xXIQueryPointerReq * Query the given device's screen/window coordinates. */ typedef struct { uint8_t reqType; /**< Input extension major code */ - uint8_t ReqType; /**< Always ::X_XIQueryDevicePointer */ + uint8_t ReqType; /**< Always ::X_XIQueryPointer */ uint16_t length; /**< Length in 4 byte units */ Window win; uint16_t deviceid; uint16_t pad1; -} xXIQueryDevicePointerReq; -#define sz_xXIQueryDevicePointerReq 12 +} xXIQueryPointerReq; +#define sz_xXIQueryPointerReq 12 typedef struct { uint8_t repType; /**< Input extension major opcode */ - uint8_t RepType; /**< Always ::X_XIQueryDevicePointer */ + uint8_t RepType; /**< Always ::X_XIQueryPointer */ uint16_t sequenceNumber; uint32_t length; Window root; @@ -309,17 +309,17 @@ typedef struct { uint8_t same_screen; uint8_t pad0; uint16_t pad1; -} xXIQueryDevicePointerReply; -#define sz_xXIQueryDevicePointerReply 40 +} xXIQueryPointerReply; +#define sz_xXIQueryPointerReply 40 /** - * @struct xXIWarpDevicePointerReq + * @struct xXIWarpPointerReq * Warp the given device's pointer to the specified position. */ typedef struct { uint8_t reqType; /**< Input extension major code */ - uint8_t ReqType; /**< Always ::X_XIWarpDevicePointer */ + uint8_t ReqType; /**< Always ::X_XIWarpPointer */ uint16_t length; /**< Length in 4 byte units */ Window src_win; Window dst_win; @@ -331,39 +331,39 @@ typedef struct { INT16 dst_y; uint16_t deviceid; uint16_t pad1; -} xXIWarpDevicePointerReq; -#define sz_xXIWarpDevicePointerReq 28 +} xXIWarpPointerReq; +#define sz_xXIWarpPointerReq 28 /** - * @struct xXIChangeDeviceCursorReq + * @struct xXIChangeCursorReq * Change the given device's sprite to the given cursor. */ typedef struct { uint8_t reqType; /**< Input extension major code */ - uint8_t ReqType; /**< Always ::X_XIChangeDeviceCursor */ + uint8_t ReqType; /**< Always ::X_XIChangeCursor */ uint16_t length; /**< Length in 4 byte units */ Window win; Cursor cursor; uint16_t deviceid; uint16_t pad1; -} xXIChangeDeviceCursorReq; -#define sz_xXIChangeDeviceCursorReq 16 +} xXIChangeCursorReq; +#define sz_xXIChangeCursorReq 16 /** - * @struct xXIChangeDeviceHierarchyReq + * @struct xXIChangeHierarchyReq * Modify the device hierarchy. */ typedef struct { uint8_t reqType; /**< Input extension major code */ - uint8_t ReqType; /**< Always ::X_XIChangeDeviceHierarchy */ + uint8_t ReqType; /**< Always ::X_XIChangeHierarchy */ uint16_t length; /**< Length in 4 byte units */ uint8_t num_changes; uint8_t pad0; uint16_t pad1; -} xXIChangeDeviceHierarchyReq; -#define sz_xXIChangeDeviceHierarchyReq 8 +} xXIChangeHierarchyReq; +#define sz_xXIChangeHierarchyReq 8 /** * Generic header for any hierarchy change. @@ -464,19 +464,19 @@ typedef struct { #define sz_xXIGetClientPointerReply 32 /** - * @struct xXISetDeviceFocusReq + * @struct xXISetFocusReq * Set the input focus to the specified window. */ typedef struct { uint8_t reqType; - uint8_t ReqType; /**< Always ::X_XISetDeviceFocus */ + uint8_t ReqType; /**< Always ::X_XISetFocus */ uint16_t length; /**< Length in 4 byte units */ Window focus; Time time; uint16_t deviceid; uint16_t pad0; -} xXISetDeviceFocusReq; -#define sz_xXISetDeviceFocusReq 16 +} xXISetFocusReq; +#define sz_xXISetFocusReq 16 /** * @struct xXIGetDeviceFocusReq @@ -488,12 +488,12 @@ typedef struct { uint16_t length; /**< Length in 4 byte units */ uint16_t deviceid; uint16_t pad0; -} xXIGetDeviceFocusReq; -#define sz_xXIGetDeviceFocusReq 8 +} xXIGetFocusReq; +#define sz_xXIGetFocusReq 8 typedef struct { uint8_t repType; /**< Input extension major opcode */ - uint8_t RepType; /**< Always ::X_XIGetDeviceFocus */ + uint8_t RepType; /**< Always ::X_XIGetFocus */ uint16_t sequenceNumber; uint32_t length; Window focus; @@ -502,8 +502,8 @@ typedef struct { uint32_t pad3; uint32_t pad4; uint32_t pad5; -} xXIGetDeviceFocusReply; -#define sz_xXIGetDeviceFocusReply 32 +} xXIGetFocusReply; +#define sz_xXIGetFocusReply 32 /** @@ -759,7 +759,7 @@ typedef struct } xXIGenericDeviceEvent; /** - * @struct xXIDeviceHierarchyEvent + * @struct xXIHierarchyEvent * The device hierarchy has been modified. This event includes the device * hierarchy after the modification has been applied. */ @@ -801,7 +801,7 @@ typedef struct uint16_t pad0; uint32_t pad1; uint32_t pad2; -} xXIDeviceHierarchyEvent; +} xXIHierarchyEvent; /** * @struct xXIDeviceChangedEvent @@ -883,7 +883,7 @@ typedef struct /** - * @struct xXIRawDeviceEvent + * @struct xXIRawEvent * Sent when an input event is generated. RawEvents include valuator * information in both device-specific data (i.e. unaccelerated) and * processed data (i.e. accelerated, if applicable). @@ -905,7 +905,7 @@ typedef struct mask in 4 byte units */ uint32_t pad1; uint32_t pad2; -} xXIRawDeviceEvent; +} xXIRawEvent; /** * @struct xXIEnterEvent diff --git a/XI2proto.txt b/XI2proto.txt index e4336b6..c23d52c 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -315,13 +315,13 @@ XI2. Clients should ignore this data. XISelectEvents window: Window num_masks: CARD16 - masks: LISTofDEVICEEVENTMASK + masks: LISTofEVENTMASK └─── - DEVICEEVENTMASK { deviceid: DEVICE, - mask_len: CARD16, - mask: SETofEVENTMASK + EVENTMASK { deviceid: DEVICE, + mask_len: CARD16, + mask: SETofEVENTMASK window The window to select the events on. @@ -351,7 +351,7 @@ XI2. Clients should ignore this data. If 'mask_len' is 0, the event mask for the given device is cleared. ┌─── - XIQueryDevicePointer + XIQueryPointer window: Window deviceid: DEVICEID ▶ @@ -380,7 +380,7 @@ XI2. Clients should ignore this data. TRUE if 'window' is on the same screen as the pointer. ┌─── - XIWarpDevicePointer + XIWarpPointer src_win: Window dst_win: Window src_x: FP1616 @@ -392,8 +392,8 @@ XI2. Clients should ignore this data. deviceid: DEVICEID └─── - WarpDevicePointer moves the pointer of 'deviceid' as if the user had moved - the pointer. WarpDevicePointer can only be called for MasterPointer and + WarpPointer moves the pointer of 'deviceid' as if the user had moved + the pointer. WarpPointer can only be called for MasterPointer and FloatingSlave devices. src_win @@ -425,7 +425,7 @@ XI2. Clients should ignore this data. moved the pointer. ┌─── - XIChangeDeviceCursor + XIChangeCursor win: Window cursor: Cursor deviceid: DEVICEID @@ -449,7 +449,7 @@ XI2. Clients should ignore this data. - repeat on parent window until a cursor has been found. ┌─── - XIChangeDeviceHierarchy + XIChangeHierarchy num_changes: CARD8 changes: LISTofHIERARCHYCHANGES └─── @@ -483,7 +483,7 @@ XI2. Clients should ignore this data. length: CARD16 deviceid: DEVICEID } - XIChangeDeviceHierarchy allows a client to modify the MD/SD device + XIChangeHierarchy allows a client to modify the MD/SD device hierarchy (see Section 4). num_changes @@ -586,7 +586,7 @@ XI2. Clients should ignore this data. The master pointer that acts as a ClientPointer if 'set' is TRUE. ┌─── - XISetDeviceFocus + XISetFocus focus: Window deviceid: DEVICEID time: Time @@ -616,7 +616,7 @@ XI2. Clients should ignore this data. Otherwise, the last-focus-change time is set to the specified time. ┌─── - XIGetDeviceFocus + XIGetFocus deviceid: DEVICEID ▶ focus: Window @@ -731,7 +731,7 @@ XI2. Clients should ignore this data. The request has no effect if the specified time is earlier than the last-device-grab time or is later than the current server time. - This request generates DeviceFocusIn and DeviceFocusOut events. + This request generates FocusIn and FocusOut events. An XIUngrabDevice is performed automatically if the event window for an active device grab becomes not viewable. @@ -1152,7 +1152,7 @@ EVENTHEADER { type: BYTE ┌─── - DeviceHierarchyEvent: + HierarchyEvent: EVENTHEADER flags: SETofHIERARCHYMASK num_devices: CARD16 @@ -1176,7 +1176,7 @@ EVENTHEADER { type: BYTE devices The current hierarchy layout for each device. - An XDeviceHierarchyEvent is sent whenever the device hierarchy been + An XIHierarchyEvent is sent whenever the device hierarchy been changed. The 'flags' specify all types of hierarchy modifiations that have occured. For all devices, 'deviceinfo' details the hierarchy information after the @@ -1194,7 +1194,7 @@ EVENTHEADER { type: BYTE device. Note: Multiple devices may be affected in one hierarchy change, - 'deviceid' in an XDeviceHierarchyChangedEvent is always the first affected + 'deviceid' in an XIHierarchyEvent is always the first affected device. Clients should ignore deviceid and instead use the 'devices' list. ┌─── @@ -1263,7 +1263,7 @@ EVENTHEADER { type: BYTE latched_group: CARD8, locked_group: CARD8 } - An XDeviceEvent is generated whenever the logical state of a device + 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. @@ -1335,7 +1335,7 @@ EVENTHEADER { type: BYTE clipping and acceleration. Transformed valuator data may be equivalent to raw data. In this case, both raw and transformed valuator data is provided. - RawDeviceEvents are sent exclusively to all root windows or to the client + RawEvents are sent exclusively to all root windows or to the client that grabbed the device only. eventtype From e1138da90235797248f38d7f613566fb8418c396 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 12 May 2009 19:24:31 +1000 Subject: [PATCH 138/388] XI2proto.txt: remove more mentioning of keycode grabs --- XI2proto.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/XI2proto.txt b/XI2proto.txt index c23d52c..61d91b6 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -850,7 +850,7 @@ XI2. Clients should ignore this data. GRABMODIFIERINFO { status: Access modifiers: CARD32 } - Establish an explicit passive grab for a button or keycode or keysym + Establish an explicit passive grab for a button or keysym on the specified input device. cursor @@ -906,7 +906,7 @@ XI2. Clients should ignore this data. is logically pressed or the grab_type is GrabtypeKeysym and the keysym specified in detail is logically pressed, and - the grab_window contains the pointer, and - - a passive grab on the same button/keycode/keysym + modifier + - a passive grab on the same button/keysym + modifier combination does not exist on an ancestor of grab_window. A modifier of GrabAnyModifier is equivalent to issuing the request for @@ -914,7 +914,7 @@ XI2. Clients should ignore this data. may request a grab for GrabAnyModifier and explicit modifier combinations in the same request. - The grab is released when all buttons or keycodes or keysyms are + The grab is released when all buttons or keysyms are released, independent of the state of modifier keys. 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. @@ -922,7 +922,7 @@ XI2. Clients should ignore this data. on the same button/key combinations on the same window. If some other client already has issued a XIPassiveGrabDevice request - with the same button/keycode/keysym and modifier combination, the + with the same button or keysym and modifier combination, the failed modifier combinations is returned in modifiers_return. If num_modifiers_return is zero, all passive grabs have been successful. @@ -936,7 +936,7 @@ XI2. Clients should ignore this data. modifiers: MODIFIERINFO └─── - Release an explicit passive grab for a button or keycode or keysym on + Release an explicit passive grab for a button or keysym on the specified input device. deviceid @@ -952,7 +952,7 @@ XI2. Clients should ignore this data. num_modifiers Number of elements in modifiers. - This request has no effect if the matching button/keycode/keysym and + This request has no effect if the matching button or keysym and modifier combination is not grabbed b this client. ┌─── From d041f30777c09f07ac79fface61bfbfa654306f2 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 14 May 2009 10:29:49 +1000 Subject: [PATCH 139/388] Add an introduction to XI2proto.txt --- XI2proto.txt | 29 +++++++++++++++++++++++------ 1 file changed, 23 insertions(+), 6 deletions(-) diff --git a/XI2proto.txt b/XI2proto.txt index 61d91b6..3287c48 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -1,10 +1,10 @@ - The X Input Extension - Version 2.0 + The X Input Extension + Version 2.0 - Peter Hutterer - peter.hutterer@redhat.com - Red Hat, Inc. + Peter Hutterer + peter.hutterer@redhat.com + Red Hat, Inc. @@ -13,7 +13,24 @@ The X Input Extension version 2.0 (XI2) is the second major release of the X Input Extension. -FIXME +XI2 provides a number of enhancements over version 1.5, including: +- use of XGE and GenericEvents. GenericEvents are of flexible length with a + minimum length of 32 bytes. +- explicit device hierarchy of master and slave devices. See Section 4. +- use of multiple independent master devices (Multi-Poiner X or MPX). +- the ability for devices to change capabilities at runtime. +- raw device events + +XI2's intent is to replace both core input processing and prior versions of +the X Input Extension. Historically, the majority of applications employed the +core protocol requests and events to handle user input. The core protocol does +not provide information about which device generated the event. The X Input +Extension version up to 1.5 requires the differentiation between core and +extended devices. Extended devices may not be core devices and thus cannot be +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. Notations used in this document From 4cc6992b08b6c7aed0d1242e3382fb53d51a0fe2 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 14 May 2009 12:09:38 +1000 Subject: [PATCH 140/388] XIQueryPointer needs to include sensible button/modifier state. This includes shuffling the xXIModifierInfo and xXIGroupInfo structs to the common structs section. --- XI2proto.h | 57 ++++++++++++++++++++++++++-------------------------- XI2proto.txt | 12 +++++++++++ 2 files changed, 40 insertions(+), 29 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index 4b808ef..0ef0ece 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -194,6 +194,30 @@ typedef struct { uint16_t mask_len; /**< Length of mask in 4 byte units */ } xXIEventMask; +/** + * XKB modifier information. + * The effective modifier is a binary mask of base, latched, and locked + * modifiers. + */ +typedef struct +{ + uint32_t base_mods; /**< Logically pressed modifiers */ + uint32_t latched_mods; /**< Logically latched modifiers */ + uint32_t locked_mods; /**< Logically locked modifiers */ +} xXIModifierInfo; + +/** + * XKB group information. + * The effective group is the mathematical sum of base, latched, and locked + * group after group wrapping is taken into account. + */ +typedef struct +{ + uint8_t base_group; /**< Logically "pressed" group */ + uint8_t latched_group; /**< Logically latched group */ + uint8_t locked_group; /**< Logically locked group */ + uint8_t pad0; +} xXIGroupInfo; /************************************************************************************* @@ -304,13 +328,13 @@ typedef struct { FP1616 root_y; FP1616 win_x; FP1616 win_y; - uint16_t mask; - uint16_t deviceid; uint8_t same_screen; uint8_t pad0; - uint16_t pad1; + uint16_t buttons_len; + xXIModifierInfo mods; + xXIGroupInfo group; } xXIQueryPointerReply; -#define sz_xXIQueryPointerReply 40 +#define sz_xXIQueryPointerReply 52 /** * @struct xXIWarpPointerReq @@ -830,31 +854,6 @@ typedef struct * Default input event for pointer or keyboard input. */ -/** - * XKB modifier information. - * The effective modifier is a binary mask of base, latched, and locked - * modifiers. - */ -typedef struct -{ - uint32_t base_mods; /**< Logically pressed modifiers */ - uint32_t latched_mods; /**< Logically latched modifiers */ - uint32_t locked_mods; /**< Logically locked modifiers */ -} xXIModifierInfo; - -/** - * XKB group information. - * The effective group is the mathematical sum of base, latched, and locked - * group after group wrapping is taken into account. - */ -typedef struct -{ - uint8_t base_group; /**< Logically "pressed" group */ - uint8_t latched_group; /**< Logically latched group */ - uint8_t locked_group; /**< Logically locked group */ - uint8_t pad0; -} xXIGroupInfo; - typedef struct { uint8_t type; /**< Always GenericEvent */ diff --git a/XI2proto.txt b/XI2proto.txt index 3287c48..3122387 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -379,6 +379,10 @@ XI2. Clients should ignore this data. win_x: FP1616 win_y: FP1616 same_screen: BOOL + mods: MODIFIERINFO + group: GROUPINFO + buttons_len: CARD16 + buttons: SETofBUTTONMASK └─── Query a master pointer device for its current position. @@ -395,6 +399,14 @@ XI2. Clients should ignore this data. Pointer position relative to 'window' or 0 if 'same_screen' is false. same_screen TRUE if 'window' is on the same screen as the pointer. + mods + XKB modifier state on the paired device. + group + XKB group state on the paired device. + buttons_len + The length of 'buttons' in 4 byte units. + buttons + Button state. ┌─── XIWarpPointer From 0ae6581bc62b3b734c84b12e9a92d945d3e98aa7 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Sat, 16 May 2009 11:25:49 +1000 Subject: [PATCH 141/388] Add XIAnyButton and XIAnyKeysym. --- XI2.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/XI2.h b/XI2.h index eeee67f..8faec5e 100644 --- a/XI2.h +++ b/XI2.h @@ -39,6 +39,8 @@ /* Passive grab modifier */ #define XIAnyModifier (1 << 31) +#define XIAnyButton 0 +#define XIAnyKeysym 0 /* XIAllowEvents event-modes */ #define XIAsyncDevice 0 From f4f09d40e0fd94d267b280f2a82385dca1141347 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Sat, 16 May 2009 11:31:03 +1000 Subject: [PATCH 142/388] XI2.h: remove XI2Mask, add XISetMask and friends. XISetMask, XIClearMask, XIMaskIsSet serve to set, clear or check a bit in the provided array. XIMaskLen is a macro to get the minimum length of a mask for a given event type. They are expected to be common ways to deal with event masks, i.e. clients will do: unsigned char mask[XIMaskLen(XI_ButtonRelease)] = {0}; XISetMask(mask, XI_ButtonPress) XISetMask(mask, XI_ButtonRelease) Signed-off-by: Peter Hutterer --- XI2.h | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/XI2.h b/XI2.h index 8faec5e..cc8d3c4 100644 --- a/XI2.h +++ b/XI2.h @@ -89,9 +89,13 @@ #define XIButtonClass 1 #define XIValuatorClass 2 -/* XI2 mask macro */ -#define XIMASK(event) (1 << (event)) +/* XI2 event mask macros */ +#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 >> 3)) +/* Fake device ID's for event selection */ #define XIAllDevices 0 #define XIAllMasterDevices 1 From b32e5830c0acbdba4798fad107bf8404c978753c Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Sat, 16 May 2009 11:46:44 +1000 Subject: [PATCH 143/388] XI2proto: define Window, Cursor, Atom and Time as uint32_t. Since we're using stdint in the rest of the file, might as well ignore CARD32 here. --- XI2proto.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index 0ef0ece..4899c97 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -42,10 +42,10 @@ #include /* make sure types have right sizes for protocol structures. */ -#define Window CARD32 -#define Time CARD32 -#define Atom CARD32 -#define Cursor CARD32 +#define Window uint32_t +#define Time uint32_t +#define Atom uint32_t +#define Cursor uint32_t /** * XI2 Request opcodes From 8c2872367765170c37f829d635c97dc3d68861b7 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Sat, 16 May 2009 11:49:21 +1000 Subject: [PATCH 144/388] Document naming conventions for XI2proto.h. --- XI2proto.h | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/XI2proto.h b/XI2proto.h index 4899c97..e01f645 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -22,10 +22,36 @@ * */ +/* Conventions for this file: + * Names: + * structs: always typedef'd, prefixed with xXI, CamelCase + * struct members: lower_case_with_underscores + * Exceptions: reqType, ReqType, repType, RepType, sequenceNumber are + * named as such for historical reasons. + * request opcodes: X_XIRequestName as CamelCase + * defines: defines used in client applications must go in XI2.h + * defines used only in protocol handling: XISOMENAME + * + * Data types: unless there is a historical name for a datatype (e.g. + * Window), use stdint types specifying the size of the datatype. + * historical data type names must be defined and undefined at the top and + * end of the file. + * + * General: + * spaces, not tabs. + * structs specific to a request or reply added before the request + * definition. structs used in more than one request, reply or event + * appended to the common structs section before the definition of the + * first request. + * members of structs vertically aligned on column 16 if datatypes permit. + * otherwise alingned on next available 8n column. + */ + /** * @mainpage * @include XI2proto.txt */ + /** * @file XI2proto.h * Protocol definitions for the XI2 protocol. From 3aca2d6ba53c8ddf5c40ae4b1411e50134b404a5 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 15 May 2009 20:14:16 +1000 Subject: [PATCH 145/388] inputproto 1.9.99.9 --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4036868..623b2d5 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.8], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.9], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) # Require xorg-macros: XORG_CHANGELOG From f065f6c12aa5c2e79f1af38908e86d20a2efdc86 Mon Sep 17 00:00:00 2001 From: Benjamin Close Date: Tue, 19 May 2009 11:27:03 +1000 Subject: [PATCH 146/388] XI2proto.h: fix two comments referring to the old naming scheme. Signed-off-by: Peter Hutterer --- XI2proto.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index e01f645..8ca8f8b 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -428,7 +428,7 @@ typedef struct { * Name of new master follows struct (4-byte padded) */ typedef struct { - uint16_t type; /**< Always ::XICreateMasterDevice */ + uint16_t type; /**< Always ::XICreateMaster */ uint16_t length; /**< 2 + (namelen + padding)/4 */ uint16_t name_len; uint8_t send_core; @@ -440,7 +440,7 @@ typedef struct { * with the given master device. */ typedef struct { - uint16_t type; /**< Always ::XIRemoveMasterDevice */ + uint16_t type; /**< Always ::XIRemoveMaster */ uint16_t length; /**< 3 */ uint16_t deviceid; uint8_t return_mode; /**< ::XIAttachToMaster, ::XIFloating */ From 31f492bf9471fc593275fb95f97312db21439641 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 25 May 2009 12:14:12 +1000 Subject: [PATCH 147/388] Add XIGetSelectedEvents request and reply. Counterpart to XISelectEvents, used to retrieve event masks from the server. --- XI2proto.h | 30 +++++++++++++++++++++++++++++- XI2proto.txt | 22 ++++++++++++++++++++++ 2 files changed, 51 insertions(+), 1 deletion(-) diff --git a/XI2proto.h b/XI2proto.h index 8ca8f8b..331b831 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -98,10 +98,11 @@ #define X_XIChangeProperty 57 #define X_XIDeleteProperty 58 #define X_XIGetProperty 59 +#define X_XIGetSelectedEvents 60 /*@}*/ /** Number of XI requests */ -#define XI2REQUESTS (X_XIGetProperty - X_XIQueryPointer + 1) +#define XI2REQUESTS (X_XIGetSelectedEvents - X_XIQueryPointer + 1) /** Number of XI2 events */ #define XI2EVENTS (XI_LASTEVENT + 1) @@ -326,6 +327,33 @@ typedef struct { } xXISelectEventsReq; #define sz_xXISelectEventsReq 12 +/** + * @struct xXIGetSelectedEventsReq + * Query for selected events on a given window. + */ +typedef struct { + uint8_t reqType; /**< Input extension major code */ + uint8_t ReqType; /**< Always ::X_XIGetSelectedEvents */ + uint16_t length; /**< Length in 4 byte units */ + Window window; +} xXIGetSelectedEventsReq; +#define sz_xXIGetSelectedEventsReq 8 + +typedef struct { + uint8_t repType; /**< Input extension major opcode */ + uint8_t RepType; /**< Always ::X_XIGetSelectedEvents */ + uint16_t sequenceNumber; + uint32_t length; + uint16_t num_masks; /**< Number of xXIEventMask structs + trailing the reply */ + uint16_t pad0; + uint32_t pad1; + uint32_t pad2; + uint32_t pad3; + uint32_t pad4; + uint32_t pad5; +} xXIGetSelectedEventsReply; +#define sz_xXIGetSelectedEventsReply 32 /** * @struct xXIQueryPointerReq diff --git a/XI2proto.txt b/XI2proto.txt index 3122387..ef6c9e5 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -367,6 +367,28 @@ XI2. Clients should ignore this data. If 'mask_len' is 0, the event mask for the given device is cleared. + ┌─── + XIGetSelectedEvents + window: Window + ▶ + num_masks: CARD16 + masks: LISTofEVENTMASK + └─── + + + window + The window to select the events on. + num_masks + Number of items in mask. + masks + Selected event masks by this client. + + Masks are returned on a per-device basis, with masks for 'AllDevices' and + 'AllMasterDevices' returned separately. + + If 'num_masks' is 0, no events have been selected by this client on the + given window. + ┌─── XIQueryPointer window: Window From d0c6633f7bc2519c0b6c662a1f39a8ce56ab768a Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 27 May 2009 13:11:49 +1000 Subject: [PATCH 148/388] XI2proto.txt: remove one more keycode mentioning, fix typo --- XI2proto.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/XI2proto.txt b/XI2proto.txt index ef6c9e5..592a59d 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -981,7 +981,7 @@ XI2. Clients should ignore this data. XIPassiveUngrabDevice deviceid: DEVICEID detail: CARD32 - grab_type: { ButtonGrab, KeycodeGrab, KeysymGrab } + grab_type: { ButtonGrab, KeysymGrab } grab_window: Window num_modifiers: INT16 modifiers: MODIFIERINFO @@ -1004,7 +1004,7 @@ XI2. Clients should ignore this data. Number of elements in modifiers. This request has no effect if the matching button or keysym and - modifier combination is not grabbed b this client. + modifier combination is not grabbed by this client. ┌─── XIListProperties From 1b2dc24bf51a325ea3fafb46768467675b00be52 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 25 May 2009 15:48:25 +1000 Subject: [PATCH 149/388] Add Enter/FocusIn passive grabs. Same behaviour as button/keysym grabs but triggered on enter/leave and focus in/out events. --- XI2.h | 2 ++ XI2proto.txt | 67 ++++++++++++++++++++++++++++++++++++++++------------ 2 files changed, 54 insertions(+), 15 deletions(-) diff --git a/XI2.h b/XI2.h index cc8d3c4..6c58926 100644 --- a/XI2.h +++ b/XI2.h @@ -36,6 +36,8 @@ /* Passive grab types */ #define XIGrabtypeButton 0 #define XIGrabtypeKeysym 1 +#define XIGrabtypeEnter 2 +#define XIGrabtypeFocusIn 3 /* Passive grab modifier */ #define XIAnyModifier (1 << 31) diff --git a/XI2proto.txt b/XI2proto.txt index 592a59d..01f6c6b 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -883,7 +883,7 @@ XI2. Clients should ignore this data. XIPassiveGrabDevice deviceid: DEVICEID detail: CARD32 - grab_type: { GrabtypeButton, GrabtypeKeysym } + grab_type: GRABTYPE grab_window: Window cursor: Cursor owner_events: Bool @@ -898,6 +898,9 @@ XI2. Clients should ignore this data. modifiers_return: GRABMODIFIERINFO └─── + GRABTYPE { GrabtypeButton, GrabtypeKeysym, GrabtypeEnter, + GrabTypeFocusIn} + GRABMODIFIERINFO { status: Access modifiers: CARD32 } @@ -911,6 +914,7 @@ XI2. Clients should ignore this data. The device to establish the passive grab on. detail The button number, or key symbol to grab for. + Must be 0 for GrabtypeEnter and GrabtypeFocusIn. grab_type The type of grab to establish. grab_window @@ -950,7 +954,8 @@ XI2. Clients should ignore this data. by being included in the event-list. For either value of owner-events, unreported events are discarded. - In the future, the device is actively grabbed if: + In the future, if grab_type is GrabtypeButton or GrabtypeKeyboard, the + device is actively grabbed if: - the device is not grabbed, and - the specified modifier keys are down, and - the grab_type is GrabtypeButton and the button specified in detail @@ -960,40 +965,71 @@ XI2. Clients should ignore this data. - a passive grab on the same button/keysym + modifier combination does not exist on an ancestor of grab_window. + Otherwise, if grab_type is GrabtypeEnter or GrabtypeFocusIn, the + device is actively grabbed if: + - the device is not actively grabbed, and + - the specified modifier keys are down, and + - 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, + - a passive grab of the same grab_type + modifier combination does not + does not exist on an ancestor of grab_window. + 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 combinations in the same request. - The grab is released when all buttons or keysyms are - released, independent of the state of modifier keys. 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. - This request overrides all previous passive grabs by the same client - on the same button/key combinations on the same window. + A GrabtypeButton or GrabtypeKeyboard grab is released when all buttons + or keysyms 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. + 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. + + This request overrides all previous passive grabs by the same + client on the same button/key/enter/focus in + modifier combinations + on the same window. If some other client already has issued a XIPassiveGrabDevice request with the same button or keysym and modifier combination, the - failed modifier combinations is returned in modifiers_return. If - num_modifiers_return is zero, all passive grabs have been successful. + 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. + + If a button grab or enter grab activates, EnterNotify and LeaveNotify + events with mode Grab are generated as if the pointer were to suddenly + warp from its current position some position in the grab_window. + However, the pointer does not warp, and the pointer position is used + as both the initial and final positions for the events. + + If a keysym grab or focus grab activates, FocusIn and FocusOut events + with mode Grab are generated as if the focus were to change from the + current window to the grab_window. ┌─── XIPassiveUngrabDevice deviceid: DEVICEID detail: CARD32 - grab_type: { ButtonGrab, KeysymGrab } + grab_type: GRABTYPE grab_window: Window num_modifiers: INT16 modifiers: MODIFIERINFO └─── - Release an explicit passive grab for a button or keysym on - the specified input device. + Release an explicit passive grab on the specified input device. deviceid The device to establish the passive grab on. detail The button number or key symbol to ungrab. + Must be 0 for GrabtypeEnter and GrabtypeFocusIn. grab_type The type of grab to establish. grab_window @@ -1003,8 +1039,9 @@ XI2. Clients should ignore this data. num_modifiers Number of elements in modifiers. - This request has no effect if the matching button or keysym and - modifier combination is not grabbed by this client. + This request has no effect if the client does not have a passive grab + of the same type, same button or keysym (if applicable) and modifier + combination on the grab_window. ┌─── XIListProperties From 6b61bef5da91ca24d1bfcf9d314b8b8587c3e4fc Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 28 May 2009 08:20:37 +1000 Subject: [PATCH 150/388] Mirror the core enter/focus modes and add the passive grab mode. If an enter/focus grabs activates (or deactivates), send an extra set of enter/focus in (or leave/focus out) events to the grabbing client with mode XIPassiveGrabNotify. Signed-off-by: Peter Hutterer --- XI2.h | 8 ++++++++ XI2proto.txt | 13 ++++++++++++- 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/XI2.h b/XI2.h index 6c58926..4765853 100644 --- a/XI2.h +++ b/XI2.h @@ -33,6 +33,14 @@ #define XIPropertyCreated 1 #define XIPropertyModified 2 +/* Enter/Leave and Focus In/Out modes */ +#define XINotifyNormal 0 +#define XINotifyGrab 1 +#define XINotifyUngrab 2 +#define XINotifyWhileGrabbed 3 +#define XINotifyPassiveGrab 4 +#define XINotifyPassiveUngrab 5 + /* Passive grab types */ #define XIGrabtypeButton 0 #define XIGrabtypeKeysym 1 diff --git a/XI2proto.txt b/XI2proto.txt index 01f6c6b..91fde4e 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -1013,6 +1013,15 @@ XI2. Clients should ignore this data. with mode Grab are generated as if the focus were to change from the current window to the grab_window. + If an enter or focus in grab activates, additional EnterNotify events + with mode XIPassiveGrabNotify are generated as if the pointer or focus + were to suddenly warp from its current position to some position in + the grab window. These events are sent to the grabbing client only + and only if the grab event mask has selected for it. If such a passive + grab deactivates, addional LeaveNotify events with mode + XIPassiveUngrabNotify are generated and sent to the grabbing client + before the grab deactivates. + ┌─── XIPassiveUngrabDevice deviceid: DEVICEID @@ -1497,7 +1506,9 @@ EVENTHEADER { type: BYTE mode Normal pointer motion events have mode Normal. Pseudo-motion events when a grab activates have mode Grab, and pseudo-motion events when a - grab deactivates have mode Ungrab. + grab deactivates have mode Ungrab. Pseudo-motion events caused by the + activation or deactivation of a passive enter or focus in grab have mode + XIPassiveGrabNotify or XIPassiveUngrabNotify. detail Specifies the relation of the event window to the window the pointer entered or left. See the core protocol spec for details. From e102c504ec58e6bc4620e7cd01ea34de665e5fd9 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 27 May 2009 14:12:58 +1000 Subject: [PATCH 151/388] inputproto 1.9.99.10 --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 623b2d5..243e670 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.9], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.10], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) # Require xorg-macros: XORG_CHANGELOG From 8aff0836afaef4397f9df273cc90edeca1ab9641 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 29 May 2009 13:25:32 +1000 Subject: [PATCH 152/388] Specify modifier interactions with attached slave devices on passive grabs. --- XI2proto.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/XI2proto.txt b/XI2proto.txt index 91fde4e..785eb27 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -954,6 +954,16 @@ XI2. Clients should ignore this data. by being included in the event-list. For either value of owner-events, unreported events are discarded. + If deviceid specifies a master pointer, the modifiers of the paired + master keyboard are used. If deviceid specifies a slave pointer + the modifiers of the master keyboard paired with the attached master + pointers are used. If deviceid specifies a slave keyboard, the + modifiers of the attached master keyboard are used. Note that + activating a grab on a slave device detaches the device from its + master. In this case, the modifiers after activation of the grab are + from the slave device only and may be different to the modifier state + when the grab was triggered. + In the future, if grab_type is GrabtypeButton or GrabtypeKeyboard, the device is actively grabbed if: - the device is not grabbed, and From 0d75208a554577d652ca9e2856a4f12b0d720a1f Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 1 Jun 2009 09:12:42 +1000 Subject: [PATCH 153/388] Move the XI2 index into versions[] over to XI2.h --- XI.h | 4 +++- XI2.h | 9 +++++++++ 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/XI.h b/XI.h index dca949c..7b44399 100644 --- a/XI.h +++ b/XI.h @@ -135,6 +135,8 @@ SOFTWARE. #define XI_FOOTMOUSE "FOOTMOUSE" #define XI_JOYSTICK "JOYSTICK" +/* Indices into the versions[] array (XExtInt.c). Used as a index to + * retrieve the minimum version of XI from _XiCheckExtInit */ #define Dont_Check 0 #define XInput_Initial_Release 1 #define XInput_Add_XDeviceBell 2 @@ -142,7 +144,7 @@ SOFTWARE. #define XInput_Add_XChangeDeviceControl 4 #define XInput_Add_DevicePresenceNotify 5 #define XInput_Add_DeviceProperties 6 -#define XInput_2 7 +/* DO NOT ADD TO HERE -> XI2 */ #define XI_Absent 0 #define XI_Present 1 diff --git a/XI2.h b/XI2.h index 4765853..1347762 100644 --- a/XI2.h +++ b/XI2.h @@ -25,6 +25,15 @@ #ifndef _XI2_H_ #define _XI2_H_ +/* Indices into the versions[] array (XExtInt.c). Used as a index to + * retrieve the minimum version of XI from _XiCheckExtInit. + * For indices 0 to 6 see XI.h */ +#ifndef Dont_Check /* defined in XI.h */ +#define Dont_Check 0 +#endif +#define XInput_2_0 7 + + #define XI_2_Major 2 #define XI_2_Minor 0 From 56da196866d8c883b9b25b04dd584fbcb159ffd3 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 4 Jun 2009 13:35:42 +1000 Subject: [PATCH 154/388] XIQueryVersion may return a BadValue for major_version less than 2. Signed-off-by: Peter Hutterer --- XI2proto.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/XI2proto.txt b/XI2proto.txt index 785eb27..74aeed5 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -201,6 +201,8 @@ XI2. Clients should ignore this data. minor_version Minor XI2 version. + If major_version is less than 2, a BadValue error occurs. + ┌─── XIQueryDevice DEVICE deviceid From 6e20d1fc2517e68b17f9da2e94f78e9d64a8c408 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 8 Jun 2009 09:51:53 +1000 Subject: [PATCH 155/388] Document BadValue error for XIHierarchyEvents selection on devices. These events may only be selected on the XIAllDevices fake device. Signed-off-by: Peter Hutterer --- XI2proto.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/XI2proto.txt b/XI2proto.txt index 74aeed5..f0b3861 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -369,6 +369,9 @@ XI2. Clients should ignore this data. 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. + ┌─── XIGetSelectedEvents window: Window From 44f2419e56b006b8f182ea5746e9b6eef205ff37 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 8 Jun 2009 12:35:29 +1000 Subject: [PATCH 156/388] Update comment referring to an old naming scheme. Signed-off-by: Peter Hutterer --- XI2proto.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XI2proto.h b/XI2proto.h index 331b831..5ec377a 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -856,7 +856,7 @@ typedef struct ::XIFloatingSlave */ BOOL enabled; /**< TRUE if the device is enabled */ uint16_t pad; - uint32_t flags; /**< ::XIMasterAdded, ::XIMasterDeleted, + uint32_t flags; /**< ::XIMasterAdded, ::XIMasterRemoved, ::XISlaveAttached, ::XISlaveDetached, ::XISlaveAdded, ::XISlaveRemoved, ::XIDeviceEnabled, ::XIDeviceDisabled */ From 751f2d6c0fa88a6bfc380b57d72ae41ec790249d Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 8 Jun 2009 13:31:28 +1000 Subject: [PATCH 157/388] Rename XICreateMaster to XIAddMaster for consistency. We use add/remove for slave devices, add/remove for the hierarchy changed flags, so let's use add/remove to create a new device as well. Signed-off-by: Peter Hutterer --- XI2.h | 2 +- XI2proto.h | 4 ++-- XI2proto.txt | 20 ++++++++++---------- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/XI2.h b/XI2.h index 1347762..1ec2d44 100644 --- a/XI2.h +++ b/XI2.h @@ -84,7 +84,7 @@ #define XIDeviceDisabled (1 << 7) /* ChangeHierarchy constants */ -#define XICreateMaster 1 +#define XIAddMaster 1 #define XIRemoveMaster 2 #define XIAttachSlave 3 #define XIDetachSlave 4 diff --git a/XI2proto.h b/XI2proto.h index 5ec377a..b4c8ace 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -456,12 +456,12 @@ typedef struct { * Name of new master follows struct (4-byte padded) */ typedef struct { - uint16_t type; /**< Always ::XICreateMaster */ + uint16_t type; /**< Always ::XIAddMaster */ uint16_t length; /**< 2 + (namelen + padding)/4 */ uint16_t name_len; uint8_t send_core; uint8_t enable; -} xXICreateMasterInfo; +} xXIAddMasterInfo; /** * Delete a master device. Will automatically delete the master device paired diff --git a/XI2proto.txt b/XI2proto.txt index f0b3861..8dfae7a 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -510,18 +510,18 @@ XI2. Clients should ignore this data. changes: LISTofHIERARCHYCHANGES └─── - HIERARCHYCHANGE { CREATEMASTER, REMOVEMASTER, ATTACHSLAVE, DETACHSLAVE } + HIERARCHYCHANGE { ADDMASTER, REMOVEMASTER, ATTACHSLAVE, DETACHSLAVE } - HIERARCHYCHANGETYPE { CreateMaster, RemoveMaster, AttachSlave, DetachSlave } + HIERARCHYCHANGETYPE { AddMaster, RemoveMaster, AttachSlave, DetachSlave } CHANGEMODE { Float, Attach } - CREATEMASTER { type: HIERARCHYCHANGETYPE - length: CARD16 - name_len: CARD16 - send_core: BOOL - enable: BOOL - name: LISTofCHAR8 } + ADDMASTER { type: HIERARCHYCHANGETYPE + length: CARD16 + name_len: CARD16 + send_core: BOOL + enable: BOOL + name: LISTofCHAR8 } REMOVEMASTER { type: HIERARCHYCHANGETYPE length: CARD16 @@ -551,9 +551,9 @@ XI2. Clients should ignore this data. immediately. If an error occurs, processing stops at the current change and returns the number of successfully applied changes in the error. - CREATEMASTER creates a pair of master devices. + ADDMASTER creates a pair of master devices. type - Always CreateMaster. + Always AddMaster. length Length in 4 byte units. name_len From 03309cfbc19fc16b5ae25f8511b3ef28fcd66818 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 8 Jun 2009 14:23:27 +1000 Subject: [PATCH 158/388] xXIHierarchyEvent should list num_info, not num_devices. The structures following the request are referred to as "info", having a name of "num_devices" is misleading as the number of info structs does not always reflect the number of devices (e.g. if a device got removed). Signed-off-by: Peter Hutterer --- XI2proto.h | 4 ++-- XI2proto.txt | 14 +++++++------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index b4c8ace..e147e07 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -843,7 +843,7 @@ typedef struct */ /** - * Device hierarch information. + * Device hierarchy information. */ typedef struct { @@ -875,7 +875,7 @@ typedef struct ::XISlaveAttached, ::XISlaveDetached, ::XISlaveAdded, ::XISlaveRemoved, ::XIDeviceEnabled, ::XIDeviceDisabled */ - uint16_t num_devices; + uint16_t num_info; uint16_t pad0; uint32_t pad1; uint32_t pad2; diff --git a/XI2proto.txt b/XI2proto.txt index 8dfae7a..492d94f 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -1267,8 +1267,8 @@ EVENTHEADER { type: BYTE HierarchyEvent: EVENTHEADER flags: SETofHIERARCHYMASK - num_devices: CARD16 - deviceinfo: LISTofHIERARCHYINFO + num_info: CARD16 + info: LISTofHIERARCHYINFO └─── @@ -1283,15 +1283,15 @@ EVENTHEADER { type: BYTE flags Set of the changes that have occured, causing this event. - num_devices - The number of devices present in the hierarchy. - devices - The current hierarchy layout for each device. + num_info + The number of device info structs following the request. + info: + The current hierarchy information. An XIHierarchyEvent is sent whenever the device hierarchy been changed. The 'flags' specify all types of hierarchy modifiations that have occured. - For all devices, 'deviceinfo' details the hierarchy information after the + For all devices, 'info' details the hierarchy information after the modification of the hierarchy has occured. For each device specified with 'deviceid': - if 'type' is MasterPointer or MasterKeyboard, 'attachment' decribes the From 17a6ad094266cc14efb75cca36de0b8adff9d35b Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 8 Jun 2009 15:40:21 +1000 Subject: [PATCH 159/388] inputproto 1.9.99.11 --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 243e670..9df503d 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.10], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.11], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) # Require xorg-macros: XORG_CHANGELOG From f711dfae6872371ec41aeeecda9570a57d0a746c Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 12 Jun 2009 15:50:07 +1000 Subject: [PATCH 160/388] XI2proto: document XSetClientPointer behaviour on None window, etc. Signed-off-by: Peter Hutterer --- XI2proto.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/XI2proto.txt b/XI2proto.txt index 492d94f..7054c36 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -624,6 +624,18 @@ XI2. Clients should ignore this data. choose a client's ClientPointer device to provide the data, unless the client currently has a grab on another device. + If win is None, the ClientPointer for this client is set to the given + device. Otherwise, if win is a valid window, the ClientPointer for the + client owning this window is set to the given device. Otherwise, if win is + not a valid window but a client with the client mask equal to win exists, + this client's ClientPointer is set to the given device. + + If deviceid does not specify a master pointer or master keyboard, a + BadDevice error returned. + + If window does not specify a valid window or client ID and is not None, a + BadWindow error is returned. + ┌─── XIGetClientPointer win: Window From 1d59de593c5aac8e109fcb3c1173d4dc14742dee Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 12 Jun 2009 15:50:26 +1000 Subject: [PATCH 161/388] XISelectEventsReq should use win (not window), like all requests. Signed-off-by: Peter Hutterer --- XI2proto.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index e147e07..9661dfb 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -321,7 +321,7 @@ typedef struct { uint8_t reqType; /**< Input extension major code */ uint8_t ReqType; /**< Always ::X_XISelectEvents */ uint16_t length; /**< Length in 4 byte units */ - Window window; + Window win; uint16_t num_masks; uint16_t pad; } xXISelectEventsReq; @@ -335,7 +335,7 @@ typedef struct { uint8_t reqType; /**< Input extension major code */ uint8_t ReqType; /**< Always ::X_XIGetSelectedEvents */ uint16_t length; /**< Length in 4 byte units */ - Window window; + Window win; } xXIGetSelectedEventsReq; #define sz_xXIGetSelectedEventsReq 8 From bac0e02889392534138e8b98e516a0ea3c76847a Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 10 Jun 2009 15:12:39 +1000 Subject: [PATCH 162/388] Ensure XIAnyModifier is an unsigned int. Signed-off-by: Peter Hutterer --- XI2.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XI2.h b/XI2.h index 1ec2d44..7fc76f0 100644 --- a/XI2.h +++ b/XI2.h @@ -57,7 +57,7 @@ #define XIGrabtypeFocusIn 3 /* Passive grab modifier */ -#define XIAnyModifier (1 << 31) +#define XIAnyModifier (1U << 31) #define XIAnyButton 0 #define XIAnyKeysym 0 From 48cf9a56066c4b5a2136310da3cd6846dcf3b607 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 10 Jun 2009 15:13:03 +1000 Subject: [PATCH 163/388] Add note that bumping XI_LASTEVENT requires changes to the server. Signed-off-by: Peter Hutterer --- XI2.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/XI2.h b/XI2.h index 7fc76f0..06bc740 100644 --- a/XI2.h +++ b/XI2.h @@ -133,6 +133,9 @@ #define XI_RawEvent 12 #define XI_PropertyEvent 13 #define XI_LASTEVENT XI_PropertyEvent +/* 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. */ /* Event masks. * Note: the protocol spec defines a mask to be of (1 << type). Clients are From db98b817355ed12609cff077c4a12948ac41f88d Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Sun, 7 Jun 2009 17:51:04 +1000 Subject: [PATCH 164/388] Add a source field to the class information. In some cases it is required to know the source device of a particular device class. In the future we might also do lazy copying of classes, meaning that for a given device, each class may come from a different source. Hence the source id should be included for each class. Signed-off-by: Peter Hutterer --- XI2proto.h | 12 ++++++++---- XI2proto.txt | 9 +++++++++ 2 files changed, 17 insertions(+), 4 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index 9661dfb..1bb5a50 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -156,6 +156,8 @@ typedef struct { typedef struct { uint16_t type; /**< One of *class */ uint16_t length; /**< Length in 4 byte units */ + uint16_t sourceid; /**< source device for this class */ + uint16_t pad; } xXIAnyInfo; /** @@ -169,8 +171,8 @@ typedef struct { typedef struct { uint16_t type; /**< Always ButtonClass */ uint16_t length; /**< Length in 4 byte units */ + uint16_t sourceid; /**< source device for this class */ uint16_t num_buttons; /**< Number of buttons provide */ - uint16_t pad; } xXIButtonInfo; /** @@ -184,8 +186,8 @@ typedef struct { typedef struct { uint16_t type; /**< Always KeyClass */ uint16_t length; /**< Length in 4 byte units */ + uint16_t sourceid; /**< source device for this class */ uint16_t num_keycodes; /**< Number of keys provided */ - uint16_t pad; } xXIKeyInfo; /** @@ -198,13 +200,15 @@ typedef 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 */ Atom name; /**< Valuator name */ FP3232 min; /**< Min value */ FP3232 max; /**< Max value */ uint32_t resolution; /**< Resolutions in units/m */ - uint16_t number; /**< Valuator number */ uint8_t mode; /**< ModeRelative or ModeAbsolute */ - uint8_t pad; + uint8_t pad1; + uint16_t pad2; } xXIValuatorInfo; diff --git a/XI2proto.txt b/XI2proto.txt index 7054c36..ed50d43 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -224,16 +224,19 @@ XI2. Clients should ignore this data. BUTTONCLASS { type: ButtonClass length: CARD16 + sourceid: CARD16 num_buttons: CARD16 buttons: LISTofATOM } KEYCLASS { type: KeyClass length: CARD16 + sourceid: CARD16 num_keys: CARD16 keys: LISTofCARD32 } AXISCLASS { type: AxisClass length: CARD16 + sourceid: CARD16 axisnumber: CARD16 axisname: ATOM min: FP3232 @@ -290,6 +293,8 @@ XI2. Clients should ignore this data. Always ButtonClass. length Length in 4 byte units. + sourceid + The device this class originates from. num_buttons Number of buttons provided by the device. buttons @@ -302,6 +307,8 @@ XI2. Clients should ignore this data. Always KeyClass. length Length in 4 byte units. + sourceid + The device this class originates from. num_keys Number of keycodes provided by the device. keys @@ -312,6 +319,8 @@ XI2. Clients should ignore this data. Always AxisClass. length Length in 4 byte units. + sourceid + The device this class originates from. axisnumber Axis number of this axis. The axis number is in device-native order and potential axis mappings are ignored. From b2fb9f81a2a7af8656309420facd58ab610d5da1 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Sun, 14 Jun 2009 08:23:56 +1000 Subject: [PATCH 165/388] Include button state in XIButtonClasses. Without including the state in a button class, it is impossible to know the state of a device until this device has pressed or released another button (and thus sends an event). Signed-off-by: Peter Hutterer --- XI2proto.txt | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/XI2proto.txt b/XI2proto.txt index ed50d43..d5fac4e 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -225,7 +225,8 @@ XI2. Clients should ignore this data. BUTTONCLASS { type: ButtonClass length: CARD16 sourceid: CARD16 - num_buttons: CARD16 + buttons_len: CARD16 + state: SETofBUTTONMASK buttons: LISTofATOM } KEYCLASS { type: KeyClass @@ -301,6 +302,11 @@ XI2. Clients should ignore this data. List of Atoms specifying the type of each button. An atom of None specifies an unnamed button. Buttons are listed in the device-native order and potential button mappings are ignored. + state + The current button mask for this device. Each bit representing a + button is 1 if this button is logically down, or 0 otherwise. State a + multiple of 4-byte units and always contains at least num_buttons + bits. KeyClass: type From b0f7e24d210cb6d0a1c47cae39b54e56a5e996d8 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 16 Jun 2009 13:14:47 +1000 Subject: [PATCH 166/388] Include valuator value in XIValuatorClasses Signed-off-by: Peter Hutterer --- XI2proto.h | 1 + XI2proto.txt | 3 +++ 2 files changed, 4 insertions(+) diff --git a/XI2proto.h b/XI2proto.h index 1bb5a50..eada483 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -205,6 +205,7 @@ typedef struct { Atom name; /**< Valuator name */ FP3232 min; /**< Min value */ FP3232 max; /**< Max value */ + FP3232 value; /**< Last published value */ uint32_t resolution; /**< Resolutions in units/m */ uint8_t mode; /**< ModeRelative or ModeAbsolute */ uint8_t pad1; diff --git a/XI2proto.txt b/XI2proto.txt index d5fac4e..34f817e 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -242,6 +242,7 @@ XI2. Clients should ignore this data. axisname: ATOM min: FP3232 max: FP3232 + value: FP3232 resolution: CARD32 } XIQueryDevices details information about the requested input devices. @@ -341,6 +342,8 @@ XI2. Clients should ignore this data. Resolution in counts/meter. mode Relative or Absolute. + value + Last published axis value (if mode is absolute). 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. From a6edd59c440cae9cd8ac775bb4d67ab433f2aae3 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 17 Jun 2009 08:53:26 +1000 Subject: [PATCH 167/388] Use the term 'labels' to refer to button and axes labels. Signed-off-by: Peter Hutterer --- XI2proto.h | 2 +- XI2proto.txt | 14 +++++++------- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index eada483..19ed901 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -202,7 +202,7 @@ typedef struct { uint16_t length; /**< Length in 4 byte units */ uint16_t sourceid; /**< source device for this class */ uint16_t number; /**< Valuator number */ - Atom name; /**< Valuator name */ + Atom label; /**< Axis label */ FP3232 min; /**< Min value */ FP3232 max; /**< Max value */ FP3232 value; /**< Last published value */ diff --git a/XI2proto.txt b/XI2proto.txt index 34f817e..1739849 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -227,7 +227,7 @@ XI2. Clients should ignore this data. sourceid: CARD16 buttons_len: CARD16 state: SETofBUTTONMASK - buttons: LISTofATOM } + labels: LISTofATOM } KEYCLASS { type: KeyClass length: CARD16 @@ -239,7 +239,7 @@ XI2. Clients should ignore this data. length: CARD16 sourceid: CARD16 axisnumber: CARD16 - axisname: ATOM + label: ATOM min: FP3232 max: FP3232 value: FP3232 @@ -299,9 +299,9 @@ XI2. Clients should ignore this data. The device this class originates from. num_buttons Number of buttons provided by the device. - buttons - List of Atoms specifying the type of each button. An atom of None - specifies an unnamed button. Buttons are listed in the device-native + labels + List of Atoms specifying the label for each button. An atom of None + specifies an unlabeled button. Buttons are listed in the device-native order and potential button mappings are ignored. state The current button mask for this device. Each bit representing a @@ -331,8 +331,8 @@ XI2. Clients should ignore this data. axisnumber Axis number of this axis. The axis number is in device-native order and potential axis mappings are ignored. - axisname - Atom specifying the axis name. An Atom of None specifies an unnamed + label + Atom specifying the axis name. An Atom of None specifies an unlabeled axis. min Minimum value. From b40f48b15e3362cc7b5aeb800b7de072ce20e4aa Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 17 Jun 2009 09:09:56 +1000 Subject: [PATCH 168/388] inputproto 1.9.99.12 Signed-off-by: Peter Hutterer --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 9df503d..7673ae3 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.11], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.12], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) # Require xorg-macros: XORG_CHANGELOG From 3f0067b45e66ef8db785b67a36f015fd4e6a9f6c Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 18 Jun 2009 00:29:44 +1000 Subject: [PATCH 169/388] XIDeviceChangedEvents may occur on master devices too. Prime example is a change in the number of buttons due to the availability of a new slave device. Signed-off-by: Peter Hutterer --- XI2proto.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XI2proto.txt b/XI2proto.txt index 1739849..f69eeb1 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -1361,7 +1361,7 @@ EVENTHEADER { type: BYTE A SlaveSwitch 'reason' can only occur on a master device. If 'reason' is DeviceChange, the device itself has changed through other means (e.g. a physical device change) and 'source' is - undefined. A DeviceChange can only occur on a slave device. + undefined. source The source of the new classes. Only defined in 'reason' is SlaveSwitch. From 2367e52404761ab14e0f908432f736cfc0813f8b Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 23 Jun 2009 21:01:27 +1000 Subject: [PATCH 170/388] Add effective group and modifiers to XIGroupInfo/XIModifierInfo. Effective modifiers are easy to calculate but let's send them down the wire nonetheless. Effective group is slightly more complicated since group wrapping must be taken into account - sending it down the wire simplifies clients. Signed-off-by: Peter Hutterer --- XI2proto.h | 5 +++-- XI2proto.txt | 6 ++++-- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index 19ed901..b7b118b 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -236,6 +236,7 @@ typedef struct uint32_t base_mods; /**< Logically pressed modifiers */ uint32_t latched_mods; /**< Logically latched modifiers */ uint32_t locked_mods; /**< Logically locked modifiers */ + uint32_t effective_mods; /**< Effective modifiers */ } xXIModifierInfo; /** @@ -248,7 +249,7 @@ typedef struct uint8_t base_group; /**< Logically "pressed" group */ uint8_t latched_group; /**< Logically latched group */ uint8_t locked_group; /**< Logically locked group */ - uint8_t pad0; + uint8_t effective_group; /**< Effective group */ } xXIGroupInfo; @@ -393,7 +394,7 @@ typedef struct { xXIModifierInfo mods; xXIGroupInfo group; } xXIQueryPointerReply; -#define sz_xXIQueryPointerReply 52 +#define sz_xXIQueryPointerReply 56 /** * @struct xXIWarpPointerReq diff --git a/XI2proto.txt b/XI2proto.txt index f69eeb1..a776849 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -1400,10 +1400,12 @@ EVENTHEADER { type: BYTE MODIFIERINFO { base_mods: CARD32, latched_mods: CARD32, - locked_mods: CARD32} + locked_mods: CARD32, + effective_mods: CARD32} GROUPINFO { base_group: CARD8, latched_group: CARD8, - locked_group: CARD8 } + locked_group: CARD8, + effective_group: CARD8} 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 From 6280b53cdbb750ef2363f5b55346a4271678ddef Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Sun, 12 Jul 2009 16:19:19 +1000 Subject: [PATCH 171/388] inputproto 1.9.99.13 --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 7673ae3..61399e4 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.12], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.13], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) # Require xorg-macros: XORG_CHANGELOG From f345258bf44e018e04643ccc6f02f5e40267d78c Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 13 Jul 2009 14:37:13 +1000 Subject: [PATCH 172/388] Fix XIMaskLen macro. Signed-off-by: Peter Hutterer --- XI2.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XI2.h b/XI2.h index 06bc740..6323204 100644 --- a/XI2.h +++ b/XI2.h @@ -112,7 +112,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 >> 3)) +#define XIMaskLen(event) (((event + 7) >> 3)) /* Fake device ID's for event selection */ #define XIAllDevices 0 From c455db2c251770a729d2747e6f05d53c2563b428 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 13 Jul 2009 15:30:50 +1000 Subject: [PATCH 173/388] XI2: Split up raw events into multiple event types. Instead of a single XI_RawEvent type with subtypes to represent the actual event, split up the event into XI_RawButtonPress, XI_RawButtonRelease, etc. This way clients can select for specific raw events only instead of all of them at once. Note that raw events may be selected on master devices too, the server will route them through master devices. Signed-off-by: Peter Hutterer --- XI2.h | 16 ++++++++++++---- XI2proto.txt | 10 +++------- 2 files changed, 15 insertions(+), 11 deletions(-) diff --git a/XI2.h b/XI2.h index 6323204..2ed65f9 100644 --- a/XI2.h +++ b/XI2.h @@ -130,9 +130,13 @@ #define XI_FocusIn 9 #define XI_FocusOut 10 #define XI_HierarchyChanged 11 -#define XI_RawEvent 12 -#define XI_PropertyEvent 13 -#define XI_LASTEVENT XI_PropertyEvent +#define XI_PropertyEvent 12 +#define XI_RawKeyPress 13 +#define XI_RawKeyRelease 14 +#define XI_RawButtonPress 15 +#define XI_RawButtonRelease 16 +#define XI_RawMotion 17 +#define XI_LASTEVENT XI_RawMotion /* 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. */ @@ -152,7 +156,11 @@ #define XI_FocusInMask (1 << XI_FocusIn) #define XI_FocusOutMask (1 << XI_FocusOut) #define XI_HierarchyChangedMask (1 << XI_HierarchyChanged) -#define XI_RawEventMask (1 << XI_RawEvent) #define XI_PropertyEventMask (1 << XI_PropertyEvent) +#define XI_RawKeyPressMask (1 << XI_RawKeyPress) +#define XI_RawKeyReleaseMask (1 << XI_RawKeyRelease) +#define XI_RawButtonPressMask (1 << XI_RawButtonPress) +#define XI_RawButtonReleaseMask (1 << XI_RawButtonRelease) +#define XI_RawMotionMask (1 << XI_RawMotion) #endif /* _XI2_H_ */ diff --git a/XI2proto.txt b/XI2proto.txt index a776849..12926c5 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -1462,7 +1462,6 @@ EVENTHEADER { type: BYTE ┌─── RawEvent EVENTHEADER - eventtype: RAWTYPE detail: CARD32 valuators_len: CARD16 valuators: SETofVALUATORMASK @@ -1470,13 +1469,10 @@ EVENTHEADER { type: BYTE axisvalues_raw: LISTofFP3232 └─── - RAWTYPE { Motion, KeyPress, KeyRelease, ButtonPress, ButtonRelease } - A RawDevice event provides the information provided by the driver to the - client. RawDevice events are only generated for slave devices and provide - both the raw data as supplied by the driver and transformed data as used - in the server. Transformations include, but are not limited to, axis - clipping and acceleration. + client. RawDevice provide both the raw data as supplied by the driver and + 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 From 51244a1a4f7165d995c139ba1f0d03d8a1140015 Mon Sep 17 00:00:00 2001 From: Daniel Stone Date: Mon, 13 Jul 2009 16:49:33 +1000 Subject: [PATCH 174/388] Device{,Raw}Event: Add flags field. Add a flags member to DeviceEvent and DeviceKeyEvent; the only currently defined flag is KeyRepeat, indicating a repeat event (a la XKB detectable autorepeat), which is only valid for key events. Signed-off-by: Daniel Stone Signed-off-by: Peter Hutterer --- XI2.h | 5 +++++ XI2proto.h | 3 ++- XI2proto.txt | 15 +++++++++++++++ 3 files changed, 22 insertions(+), 1 deletion(-) diff --git a/XI2.h b/XI2.h index 2ed65f9..3af9f0f 100644 --- a/XI2.h +++ b/XI2.h @@ -108,6 +108,11 @@ #define XIButtonClass 1 #define XIValuatorClass 2 +/* Device event flags (common) */ +/* Device event flags (key events only) */ +#define XIKeyRepeat (1 << 16) +/* Device event flags (pointer events only) */ + /* XI2 event mask macros */ #define XISetMask(ptr, event) (((unsigned char*)(ptr))[(event)>>3] |= (1 << ((event) & 7))) #define XIClearMask(ptr, event) (((unsigned char*)(ptr))[(event)>>3] &= ~(1 << ((event) & 7))) diff --git a/XI2proto.h b/XI2proto.h index b7b118b..e6ec190 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -936,6 +936,7 @@ typedef struct uint16_t valuators_len; /**< Len of val. flags in 4 b units */ uint16_t sourceid; /**< The source device */ uint16_t pad0; + uint32_t flags; /**< ::XIKeyRepeat */ xXIModifierInfo mods; xXIGroupInfo group; } xXIDeviceEvent; @@ -962,7 +963,7 @@ typedef struct ::XI_KeyRelease */ uint16_t valuators_len; /**< Length of trailing valuator mask in 4 byte units */ - uint32_t pad1; + uint32_t flags; /**< ::XIKeyRepeat */ uint32_t pad2; } xXIRawEvent; diff --git a/XI2proto.txt b/XI2proto.txt index 12926c5..2f25fb1 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -1390,6 +1390,7 @@ EVENTHEADER { type: BYTE sourceid: DEVICEID mods: MODIFIERINFO group: GROUPINFO + flags: DEVICEEEVENTFLAGS buttons: SETofBUTTONMASK valuators: SETofVALUATORMASK axisvalues: LISTofFP3232 @@ -1407,6 +1408,10 @@ EVENTHEADER { type: BYTE locked_group: CARD8, effective_group: CARD8} + DEVICEEVENTFLAGS (all events): none + DEVICEEVENTFLAGS (key events only): { KeyRepeat } + DEVICEEVENTFLAGS (pointer events only): none + 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. @@ -1442,6 +1447,13 @@ EVENTHEADER { type: BYTE Bitmask of valuators provided in 'axisvalues'. axisvalues Valuator data in device-native resolution. + flags + Miscellaneous information about this event; the union of the + common flag set and either the key or pointer flag set, + depending on the event type. + 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. Modifier state in 'mods' is detailed as follows: base_mods @@ -1463,6 +1475,7 @@ EVENTHEADER { type: BYTE RawEvent EVENTHEADER detail: CARD32 + flags: DEVICEEVENTFLAGS valuators_len: CARD16 valuators: SETofVALUATORMASK axisvalues: LISTofFP3232 @@ -1482,6 +1495,8 @@ EVENTHEADER { type: BYTE The type of event that occured on the device. detail The button number or keycode. + flags + Flags as described in DeviceEvent::flags. valuators_len The length of 'valuators' in 4 byte units. valuators From 2a3dc6c47145356a7c9e1cef59165a7ed2f2e9e2 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 14 Jul 2009 16:15:06 +1000 Subject: [PATCH 175/388] Formatting fix, s/tabs/spaces/ --- XI2.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/XI2.h b/XI2.h index 3af9f0f..99f6ca2 100644 --- a/XI2.h +++ b/XI2.h @@ -34,8 +34,8 @@ #define XInput_2_0 7 -#define XI_2_Major 2 -#define XI_2_Minor 0 +#define XI_2_Major 2 +#define XI_2_Minor 0 /* Property event flags */ #define XIPropertyDeleted 0 From 1357361d6b2a72a3decd9307ca59cc7678ba3063 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 14 Jul 2009 16:15:19 +1000 Subject: [PATCH 176/388] Add the enter/leave detail defines, same as the core protocol ones. Signed-off-by: Peter Hutterer --- XI2.h | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/XI2.h b/XI2.h index 99f6ca2..9430480 100644 --- a/XI2.h +++ b/XI2.h @@ -50,6 +50,16 @@ #define XINotifyPassiveGrab 4 #define XINotifyPassiveUngrab 5 +/* Enter/Leave and focus In/out detail */ +#define XINotifyAncestor 0 +#define XINotifyVirtual 1 +#define XINotifyInferior 2 +#define XINotifyNonlinear 3 +#define XINotifyNonlinearVirtual 4 +#define XINotifyPointer 5 +#define XINotifyPointerRoot 6 +#define XINotifyDetailNone 7 + /* Passive grab types */ #define XIGrabtypeButton 0 #define XIGrabtypeKeysym 1 From aaefb1e12229cc7bed40f6aaec3641db840aa4f2 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 13 Jul 2009 16:05:07 +1000 Subject: [PATCH 177/388] inputproto 1.9.99.14 Signed-off-by: Peter Hutterer --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 61399e4..e4f3fa7 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.13], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.14], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) # Require xorg-macros: XORG_CHANGELOG From 006afb766ac1d01ad9d57035af56a5b48c6ec5d3 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 20 Jul 2009 16:25:08 +1000 Subject: [PATCH 178/388] XI2: remove Keysym grabs, use Keycode grabs instead. Keysym grabs are tricky to get right for applications that are more complicated than demo applications. otoh, we know keycode grabs are working. So let's go with keycode grabs for now and add keysym grabs later when we've sorted out the details. Signed-off-by: Peter Hutterer --- XI2.h | 4 ++-- XI2proto.txt | 18 +++++++++--------- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/XI2.h b/XI2.h index 9430480..6ba1377 100644 --- a/XI2.h +++ b/XI2.h @@ -62,14 +62,14 @@ /* Passive grab types */ #define XIGrabtypeButton 0 -#define XIGrabtypeKeysym 1 +#define XIGrabtypeKeycode 1 #define XIGrabtypeEnter 2 #define XIGrabtypeFocusIn 3 /* Passive grab modifier */ #define XIAnyModifier (1U << 31) #define XIAnyButton 0 -#define XIAnyKeysym 0 +#define XIAnyKeycode 0 /* XIAllowEvents event-modes */ #define XIAsyncDevice 0 diff --git a/XI2proto.txt b/XI2proto.txt index 2f25fb1..7c41deb 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -933,13 +933,13 @@ XI2. Clients should ignore this data. modifiers_return: GRABMODIFIERINFO └─── - GRABTYPE { GrabtypeButton, GrabtypeKeysym, GrabtypeEnter, + GRABTYPE { GrabtypeButton, GrabtypeKeycode, GrabtypeEnter, GrabTypeFocusIn} GRABMODIFIERINFO { status: Access modifiers: CARD32 } - Establish an explicit passive grab for a button or keysym + Establish an explicit passive grab for a button or keycode on the specified input device. cursor @@ -1004,10 +1004,10 @@ XI2. Clients should ignore this data. - the device is not grabbed, and - the specified modifier keys are down, and - the grab_type is GrabtypeButton and the button specified in detail - is logically pressed or the grab_type is GrabtypeKeysym and the - keysym specified in detail is logically pressed, and + is logically pressed or the grab_type is GrabtypeKeycode and the + keycode specified in detail is logically pressed, and - the grab_window contains the pointer, and - - a passive grab on the same button/keysym + modifier + - a passive grab on the same button/keycode + modifier combination does not exist on an ancestor of grab_window. Otherwise, if grab_type is GrabtypeEnter or GrabtypeFocusIn, the @@ -1027,7 +1027,7 @@ XI2. Clients should ignore this data. combinations in the same request. A GrabtypeButton or GrabtypeKeyboard grab is released when all buttons - or keysyms are released, independent of the state of modifier keys. + 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. @@ -1040,7 +1040,7 @@ XI2. Clients should ignore this data. on the same window. If some other client already has issued a XIPassiveGrabDevice request - with the same button or keysym and modifier combination, the + 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 @@ -1054,7 +1054,7 @@ XI2. Clients should ignore this data. However, the pointer does not warp, and the pointer position is used as both the initial and final positions for the events. - If a keysym grab or focus grab activates, FocusIn and FocusOut events + If a keycode grab or focus grab activates, FocusIn and FocusOut events with mode Grab are generated as if the focus were to change from the current window to the grab_window. @@ -1094,7 +1094,7 @@ XI2. Clients should ignore this data. Number of elements in modifiers. This request has no effect if the client does not have a passive grab - of the same type, same button or keysym (if applicable) and modifier + of the same type, same button or keycode (if applicable) and modifier combination on the grab_window. ┌─── From 0e7af09fcedc3f6f86306dbf2c683d065fc41f29 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 22 Jul 2009 12:11:13 +1000 Subject: [PATCH 179/388] inputproto 1.9.99.15 Signed-off-by: Peter Hutterer --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index e4f3fa7..9487382 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.14], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.15], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) # Require xorg-macros: XORG_CHANGELOG From 7cf46d64e0f2816f76ff3e23a77e5414a8625d10 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 27 Jul 2009 14:20:38 +1000 Subject: [PATCH 180/388] XI2proto.txt: update list of XI2 event types. Signed-off-by: Peter Hutterer --- XI2proto.txt | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/XI2proto.txt b/XI2proto.txt index 7c41deb..2119aff 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -1262,9 +1262,16 @@ Version 2.0: ButtonPress ButtonRelease Motion - RawEvent + RawKeyPress + RawKeyRelease + RawButtonPress + RawButtonRelease + RawMotion Enter Leave + FocusIn + FocusOut + PropertyEvent All events have a set of common fields specified as EVENTHEADER. From 0542581edcef2795c613921e66736871b44408d7 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 27 Jul 2009 14:29:00 +1000 Subject: [PATCH 181/388] XI2proto.txt: Add some XI1 vs. XI2 interoperability descriptions. Signed-off-by: Peter Hutterer --- XI2proto.txt | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/XI2proto.txt b/XI2proto.txt index 2119aff..a36f1dd 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -63,7 +63,37 @@ COMPLEXFIELDTYPE: { name of subfield: type of subfield, 3. Interoperability between version 1.x and 2.0 -FIXME +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 + +XI2 provides a larger range for some fields than XI1. As a result, XI1 clients +may not receive data an XI2 client receives. +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 + 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. + + +3.2 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. +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 + +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. ❧❧❧❧❧❧❧❧❧❧❧ From 4b414dcdbb5641ea528ccc212584f9dac816b571 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 27 Jul 2009 15:51:17 +1000 Subject: [PATCH 182/388] XI2proto.h: Remove special doxygen tags. The protocol header does not include enough documentation to make the use of doxygen really worthwile. Special doxygen tags beyond the very simple use of /** and /**< contribute too much to the noise and make it hard to actually read the code itself. While no extra tags are added now, a run of doxygen over XI2proto and XI.h still produces an acceptable output. Signed-off-by: Peter Hutterer --- XI2proto.h | 67 ++++-------------------------------------------------- 1 file changed, 4 insertions(+), 63 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index e6ec190..8fb506d 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -48,12 +48,6 @@ */ /** - * @mainpage - * @include XI2proto.txt - */ - -/** - * @file XI2proto.h * Protocol definitions for the XI2 protocol. * This file should not be included by clients that merely use XI2, but do not * need the wire protocol. Such clients should include XI2.h, or the matching @@ -75,8 +69,6 @@ /** * XI2 Request opcodes - * @addtogroup XI2Requests - * @{ */ #define X_XIQueryPointer 40 #define X_XIWarpPointer 41 @@ -99,7 +91,6 @@ #define X_XIDeleteProperty 58 #define X_XIGetProperty 59 #define X_XIGetSelectedEvents 60 -/*@}*/ /** Number of XI requests */ #define XI2REQUESTS (X_XIGetSelectedEvents - X_XIQueryPointer + 1) @@ -121,7 +112,6 @@ typedef struct { } FP3232; /** - * \struct xXIDeviceInfo * Struct to describe a device. * * For a MasterPointer or a MasterKeyboard, 'attachment' specifies the @@ -129,8 +119,6 @@ typedef struct { * For a SlaveKeyboard or SlavePointer, 'attachment' specifies the master * device this device is attached to. * For a FloatingSlave, 'attachment' is undefined. - * - * @see xXIQueryDeviceReq */ typedef struct { uint16_t deviceid; @@ -145,13 +133,9 @@ typedef struct { } xXIDeviceInfo; /** - * \struct xXIAnyInfo * Default template for a device class. * A device class is equivalent to a device's capabilities. Multiple classes * are supported per device. - * - * @see xXIQueryDeviceReq - * @see xXIDeviceChangedEvent */ typedef struct { uint16_t type; /**< One of *class */ @@ -164,9 +148,6 @@ typedef struct { * Denotes button capability on a device. * Struct is followed by num_buttons * Atom that names the buttons in the * device-native setup (i.e. ignoring button mappings). - * - * @see xXIQueryDeviceReq - * @see xXIDeviceChangedEvent */ typedef struct { uint16_t type; /**< Always ButtonClass */ @@ -179,9 +160,6 @@ typedef struct { * Denotes key capability on a device. * Struct is followed by num_keys * CARD32 that lists the keycodes available * on the device. - * - * @see xXIQueryDeviceReq - * @see xXIDeviceChangedEvent */ typedef struct { uint16_t type; /**< Always KeyClass */ @@ -193,9 +171,6 @@ typedef struct { /** * Denotes an valuator capability on a device. * One XIValuatorInfo describes exactly one valuator (axis) on the device. - * - * @see xXIQueryDevice - * @see xXIDeviceChangedEvent */ typedef struct { uint16_t type; /**< Always ValuatorClass */ @@ -218,8 +193,6 @@ typedef struct { * Struct is followed by (mask_len * CARD8), with each bit set representing * the event mask for the given type. A mask bit represents an event type if * (mask == (1 << type)). - * - * @see XISelectEvents */ typedef struct { uint16_t deviceid; /**< Device id to select for */ @@ -260,7 +233,6 @@ typedef struct *************************************************************************************/ /** - * @struct xXIQueryVersionReq * Query the server for the supported X Input extension version. */ @@ -289,12 +261,9 @@ typedef struct { #define sz_xXIQueryVersionReply 32 /** - * @struct xXIQueryDeviceReq * Query the server for information about a specific device or all input * devices. - * */ - typedef struct { uint8_t reqType; /**< Input extension major code */ uint8_t ReqType; /**< Always ::X_XIQueryDevice */ @@ -320,7 +289,6 @@ typedef struct { #define sz_xXIQueryDeviceReply 32 /** - * @struct xXISelectEventsReq * Select for events on a given window. */ typedef struct { @@ -334,7 +302,6 @@ typedef struct { #define sz_xXISelectEventsReq 12 /** - * @struct xXIGetSelectedEventsReq * Query for selected events on a given window. */ typedef struct { @@ -362,7 +329,6 @@ typedef struct { #define sz_xXIGetSelectedEventsReply 32 /** - * @struct xXIQueryPointerReq * Query the given device's screen/window coordinates. */ @@ -397,7 +363,6 @@ typedef struct { #define sz_xXIQueryPointerReply 56 /** - * @struct xXIWarpPointerReq * Warp the given device's pointer to the specified position. */ @@ -419,7 +384,6 @@ typedef struct { #define sz_xXIWarpPointerReq 28 /** - * @struct xXIChangeCursorReq * Change the given device's sprite to the given cursor. */ @@ -435,7 +399,6 @@ typedef struct { #define sz_xXIChangeCursorReq 16 /** - * @struct xXIChangeHierarchyReq * Modify the device hierarchy. */ @@ -506,7 +469,6 @@ typedef struct { /** - * @struct xXISetClientPointerReq * Set the window/client's ClientPointer. */ typedef struct { @@ -520,7 +482,6 @@ typedef struct { #define sz_xXISetClientPointerReq 12 /** - * @struct xXIGetClientPointerReq * Query the given window/client's ClientPointer setting. */ typedef struct { @@ -548,7 +509,6 @@ typedef struct { #define sz_xXIGetClientPointerReply 32 /** - * @struct xXISetFocusReq * Set the input focus to the specified window. */ typedef struct { @@ -563,7 +523,6 @@ typedef struct { #define sz_xXISetFocusReq 16 /** - * @struct xXIGetDeviceFocusReq * Query the current input focus. */ typedef struct { @@ -591,7 +550,6 @@ typedef struct { /** - * @struct xXIGrabDeviceReq * Grab the given device. */ typedef struct { @@ -637,7 +595,6 @@ typedef struct { #define sz_xXIGrabDeviceReply 32 /** - * @struct xXIUngrabDeviceReq * Ungrab the specified device. * */ @@ -653,7 +610,6 @@ typedef struct { /** - * @struct xXIAllowEventsReq * Allow or replay events on the specified grabbed device. */ typedef struct { @@ -669,7 +625,6 @@ typedef struct { /** - * @struct xXIPassiveGrabDeviceReq * Passively grab the device. */ typedef struct { @@ -707,7 +662,6 @@ typedef struct { #define sz_xXIPassiveGrabDeviceReply 32 /** - * @struct xXIPassiveUngrabDeviceReq * Delete a passive grab for the given device. */ typedef struct { @@ -725,7 +679,6 @@ typedef struct { #define sz_xXIPassiveUngrabDeviceReq 20 /** - * @struct xXIListPropertiesReq * List all device properties on the specified device. */ typedef struct { @@ -753,7 +706,6 @@ typedef struct { #define sz_xXIListPropertiesReply 32 /** - * @struct xXIChangePropertyReq * Change a property on the specified device. */ typedef struct { @@ -770,7 +722,6 @@ typedef struct { #define sz_xXIChangePropertyReq 20 /** - * @struct xXIDeletePropertyReq * Delete the specified property. */ typedef struct { @@ -784,7 +735,6 @@ typedef struct { #define sz_xXIDeletePropertyReq 12 /** - * @struct xXIGetPropertyReq * Query the specified property's values. */ typedef struct { @@ -828,7 +778,6 @@ typedef struct { *************************************************************************************/ /** - * @struct xXIGenericDeviceEvent * Generic XI2 event header. All XI2 events use the same header. */ typedef struct @@ -842,12 +791,6 @@ typedef struct Time time; } xXIGenericDeviceEvent; -/** - * @struct xXIHierarchyEvent - * The device hierarchy has been modified. This event includes the device - * hierarchy after the modification has been applied. - */ - /** * Device hierarchy information. */ @@ -868,6 +811,10 @@ typedef struct ::XIDeviceEnabled, ::XIDeviceDisabled */ } xXIHierarchyInfo; +/** + * The device hierarchy has been modified. This event includes the device + * hierarchy after the modification has been applied. + */ typedef struct { uint8_t type; /**< Always GenericEvent */ @@ -888,7 +835,6 @@ typedef struct } xXIHierarchyEvent; /** - * @struct xXIDeviceChangedEvent * A device has changed capabilities. */ typedef struct @@ -910,10 +856,8 @@ typedef struct } xXIDeviceChangedEvent; /** - * @struct xXIDeviceEvent * Default input event for pointer or keyboard input. */ - typedef struct { uint8_t type; /**< Always GenericEvent */ @@ -943,7 +887,6 @@ typedef struct /** - * @struct xXIRawEvent * Sent when an input event is generated. RawEvents include valuator * information in both device-specific data (i.e. unaccelerated) and * processed data (i.e. accelerated, if applicable). @@ -968,7 +911,6 @@ typedef struct } xXIRawEvent; /** - * @struct xXIEnterEvent * Note that the layout of root, event, child, root_x, root_y, event_x, * event_y must be identical to the xXIDeviceEvent. */ @@ -1005,7 +947,6 @@ typedef xXIEnterEvent xXIFocusInEvent; typedef xXIEnterEvent xXIFocusOutEvent; /** - * @struct xXIPropertyEvent * Sent when a device property is created, modified or deleted. Does not * include property data, the client is required to query the data. */ From 7b988fcae5135d064388084ef190966c3e38702c Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 28 Jul 2009 10:10:10 +1000 Subject: [PATCH 183/388] XI2proto.txt: padding bytes must be zero. Padding bytes zeroed out ensures that future versions of the XI2 protcol may use these padding bytes with a defined state. The server should ignore padding bytes depending on the client's version anyway but better safe than sorry. Signed-off-by: Peter Hutterer --- XI2proto.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/XI2proto.txt b/XI2proto.txt index a36f1dd..4ad861e 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -206,7 +206,8 @@ future revisions of XI2. A client must always retrieve the exact length of the protocol reply from the connection, even if the reply is longer than defined for the XI2 version supported by the client. Additional bytes in a request may include data supported in later versions of -XI2. Clients should ignore this data. +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 From 9f5d450fda41f936a8e12863aec544d69b30132f Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 28 Jul 2009 10:38:21 +1000 Subject: [PATCH 184/388] XIproto.txt: clarify that the ClientPointer is set, even if implicitly. It is indistinguishable for the client whether the the server chooses a ClientPointer or whether the CP was set through an XISetClientPointer request. The only thing that matters is that a device was actually assigned and will be used in the future. Signed-off-by: Peter Hutterer --- XI2proto.txt | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/XI2proto.txt b/XI2proto.txt index 4ad861e..ab075f7 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -698,10 +698,14 @@ are required to be 0. win The window or client ID. set - TRUE if the client has an explicitly set ClientPointer. + TRUE if the client has a ClientPointer set. deviceid The master pointer that acts as a ClientPointer if 'set' is TRUE. + 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. + ┌─── XISetFocus focus: Window From d0b1e55b876a29a7c820ec12d7b9cb5e081e1944 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 28 Jul 2009 10:53:08 +1000 Subject: [PATCH 185/388] XI2proto.txt: grabbing a slave does not detach it anymore. Signed-off-by: Peter Hutterer --- XI2proto.txt | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/XI2proto.txt b/XI2proto.txt index ab075f7..90690a3 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -1028,11 +1028,7 @@ are required to be 0. master keyboard are used. If deviceid specifies a slave pointer the modifiers of the master keyboard paired with the attached master pointers are used. If deviceid specifies a slave keyboard, the - modifiers of the attached master keyboard are used. Note that - activating a grab on a slave device detaches the device from its - master. In this case, the modifiers after activation of the grab are - from the slave device only and may be different to the modifier state - when the grab was triggered. + modifiers of the attached master keyboard are used. In the future, if grab_type is GrabtypeButton or GrabtypeKeyboard, the device is actively grabbed if: From b877309713930f92f04e2485bc40e1b6730d7e77 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 28 Jul 2009 11:12:26 +1000 Subject: [PATCH 186/388] XI2proto.txt: passive grabs can take XIAll{Master}Devices. Signed-off-by: Peter Hutterer --- XI2proto.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/XI2proto.txt b/XI2proto.txt index 90690a3..6349e19 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -951,7 +951,7 @@ are required to be 0. ┌─── XIPassiveGrabDevice - deviceid: DEVICEID + deviceid: DEVICE detail: CARD32 grab_type: GRABTYPE grab_window: Window @@ -981,7 +981,8 @@ are required to be 0. The cursor to display for the duration of the grab. If grab_type is not GrabtypeButton, this argument is ignored. deviceid - The device to establish the passive grab on. + The device to establish the passive grab on or AllDevices or + AllMasterDevices. detail The button number, or key symbol to grab for. Must be 0 for GrabtypeEnter and GrabtypeFocusIn. From 26f244fadc188cc76f53c82c10bc3b308964f20c Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 28 Jul 2009 11:12:50 +1000 Subject: [PATCH 187/388] XI2proto.txt: sourceid on DeviceChanged is the device. Signed-off-by: Peter Hutterer --- XI2proto.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/XI2proto.txt b/XI2proto.txt index 6349e19..f1cbb1e 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -1400,10 +1400,9 @@ EVENTHEADER { type: BYTE A SlaveSwitch 'reason' can only occur on a master device. If 'reason' is DeviceChange, the device itself has changed through other means (e.g. a physical device change) and 'source' is - undefined. + the device itself. source - The source of the new classes. Only defined in 'reason' is - SlaveSwitch. + The source of the new classes. num_classes Number of 'classes' provided. classes From 5e76f4ca69fedab770280854ab238587eb5e10fb Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 28 Jul 2009 10:12:06 +1000 Subject: [PATCH 188/388] XI2proto.txt: typo fixes and minor clarifications. Signed-off-by: Peter Hutterer --- XI2proto.txt | 64 ++++++++++++++++++++++++++-------------------------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/XI2proto.txt b/XI2proto.txt index f1cbb1e..ec930d3 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -224,7 +224,7 @@ are required to be 0. server sends the highest version it supports, but no higher than the requested version. Major versions changes can introduce incompatibilities in existing functionality, minor version changes introduce only backward - compatible changes. It is the clients responsibility to ensure that the + compatible changes. It is the client's responsibility to ensure that the server supports a version which is compatible with its expectations. major_version @@ -251,7 +251,7 @@ are required to be 0. name: LISTofCHAR8 classes: LISTofCLASS } - CLASS { BUTTONCLASS KEYCLASS, AXISCLASS } + CLASS { BUTTONCLASS, KEYCLASS, AXISCLASS } BUTTONCLASS { type: ButtonClass length: CARD16 @@ -296,25 +296,23 @@ are required to be 0. If the device is a slave pointer, 'use' is SlavePointer. If the device is a slave keyboard, 'use' is SlaveKeyboard. If the device is a floating slave, 'use' is FloatingSlave. - attachment If the device is a master pointer or a master keyboard, 'attachment' specifies the paired master keyboard, or the paired master pointer, respectively. If the device is a non-floating slave device 'attachment' specifies the master device this device is attached to. If the device is a floating slave, 'attachment' is undefined. - enabled Zero if the device is disabled, non-zero otherwise. num_classes Number of 'classes' provided. name_len - Length of the name in bytes. + Length of the name in bytes not including padding. classes Details the available classes provided by the device in an undefined order. name - The device's name, padded to a multiple of 4 bytes. + The device's name. padded to a multiple of 4 bytes. For all classes, 'type' specifies the device class. Clients are required to ignore unknown device classes. The 'length' field specifies the length @@ -331,14 +329,14 @@ are required to be 0. num_buttons Number of buttons provided by the device. labels - List of Atoms specifying the label for each button. An atom of None + List of Atoms specifying the label for each button. An Atom of None specifies an unlabeled button. Buttons are listed in the device-native - order and potential button mappings are ignored. + order regardless of the current button mapping. state - The current button mask for this device. Each bit representing a - button is 1 if this button is logically down, or 0 otherwise. State a - multiple of 4-byte units and always contains at least num_buttons - bits. + The current button mask for this device after button mapping is + applied. Each bit representing a button is 1 if this button is + logically down, or 0 otherwise. State is a multiple of 4-byte units + and always contains at least num_buttons bits. KeyClass: type @@ -394,11 +392,11 @@ are required to be 0. window The window to select the events on. num_masks - Number of items in mask. + Number of items in 'masks'. deviceid Numerical deviceid, or AllDevices, or AllMasterDevices. mask_len - Length of mask in 4 byte units. + Length of 'mask' in 4 byte units. mask Event mask. An event mask for an event type T is defined as (1 << T). @@ -429,16 +427,17 @@ are required to be 0. masks: LISTofEVENTMASK └─── - window The window to select the events on. num_masks - Number of items in mask. + Number of items in 'masks'. masks Selected event masks by this client. Masks are returned on a per-device basis, with masks for 'AllDevices' and - 'AllMasterDevices' returned separately. + 'AllMasterDevices' returned separately. A client can calculate the + effective mask for a device with a bitwise OR of the AllDevices, the + AllMasterDevices and the device-specific mask. If 'num_masks' is 0, no events have been selected by this client on the given window. @@ -474,7 +473,7 @@ are required to be 0. win_y Pointer position relative to 'window' or 0 if 'same_screen' is false. same_screen - TRUE if 'window' is on the same screen as the pointer. + True if 'window' is on the same screen as the pointer. mods XKB modifier state on the paired device. group @@ -596,9 +595,10 @@ are required to be 0. changes The list of changes. - The server processes the changes one by one and applies changes - immediately. If an error occurs, processing stops at the current change - and returns the number of successfully applied changes in the error. + The server processes the changes in the order received from the client and + applies each requested change immediately. If an error occurs, processing + stops at the current change and returns the number of successfully applied + changes in the error. ADDMASTER creates a pair of master devices. type @@ -608,9 +608,9 @@ are required to be 0. name_len Length of 'name' in bytes. send_core - TRUE if the device should send core events. + True if the device should send core events. enable - TRUE if the device is to be enabled immediately. + True if the device is to be enabled immediately. name The name for the new master devices. The master pointer's name is automatically appended with " pointer", the master keyboard's name is @@ -632,7 +632,8 @@ are required to be 0. return_pointer return_keyboard The master pointer and master keyboard to attach slave devices to, if - 'return_mode' is Attach. + 'return_mode' is Attach. If 'return_mode' is Float, 'return_pointer' + and 'return_keyboard' are undefined. Removing a master pointer removes the paired master keyboard and vice versa. @@ -698,9 +699,9 @@ are required to be 0. win The window or client ID. set - TRUE if the client has a ClientPointer set. + True if the client has a ClientPointer set. deviceid - The master pointer that acts as a ClientPointer if 'set' is TRUE. + The master pointer that acts as a ClientPointer if 'set' is True. No difference is made between a ClientPointer set explicitly through XISetClientPointer and a ClientPointer implicitly assigned by the server @@ -788,7 +789,6 @@ are required to be 0. status Success or the reason why the grab could not be established. - The masks parameter specifies which events the client wishes to receive while the device is grabbed. @@ -850,8 +850,8 @@ are required to be 0. time A valid server time or CurrentTime. - The request has no effect if the specified time is earlier - than the last-device-grab time or is later than the current server time. + The request has no effect if the specified time is earlier than the + last-device-grab time or is later than the current server time. This request generates FocusIn and FocusOut events. An XIUngrabDevice is performed automatically if the event window for an active device grab becomes not viewable. @@ -1370,7 +1370,7 @@ EVENTHEADER { type: BYTE - if 'type' is FloatingSlave device, 'attachment' is undefined. enabled - TRUE if the device is enabled and can send events. A disabled master + True if the device is enabled and can send events. A disabled master device will not forward events from an attached, enabled slave device. @@ -1534,7 +1534,7 @@ EVENTHEADER { type: BYTE detail The button number or keycode. flags - Flags as described in DeviceEvent::flags. + Flags as described in DeviceEvent. valuators_len The length of 'valuators' in 4 byte units. valuators @@ -1609,7 +1609,7 @@ EVENTHEADER { type: BYTE Specifies the relation of the event window to the window the pointer entered or left. See the core protocol spec for details. same_screen - TRUE if the event window is on the same screen as the pointer's root + True if the event window is on the same screen as the pointer's root window. focus If the event window is the focus window or an inferior of the focus From 221aed39ac45ce4bf3b28c7956bc00ea3c9dbf57 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 28 Jul 2009 11:15:12 +1000 Subject: [PATCH 189/388] XI2proto.txt: don't put field names in quotes. This was done inconsistently anyway so get rid of it alltogether. Signed-off-by: Peter Hutterer --- XI2proto.txt | 152 +++++++++++++++++++++++++-------------------------- 1 file changed, 76 insertions(+), 76 deletions(-) diff --git a/XI2proto.txt b/XI2proto.txt index ec930d3..94e0f81 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -279,33 +279,33 @@ are required to be 0. XIQueryDevices details information about the requested input devices. devices - The device to list. If 'devices' is AllDevices, all enabled and - disabled devices are listed. If 'devices' is AllMasterDevices, all - enabled and disabled master devices are listed. If 'devices' is a - valid DEVICE, only this DEVICE is listed and 'num_devices' is 1. + The device to list. If devices is AllDevices, all enabled and + disabled devices are listed. If devices is AllMasterDevices, all + enabled and disabled master devices are listed. If devices is a + valid DEVICE, only this DEVICE is listed and num_devices is 1. num_devices - The number of 'deviceinfos' returned. + The number of deviceinfos returned. - Each 'deviceinfo' is detailed as follows: + Each deviceinfo is detailed as follows: deviceid The unique ID of the device. Device IDs may get re-used when a device is removed. use - If the device is a master pointer, 'use' is MasterPointer. - If the device is a master keyboard, 'use' is MasterKeyboard. - If the device is a slave pointer, 'use' is SlavePointer. - If the device is a slave keyboard, 'use' is SlaveKeyboard. - If the device is a floating slave, 'use' is FloatingSlave. + If the device is a master pointer, use is MasterPointer. + If the device is a master keyboard, use is MasterKeyboard. + If the device is a slave pointer, use is SlavePointer. + If the device is a slave keyboard, use is SlaveKeyboard. + If the device is a floating slave, use is FloatingSlave. attachment - If the device is a master pointer or a master keyboard, 'attachment' + If the device is a master pointer or a master keyboard, attachment specifies the paired master keyboard, or the paired master pointer, respectively. If the device is a non-floating slave device - 'attachment' specifies the master device this device is attached to. - If the device is a floating slave, 'attachment' is undefined. + attachment specifies the master device this device is attached to. + If the device is a floating slave, attachment is undefined. enabled Zero if the device is disabled, non-zero otherwise. num_classes - Number of 'classes' provided. + Number of classes provided. name_len Length of the name in bytes not including padding. classes @@ -314,8 +314,8 @@ are required to be 0. name The device's name. padded to a multiple of 4 bytes. - For all classes, 'type' specifies the device class. Clients are required - to ignore unknown device classes. The 'length' field specifies the length + For all classes, type specifies the device class. Clients are required + to ignore unknown device classes. The length field specifies the length of the class in 4 byte units. The following classes may occur only once: ButtonClass, KeyClass @@ -374,8 +374,8 @@ are required to be 0. value Last published axis value (if mode is absolute). - 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. + 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. ┌─── XISelectEvents @@ -392,29 +392,29 @@ are required to be 0. window The window to select the events on. num_masks - Number of items in 'masks'. + Number of items in masks. deviceid Numerical deviceid, or AllDevices, or AllMasterDevices. mask_len - Length of 'mask' in 4 byte units. + Length of mask in 4 byte units. mask Event mask. An event mask for an event type T is defined as (1 << T). - XISelectEvents selects for XI2 events on 'window'. + XISelectEvents selects for XI2 events on window. - If 'num_masks' is 0, a BadValue error occurs. + If num_masks is 0, a BadValue error occurs. - Each 'mask' sets the (and overwrites a previous) event mask for the DEVICE - specified through 'deviceid'. The device 'AllDevices' or - 'AllMasterDevices' is treated as a separate device by server. A client's - event mask is the union of 'AllDevices', 'AllMasterDevices' and the + Each mask sets the (and overwrites a previous) event mask for the DEVICE + specified through deviceid. The device AllDevices or + AllMasterDevices is treated as a separate device by server. A client's + event mask is the union of AllDevices, AllMasterDevices and the per-device event mask. The removal of device from the server unsets the event masks for the device. If an event mask is set for AllDevices or AllMasterDevices, the event mask is not cleared on device removal and affects all future devices. - If 'mask_len' is 0, the event mask for the given device is cleared. + 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. @@ -430,16 +430,16 @@ are required to be 0. window The window to select the events on. num_masks - Number of items in 'masks'. + Number of items in masks. masks Selected event masks by this client. - Masks are returned on a per-device basis, with masks for 'AllDevices' and - 'AllMasterDevices' returned separately. A client can calculate the + Masks are returned on a per-device basis, with masks for AllDevices and + AllMasterDevices returned separately. A client can calculate the effective mask for a device with a bitwise OR of the AllDevices, the AllMasterDevices and the device-specific mask. - If 'num_masks' is 0, no events have been selected by this client on the + If num_masks is 0, no events have been selected by this client on the given window. ┌─── @@ -465,21 +465,21 @@ are required to be 0. root The root window the pointer is logically on. child - The child window of 'window' that contains the pointer or None. + The child window of window that contains the pointer or None. root_x root_y Pointer position relative to the root window's origin. win_x win_y - Pointer position relative to 'window' or 0 if 'same_screen' is false. + Pointer position relative to window or 0 if same_screen is false. same_screen - True if 'window' is on the same screen as the pointer. + True if window is on the same screen as the pointer. mods XKB modifier state on the paired device. group XKB group state on the paired device. buttons_len - The length of 'buttons' in 4 byte units. + The length of buttons in 4 byte units. buttons Button state. @@ -496,7 +496,7 @@ are required to be 0. deviceid: DEVICEID └─── - WarpPointer moves the pointer of 'deviceid' as if the user had moved + WarpPointer moves the pointer of deviceid as if the user had moved the pointer. WarpPointer can only be called for MasterPointer and FloatingSlave devices. @@ -506,9 +506,9 @@ are required to be 0. rectangle of src_window. dst_win If dst_win is None, this request moves the pointer by offsets - 'dst_x'/'dst_y' relative to the current position of the pointer. If + dst_x/dst_y relative to the current position of the pointer. If dst_window is a window, this request moves the pointer to - 'dst_x'/'dst_y' relative to dst_win's origin. + dst_x/dst_y relative to dst_win's origin. src_x src_y src_width @@ -516,8 +516,8 @@ are required to be 0. Specifies the source window rectangle. dst_x dst_y - The relative coordinates to move the pointer if 'dst_win' is None, or - the absolute coordinates if 'dst_win' is a window. + The relative coordinates to move the pointer if dst_win is None, or + the absolute coordinates if dst_win is a window. deviceid The device to warp. @@ -544,9 +544,9 @@ are required to be 0. deviceid The master pointer device. - Whenever 'device' enters a window W, the cursor shape is selected in the + 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', + - 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 protocol's window attributes, display cursor C(w). @@ -606,7 +606,7 @@ are required to be 0. length Length in 4 byte units. name_len - Length of 'name' in bytes. + Length of name in bytes. send_core True if the device should send core events. enable @@ -625,15 +625,15 @@ are required to be 0. The device to remove. return_mode Return mode for attached slave devices. - If 'return_mode' is Float, all slave devices are set to floating. - If 'return_mode' is Attach, slave pointers are attached to - 'return_pointer' and slave keyboards are attached to - 'return_keyboard'. + If return_mode is Float, all slave devices are set to floating. + If return_mode is Attach, slave pointers are attached to + return_pointer and slave keyboards are attached to + return_keyboard. return_pointer return_keyboard The master pointer and master keyboard to attach slave devices to, if - 'return_mode' is Attach. If 'return_mode' is Float, 'return_pointer' - and 'return_keyboard' are undefined. + return_mode is Attach. If return_mode is Float, return_pointer + and return_keyboard are undefined. Removing a master pointer removes the paired master keyboard and vice versa. @@ -662,7 +662,7 @@ are required to be 0. deviceid: DEVICEID └─── - Set the ClientPointer for the client owning 'win' to the given device. + Set the ClientPointer for the client owning win to the given device. win Window or client ID. @@ -694,14 +694,14 @@ are required to be 0. deviceid: DEVICEID └─── - Query the ClientPointer for the client owning 'win'. + Query the ClientPointer for the client owning win. win The window or client ID. set True if the client has a ClientPointer set. deviceid - The master pointer that acts as a ClientPointer if 'set' is True. + The master pointer that acts as a ClientPointer if set is True. No difference is made between a ClientPointer set explicitly through XISetClientPointer and a ClientPointer implicitly assigned by the server @@ -1358,16 +1358,16 @@ EVENTHEADER { type: BYTE The current hierarchy information. An XIHierarchyEvent is sent whenever the device hierarchy been - changed. The 'flags' specify all types of hierarchy modifiations that have + changed. The flags specify all types of hierarchy modifiations that have occured. - For all devices, 'info' details the hierarchy information after the + For all devices, info details the hierarchy information after the modification of the hierarchy has occured. For each device specified with - 'deviceid': - - if 'type' is MasterPointer or MasterKeyboard, 'attachment' decribes the + deviceid: + - if type is MasterPointer or MasterKeyboard, attachment decribes the pairing of this device. - - if 'type' is SlavePointer or SlaveKeyboard, 'attachment' describes the + - if type is SlavePointer or SlaveKeyboard, attachment describes the master device this device is attached to. - - if 'type' is FloatingSlave device, 'attachment' is undefined. + - if type is FloatingSlave device, attachment is undefined. enabled True if the device is enabled and can send events. A disabled master @@ -1375,8 +1375,8 @@ EVENTHEADER { type: BYTE device. 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. + deviceid in an XIHierarchyEvent is always the first affected + device. Clients should ignore deviceid and instead use the devices list. ┌─── DeviceChangedEvent: @@ -1395,21 +1395,21 @@ EVENTHEADER { type: BYTE reason The reason for generating this event. - If 'reason' is SlaveSwitch, the slave device sending events through - this device has changed and 'source' specifies the new slave device. - A SlaveSwitch 'reason' can only occur on a master device. - If 'reason' is DeviceChange, the device itself has changed through - other means (e.g. a physical device change) and 'source' is + If reason is SlaveSwitch, the slave device sending events through + this device has changed and source specifies the new slave device. + A SlaveSwitch reason can only occur on a master device. + If reason is DeviceChange, the device itself has changed through + other means (e.g. a physical device change) and source is the device itself. source The source of the new classes. num_classes - Number of 'classes' provided. + Number of classes provided. classes 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 XQueryInputDevice + For a detailed description of classes, see the XQueryInputDevice request. ┌─── @@ -1470,9 +1470,9 @@ EVENTHEADER { type: BYTE event window (16.16 fixed point). buttons_len - The length of 'buttons' in 4 byte units. + The length of buttons in 4 byte units. valuators_len - The length of 'valuators' in 4 byte units. + The length of valuators in 4 byte units. sourceid The source device that originally generated the event. mods @@ -1482,7 +1482,7 @@ EVENTHEADER { type: BYTE buttons Button state before the event. valuators - Bitmask of valuators provided in 'axisvalues'. + Bitmask of valuators provided in axisvalues. axisvalues Valuator data in device-native resolution. flags @@ -1493,7 +1493,7 @@ EVENTHEADER { type: BYTE the physical state of the key has not changed. This is only valid for KeyPress events. - Modifier state in 'mods' is detailed as follows: + Modifier state in mods is detailed as follows: base_mods XKB base modifier state. latched_mods @@ -1501,7 +1501,7 @@ EVENTHEADER { type: BYTE locked_mods XKB locked modifier state. - Group state in 'group' is detailed as follows: + Group state in group is detailed as follows: base_group XKB base group state. latched_group @@ -1536,9 +1536,9 @@ EVENTHEADER { type: BYTE flags Flags as described in DeviceEvent. valuators_len - The length of 'valuators' in 4 byte units. + The length of valuators in 4 byte units. valuators - Bitmask of valuators provided in 'axisvalues' and 'axisvalues_raw'. + Bitmask of valuators provided in axisvalues and axisvalues_raw. axisvalues Valuator data in device-native resolution. axisvalues_raw @@ -1620,7 +1620,7 @@ EVENTHEADER { type: BYTE group XKB group state before the event. buttons_len - The length of 'buttons' in 4 byte units. + The length of buttons in 4 byte units. buttons Button state before the event. From b31776bb5b416ffa15235611954e68d386edf674 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 31 Jul 2009 08:52:43 +1000 Subject: [PATCH 190/388] XI2proto.txt: document ClientPointer in more detail. Signed-off-by: Peter Hutterer --- XI2proto.txt | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/XI2proto.txt b/XI2proto.txt index 94e0f81..00e5e8d 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -149,6 +149,26 @@ 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 + +Many core protocol and some extension requests are ambiguous when multiple +master devices are available (e.g. QueryPointer does not specfy 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. +QueryPointer), the ClientPointer or the keyboard paired with the ClientPointer +is chosen to provide the data for this request. + +This ClientPointer may be explicitly assigned to a client with the +SetClientPointer call. If no ClientPointer is set when a client issues an +ambiguous request, the server choses one device as the ClientPointer. The +method of chosing a ClientPointer from the available master pointers is +implementation-specific. + +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. + ❧❧❧❧❧❧❧❧❧❧❧ 5. Data types @@ -672,7 +692,8 @@ are required to be 0. Some protocol requests are ambiguous and the server has to choose a device to provide data for a request or a reply. By default, the server will choose a client's ClientPointer device to provide the data, unless the - client currently has a grab on another device. + client currently has a grab on another device. See section 4.4 for more + details. If win is None, the ClientPointer for this client is set to the given device. Otherwise, if win is a valid window, the ClientPointer for the From d8a1c1b1aba92e60d2fcad7cdf5abe77f3c9ae10 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 5 Aug 2009 14:52:45 +1000 Subject: [PATCH 191/388] Revert "XI2proto.txt: grabbing a slave does not detach it anymore." Detaching a slave device during an explicit grab makes sense from a UI perspective. It allows a client to get exclusive access to a device without that device's events also feeding into the respective master device. Thanks to Thomas Jaeger for his contribution. This reverts commit d0b1e55b876a29a7c820ec12d7b9cb5e081e1944. Signed-off-by: Peter Hutterer --- XI2proto.txt | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/XI2proto.txt b/XI2proto.txt index 00e5e8d..4b67d66 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -1050,7 +1050,11 @@ are required to be 0. master keyboard are used. If deviceid specifies a slave pointer the modifiers of the master keyboard paired with the attached master pointers are used. If deviceid specifies a slave keyboard, the - modifiers of the attached master keyboard are used. + modifiers of the attached master keyboard are used. Note that + activating a grab on a slave device detaches the device from its + master. In this case, the modifiers after activation of the grab are + from the slave device only and may be different to the modifier state + when the grab was triggered. In the future, if grab_type is GrabtypeButton or GrabtypeKeyboard, the device is actively grabbed if: From 1a7eb6de82bd61fc16f2a3f000d4d3b9d418dcd0 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 4 Aug 2009 10:43:52 +1000 Subject: [PATCH 192/388] inputproto 1.9.99.901 (RC 1) Signed-off-by: Peter Hutterer --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 9487382..5682dea 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.15], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.901], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) # Require xorg-macros: XORG_CHANGELOG From 6719ae1ed024270f7fe1cb6bbee1f84cdaeba90c Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 7 Aug 2009 10:39:46 +1000 Subject: [PATCH 193/388] Remove eventtype field from xXIRawEvent. With c455db2, raw events were split up into using multiple evtypes instead of a sub event type. The eventtype field itself however has not been removed and was unused by both the server and the library. Field converted into a padding field, wire layout stays the same. Signed-off-by: Peter Hutterer --- XI2proto.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index 8fb506d..101bbf1 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -901,9 +901,7 @@ typedef struct uint16_t deviceid; Time time; uint32_t detail; - uint16_t eventtype; /**< ::XI_Motion, ::XI_ButtonPress, - ::XI_ButtonRelease, ::XI_KeyPress, - ::XI_KeyRelease */ + uint16_t pad0; uint16_t valuators_len; /**< Length of trailing valuator mask in 4 byte units */ uint32_t flags; /**< ::XIKeyRepeat */ From 4f9d8d49eca460b24daca2a28a2c644f7edc19bd Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 18 Aug 2009 15:04:47 +1000 Subject: [PATCH 194/388] XI2proto.txt: typo fix Signed-off-by: Peter Hutterer --- XI2proto.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XI2proto.txt b/XI2proto.txt index 4b67d66..21410a6 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -702,7 +702,7 @@ are required to be 0. this client's ClientPointer is set to the given device. If deviceid does not specify a master pointer or master keyboard, a - BadDevice error returned. + BadDevice error is returned. If window does not specify a valid window or client ID and is not None, a BadWindow error is returned. From d9aa0917b491e9d6ef887ac59fb7a01fb428fa62 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 18 Aug 2009 15:05:09 +1000 Subject: [PATCH 195/388] XI2proto: XIChangeCursor request requires a master pointer. State that the server will return BadDevice in this case. Signed-off-by: Peter Hutterer --- XI2proto.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/XI2proto.txt b/XI2proto.txt index 21410a6..3fd7ac9 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -572,6 +572,9 @@ are required to be 0. protocol's window attributes, display cursor C(w). - repeat on parent window until a cursor has been found. + If deviceid does not specify a master pointer, a BadDevice error + is returned. + ┌─── XIChangeHierarchy num_changes: CARD8 From 68cdaf8d26e133f700404bca93b18240aa6b8f86 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 21 Aug 2009 13:55:52 +1000 Subject: [PATCH 196/388] XIQueryPointer only works on master pointers and floating slaves. Signed-off-by: Peter Hutterer --- XI2proto.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/XI2proto.txt b/XI2proto.txt index 3fd7ac9..a55d06d 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -503,6 +503,9 @@ are required to be 0. buttons Button state. + If the device is not a master pointer device or not a floating slave + pointer, a BadDevice error results. + ┌─── XIWarpPointer src_win: Window From 8eccc169c045fcf68b5a0974c49a8e6863894cf3 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 21 Aug 2009 13:56:11 +1000 Subject: [PATCH 197/388] Replace four leftover INT16 with int16_t. --- XI2proto.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index 101bbf1..78770c5 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -372,12 +372,12 @@ typedef struct { uint16_t length; /**< Length in 4 byte units */ Window src_win; Window dst_win; - INT16 src_x; - INT16 src_y; + int16_t src_x; + int16_t src_y; uint16_t src_width; uint16_t src_height; - INT16 dst_x; - INT16 dst_y; + int16_t dst_x; + int16_t dst_y; uint16_t deviceid; uint16_t pad1; } xXIWarpPointerReq; From ae4588ff0c6e5cc7009e4ac78a3f953bc399bd84 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 21 Aug 2009 14:24:23 +1000 Subject: [PATCH 198/388] XIWarpPointer needs to take FP1616 for positions. This was already in the spec but the protocol itself hadn't cought up with it. Signed-off-by: Peter Hutterer --- XI2proto.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index 78770c5..2fd91eb 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -372,16 +372,16 @@ typedef struct { uint16_t length; /**< Length in 4 byte units */ Window src_win; Window dst_win; - int16_t src_x; - int16_t src_y; + FP1616 src_x; + FP1616 src_y; uint16_t src_width; uint16_t src_height; - int16_t dst_x; - int16_t dst_y; + FP1616 dst_x; + FP1616 dst_y; uint16_t deviceid; uint16_t pad1; } xXIWarpPointerReq; -#define sz_xXIWarpPointerReq 28 +#define sz_xXIWarpPointerReq 36 /** * Change the given device's sprite to the given cursor. From f3f79c0642f33b6a39a0f7fdab2bcb06d9cab0f7 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Tue, 25 Aug 2009 10:04:01 +1000 Subject: [PATCH 199/388] Device cursors are deleted once the window or the device disappear. Signed-off-by: Peter Hutterer --- XI2proto.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/XI2proto.txt b/XI2proto.txt index a55d06d..706f50a 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -575,6 +575,9 @@ are required to be 0. protocol's window attributes, display cursor C(w). - repeat on parent window until a cursor has been found. + The device cursor for a given window is reset once the window is destroyed + or the device is removed, whichever comes earlier. + If deviceid does not specify a master pointer, a BadDevice error is returned. From 472309905a66245c9fd420ef64716ec630216323 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 21 Aug 2009 14:25:51 +1000 Subject: [PATCH 200/388] inputproto 1.9.99.902 (RC 2) Signed-off-by: Peter Hutterer --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 5682dea..2b6c043 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.901], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [1.9.99.902], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) # Require xorg-macros: XORG_CHANGELOG From bda99e7e5ac528aaa08664b21f0380db67bd2ac2 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 2 Oct 2009 11:31:13 +1000 Subject: [PATCH 201/388] Require macros 1.3 for XORG_DEFAULT_OPTIONS Signed-off-by: Peter Hutterer --- configure.ac | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index 2b6c043..5c43cca 100644 --- a/configure.ac +++ b/configure.ac @@ -2,11 +2,11 @@ AC_PREREQ([2.57]) AC_INIT([InputProto], [1.9.99.902], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) -# Require xorg-macros: XORG_CHANGELOG -m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.2 or later before running autoconf/autogen])]) -XORG_MACROS_VERSION(1.2) -XORG_RELEASE_VERSION -XORG_CHANGELOG +# Require xorg-macros: XORG_DEFAULT_OPTIONS +m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.3 or later before running autoconf/autogen])]) +XORG_MACROS_VERSION(1.3) + +XORG_DEFAULT_OPTIONS AC_OUTPUT([Makefile inputproto.pc]) From 0470d29c1e690f3784ca1a42f6d27aa322f9b37a Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 1 Oct 2009 16:47:11 +1000 Subject: [PATCH 202/388] Add XIproto.txt This is the XI protocol specification document that used to be in xorg-docs. It's now moved here, and if it ever sees updates, the updates will only apply to here. Signed-off-by: Peter Hutterer --- Makefile.am | 2 +- XIproto.txt | 2542 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 2543 insertions(+), 1 deletion(-) create mode 100644 XIproto.txt diff --git a/Makefile.am b/Makefile.am index f41d768..85ca02f 100644 --- a/Makefile.am +++ b/Makefile.am @@ -10,7 +10,7 @@ pkgconfig_DATA = inputproto.pc EXTRA_DIST = inputproto.pc.in -EXTRA_DIST += ChangeLog XI2proto.txt +EXTRA_DIST += ChangeLog XI2proto.txt XIproto.txt MAINTAINERCLEANFILES = ChangeLog .PHONY: ChangeLog diff --git a/XIproto.txt b/XIproto.txt new file mode 100644 index 0000000..20cc02a --- /dev/null +++ b/XIproto.txt @@ -0,0 +1,2542 @@ + X11 Input Extension Protocol Specification + Version 1.0 + X Consortium Standard + X Version 11, Release 6.8 + Mark Patrick, Ardent Computer + George Sachs, Hewlett-Packard + + Version 1.5 + Peter Hutterer + + Copyright © 1989, 1990, 1991 by Hewlett-Packard Company and + Ardent Computer + + Permission to use, copy, modify, and distribute this + documentation for any purpose and without fee is hereby + granted, provided that the above copyright notice and this + permission notice appear in all copies. Ardent and + Hewlett-Packard make no representations about the suitability + for any purpose of the information in this document. It is + provided "as is" without express or implied warranty. Copyright + © 1989, 1990, 1991, 1992 X Consortium + + Permission is hereby granted, free of charge, to any person + obtaining a copy of this software and associated documentation + files (the “Software”), to deal in the Software without + restriction, including without limitation the rights to use, + copy, modify, merge, publish, distribute, sublicense, and/or + sell copies of the Software, and to permit persons to whom the + Software is furnished to do so, subject to the following + conditions: + + The above copyright notice and this permission notice shall be + included in all copies or substantial portions of the Software. + + THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE + FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION + OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN + CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + THE SOFTWARE. + + Except as contained in this notice, the name of the X + Consortium shall not be used in advertising or otherwise to + promote the sale, use or other dealings in this Software + without prior written authorization from the X Consortium. X + Window System is a trademark of The Open Group. + + Copyright © 2008 by Peter Hutterer + + Permission is hereby granted, free of charge, to any person + obtaining a copy of this software and associated documentation + files (the "Software"), to deal in the Software without + restriction, including without limitation the rights to use, + copy, modify, merge, publish, distribute, sublicense, and/or + sell copies of the Software, and to permit persons to whom the + Software is furnished to do so, subject to the following + conditions: + + The above copyright notice and this permission notice + (including the next paragraph) shall be included in all copies + or substantial portions of the Software. + + THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, + WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + 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. + +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. + +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. + + In servers supporting only XI 1.x, this input extension does + not change the behavior or functionality of the core input + devices, core events, or core protocol requests, with the + exception of the core grab requests. These requests may affect + the synchronization of events from extension devices. See the + explanation in the section titled "Event Synchronization and + Core Grabs". + + Selection of the physical devices to be initially used by the + server as the core devices is left implementation-dependent. + Requests are defined that allow client programs to change which + physical devices are used as the core devices. + +1.3 Extension Input Devices + + The input extension v1.x controls access to input devices other + than the X keyboard and X pointer. It allows client programs to + select input from these devices independently from each other + and independently from the core devices. + + A client that wishes to access a specific device must first + determine whether that device is connected to the X server. + This is done through the ListInputDevices request, which will + return a list of all devices that can be opened by the X + server. A client can then open one or more of these devices + using the OpenDevice request, specify what events they are + interested in receiving, and receive and process input events + from extension devices in the same way as events from the X + keyboard and X pointer. Input events from these devices are of + extension types ( DeviceKeyPress, DeviceKeyRelease, + DeviceButtonPress, DeviceButtonRelease, DeviceMotionNotify, + etc.) and contain a device identifier so that events of the + same type coming from different input devices can be + distinguished. + + Any kind of input device may be used as an extension input + device. Extension input devices may have 0 or more keys, 0 or + more buttons, and may report 0 or more axes of motion. Motion + may be reported as relative movements from a previous position + or as an absolute position. All valuators reporting motion + information for a given extension input device must report the + same kind of motion information (absolute or relative). + + This extension is designed to accommodate new types of input + devices that may be added in the future. The protocol requests + that refer to specific characteristics of input devices + organize that information by input classes. Server implementors + may add new classes of input devices without changing the + protocol requests. Input classes are unique numbers registered + with the X Consortium. Each extension input device may support + multiple input classes. + + In XI 1.x, all extension input devices are treated like the + core X keyboard in determining their location and focus. The + server does not track the location of these devices on an + individual basis, and therefore does not echo a cursor to + indicate their current location. Instead, their location is + determined by the location of the core X pointer. Like the core + X keyboard, some may be explicitly focused. If they are not + explicitly focused, their focus is determined by the location + of the core X pointer. + + Most input events reported by the server to a client are of + fixed size (32 bytes). In order to represent the change in + state of an input device the extension may need to generate a + sequence of input events. A client side library (such as Xlib) + will typically take these raw input events and format them into + a form more convenient to the client. + +1.4 Event Classes + + In the core protocol a client registers interest in receiving + certain input events directed to a window by modifying that + window's event-mask. Most of the bits in the event mask are + already used to specify interest in core X events. The input + extension specifies a different mechanism by which a client can + express interest in events generated by this extension. + + When a client opens a extension input device via the OpenDevice + request, an XDevice structure is returned. Macros are provided + that extract 32-bit numbers called event classes from that + structure, that a client can use to register interest in + extension events via the SelectExtensionEvent request. The + event class combines the desired event type and device id, and + may be thought of as the equivalent of core event masks. + +1.5 Input Classes + + Some of the input extension requests divide input devices into + classes based on their functionality. This is intended to allow + new classes of input devices to be defined at a later time + without changing the semantics of these requests. The following + input device classes are currently defined: + + KEY + The device reports key events. + + BUTTON + The device reports button events. + + VALUATOR + The device reports valuator data in motion events. + + PROXIMITY + The device reports proximity events. + + FOCUS + The device can be focused and reports focus events. + + FEEDBACK + The device supports feedbacks. + + OTHER + The ChangeDeviceNotify, DeviceMappingNotify, and + DeviceStateNotify macros may be invoked passing the + XDevice structure returned for this device. + + Each extension input device may support multiple input classes. + Additional classes may be added in the future. Requests that + support multiple input classes, such as the ListInputDevices + function that lists all available input devices, organize the + data they return by input class. Client programs that use these + requests should not access data unless it matches a class + defined at the time those clients were compiled. In this way, + new classes can be added without forcing existing clients that + use these requests to be recompiled. + +2. Requests + + Extension input devices are accessed by client programs through + the use of new protocol requests. This section summarizes the + new requests defined by this extension. The syntax and type + definitions used below follow the notation used for the X11 + core protocol. + +2.1 Getting the Extension Version + + The GetExtensionVersion request returns version information + about the input extension. + + GetExtensionVersion + name: STRING + => + present: BOOL + protocol-major-version: CARD16 + protocol-minor-version: CARD16 + + The protocol version numbers returned indicate the version of + the input extension supported by the target X server. The + version numbers can be compared to constants defined in the + header file XI.h. Each version is a superset of the previous + versions. + + The name must be the name of the Input Extension as defined + in the header file XI.h. + +2.2 Listing Available Devices + + A client that wishes to access a specific device must first + determine whether that device is connected to the X server. + This is done through the ListInputDevices request, which will + return a list of all devices that can be opened by the X + server. + + ListInputDevices + => + input-devices: ListOfDeviceInfo + + where + + DEVICEINFO: + [type: ATOM + id: CARD8 + num_classes: CARD8 + use: {IsXKeyboard, IsXPointer, IsXExtensionPointer, + IsXExtensionKeyboard, IsExtensionDevice} + info: LISTofINPUTINFO + name: STRING8] + + INPUTINFO: {KEYINFO, BUTTONINFO, VALUATORINFO} + KEYINFO: + [class: CARD8 + length: CARD8 + min-keycode: KEYCODE + max-keycode: KEYCODE + num-keys: CARD16] + BUTTONINFO: + [class: CARD8 + length: CARD8 + num-buttons: CARD16] + VALUATORINFO: + [class: CARD8 + length: CARD8 + num_axes: CARD8 + mode: SETofDEVICEMODE + motion_buffer_size: CARD32 + axes: LISTofAXISINFO] + + AXISINFO: + [resolution: CARD32 + min-val: CARD32 + max-val: CARD32] + DEVICEMODE: {Absolute, Relative} + + Errors: None + + This request returns a list of all devices that can be opened + by the X server, including the core X keyboard and X pointer. + Some implementations may open all input devices as part of X + initialization, while others may not open an input device until + requested to do so by a client program. + + The information returned for each device is as follows: + + type + The type field is of type Atom and indicates the nature + of the device. Clients may determine device types by + invoking the XInternAtom request passing one of the + names defined in the header file XI.h. The following + names have been defined to date: + + MOUSE + TABLET + KEYBOARD + TOUCHSCREEN + TOUCHPAD + BUTTONBOX + BARCODE + KNOB_BOX + TRACKBALL + QUADRATURE + SPACEBALL + DATAGLOVE + EYETRACKER + CURSORKEYS + FOOTMOUSE + ID_MODULE + ONE_KNOB + NINE_KNOB + JOYSTICK + + + id + The id is a small cardinal value in the range 0-128 that + uniquely identifies the device. It is assigned to the + device when it is initialized by the server. Some + implementations may not open an input device until + requested by a client program, and may close the device + when the last client accessing it requests that it be + closed. If a device is opened by a client program via + XOpenDevice, then closed via XCloseDevice, then opened + again, it is not guaranteed to have the same id after + the second open request. + + num_classes + The num_classes field is a small cardinal value in the + range 0-255 that specifies the number of input classes + supported by the device for which information is + returned by ListInputDevices. Some input classes, such + as class Focus and class Proximity do not have any + information to be returned by ListInputDevices. + + use + The use field specifies how the device is currently + being used. If the value is IsXKeyboard, the device is + currently being used as the X keyboard. If the value is + IsXPointer, the device is currently being used as the X + pointer. If the value is IsXExtensionPointer, the device + is available for use as an extension pointer. If the value + is IsXExtensionKeyboard, the device is available for use as + and extension keyboard. + Older versions of XI report all extension devices as + IsXExtensionDevice. + + name + The name field contains a pointer to a null-terminated + string that corresponds to one of the defined device + types. + + InputInfo + InputInfo is one of: KeyInfo, ButtonInfo or + ValuatorInfo. The first two fields are common to all + three: + + class + The class field is a cardinal value in the range + 0-255. It uniquely identifies the class of input + for which information is returned. + + length + The length field is a cardinal value in the range + 0-255. It specifies the number of bytes of data + that are contained in this input class. The length + includes the class and length fields. + + The remaining information returned for input class + KEYCLASS is as follows: + + min_keycode + min_keycode is of type KEYCODE. It specifies the + minimum keycode that the device will report. The + minimum keycode will not be smaller than 8. + + max_keycode + max_keycode is of type KEYCODE. It specifies the + maximum keycode that the device will report. The + maximum keycode will not be larger than 255. + + num_keys + num_keys is a cardinal value that specifies the + number of keys that the device has. + + The remaining information returned for input class + BUTTONCLASS is as follows: + + num_buttons + num_buttons is a cardinal value that specifies the + number of buttons that the device has. + + The remaining information returned for input class + VALUATORCLASS is as follows: + + mode + mode is a constant that has one of the following + values: Absolute or Relative. Some devices allow + the mode to be changed dynamically via the + SetDeviceMode request. + + motion_buffer_size + motion_buffer_size is a cardinal number that + specifies the number of elements that can be + contained in the motion history buffer for the + device. + + axes + The axes field contains a pointer to an AXISINFO + struture. + + The information returned for each axis reported by the + device is: + + resolution + The resolution is a cardinal value in + counts/meter. + + min_val + The min_val field is a cardinal value in that + contains the minimum value the device reports for + this axis. For devices whose mode is Relative, the + min_val field will contain 0. + + max_val + The max_val field is a cardinal value in that + contains the maximum value the device reports for + this axis. For devices whose mode is Relative, the + max_val field will contain 0. + +2.3 Enabling Devices + + Client programs that wish to access an extension device must + request that the server open that device. This is done via the + OpenDevice request. + + OpenDevice + id: CARD8 + => + DEVICE: + [device_id: XID + num_classes: INT32 + classes: LISTofINPUTCLASSINFO] + INPUTCLASSINFO: + [input_class: CARD8 + event_type_base: CARD8] + + Errors: Device + + This request returns the event classes to be used by the client + to indicate which events the client program wishes to receive. + Each input class may report several event classes. For example, + input class Keys reports DeviceKeyPress and DeviceKeyRelease + event classes. Input classes are unique numbers registered with + the X Consortium. Input class Other exists to report event + classes that are not specific to any one input class, such as + DeviceMappingNotify, ChangeDeviceNotify, and DeviceStateNotify. + + The information returned for each device is as follows: + + device_id + The device_id is a number that uniquely identifies the + device. + + num_classes + The num_classes field contains the number of input + classes supported by this device. + + For each class of input supported by the device, the + InputClassInfo structure contains the following information: + + input_class + The input_class is a small cardinal number that + identifies the class of input. + + event_type_base + The event_type_base is a small cardinal number that + specifies the event type of one of the events reported + by this input class. This information is not directly + used by client programs. Instead, the Device is used by + macros that return extension event types and event + classes. This is described in the section of this + document entitled "Selecting Extension Device Events". + + The information in the InputClassInfo reflects the state of + this device at the time the request was processed. + + Before it exits, the client program should explicitly request + that the server close the device. This is done via the + CloseDevice request. + + A client may open the same extension device more than once. + Requests after the first successful one return an additional + XDevice structure with the same information as the first, but + otherwise have no effect. A single CloseDevice request will + terminate that client's access to the device. + + Closing a device releases any active or passive grabs the + requesting client has established. If the device is frozen only + by an active grab of the requesting client, the queued events + are released when the client terminates. + + If a client program terminates without closing a device, the + server will automatically close that device on behalf of the + client. This does not affect any other clients that may be + accessing that device. + + CloseDevice: + device: DEVICE + + Errors: Device + +2.4 Changing The Mode Of A Device + + Some devices are capable of reporting either relative or + absolute motion data. To change the mode of a device from + relative to absolute, use the SetDeviceMode request. The valid + values are Absolute or Relative. + + This request will fail and return DeviceBusy if another client + already has the device open with a different mode. It will fail + and return AlreadyGrabbed if another client has the device + grabbed. The request will fail with a BadMatch error if the + requested mode is not supported by the device. + + SetDeviceMode + device:DEVICE + mode: {Absolute, Relative} + => + status: {Success, DeviceBusy, AlreadyGrabbed} + + Errors: Device, Match, Mode + +2.5 Initializing Valuators on an Input Device + + Some devices that report absolute positional data can be + initialized to a starting value. Devices that are capable of + reporting relative motion or absolute positional data may + require that their valuators be initialized to a starting value + after the mode of the device is changed to Absolute. To + initialize the valuators on such a device, use the + SetDeviceValuators request. + + SetDeviceValuators + device: DEVICE + first_valuator: CARD8 + num_valuators: CARD8 + valuators: LISTOFINT32 + => + status: {Success, AlreadyGrabbed} + + Errors: Length, Device, Match, Value + + This request initializes the specified valuators on the + specified extension input device. Valuators are numbered + beginning with zero. Only the valuators in the range specified + by first_valuator and num_valuators are set. If the number of + valuators supported by the device is less than the expression + first_valuator + num_valuators, a Value error will result. + + If the request succeeds, Success is returned. If the specifed + device is grabbed by some other client, the request will fail + and a status of AlreadyGrabbed will be returned. + +2.6 Getting Input Device Controls + + GetDeviceControl + device: DEVICE + control: XID + => + controlState: {DeviceState} + + where + + DeviceState: DeviceResolutionState + + Errors: Length, Device, Match, Value + + This request returns the current state of the specified device + control. The device control must be supported by the target + server and device or an error will result. + + If the request is successful, a pointer to a generic + DeviceState structure will be returned. The information + returned varies according to the specified control and is + mapped by a structure appropriate for that control. + + GetDeviceControl will fail with a BadValue error if the server + does not support the specified control. It will fail with a + BadMatch error if the device does not support the specified + control. + + Supported device controls and the information returned for them + include: + + DEVICE_RESOLUTION: + [control: CARD16 + length: CARD16 + num_valuators: CARD8 + resolutions: LISTofCARD32 + min_resolutions: LISTofCARD32 + max_resolutions: LISTofCARD32] + + This device control returns a list of valuators and the range + of valid resolutions allowed for each. Valuators are numbered + beginning with 0. Resolutions for all valuators on the device + are returned. For each valuator i on the device, resolutions[i] + returns the current setting of the resolution, + min_resolutions[i] returns the minimum valid setting, and + max_resolutions[i] returns the maximum valid setting. + + When this control is specified, XGetDeviceControl will fail + with a BadMatch error if the specified device has no valuators. + + ChangeDeviceControl: + device: DEVICE + XID: controlId + control: DeviceControl + + where + + DeviceControl: DeviceResolutionControl + => + status: {Success, DeviceBusy, AlreadyGrabbed} + + Errors: Length, Device, Match, Value + + ChangeDeviceControl changes the specifed device control + according to the values specified in the DeviceControl + structure. The device control must be supported by the target + server and device or an error will result. + + The information passed with this request varies according to + the specified control and is mapped by a structure appropriate + for that control. + + ChangeDeviceControl will fail with a BadValue error if the + server does not support the specified control. It will fail + with a BadMatch error if the server supports the specified + control, but the requested device does not. The request will + fail and return a status of DeviceBusy if another client + already has the device open with a device control state that + conflicts with the one specified in the request. It will fail + with a status of AlreadyGrabbed if some other client has + grabbed the specified device. If the request succeeds, Success + is returned. If it fails, the device control is left unchanged. + + Supported device controls and the information specified for + them include: + + DEVICE_RESOLUTION: + [control: CARD16 + length: CARD16 + first_valuator: CARD8 + num_valuators: CARD8 + resolutions: LISTofCARD32] + + This device control changes the resolution of the specified + valuators on the specified extension input device. Valuators + are numbered beginning with zero. Only the valuators in the + range specified by first_valuator and num_valuators are set. A + value of -1 in the resolutions list indicates that the + resolution for this valuator is not to be changed. + num_valuators specifies the number of valuators in the + resolutions list. + + When this control is specified, XChangeDeviceControl will fail + with a BadMatch error if the specified device has no valuators. + If a resolution is specified that is not within the range of + valid values (as returned by XGetDeviceControl) the request + will fail with a BadValue error. If the number of valuators + supported by the device is less than the expression + first_valuator + num_valuators, a BadValue error will result. + + If the request fails for any reason, none of the valuator + resolutions will be changed. + + ChangeDeviceControl causes the server to send a DevicePresence + event to interested clients. + +2.7 Selecting Extension Device Events + + Extension input events are selected using the + SelectExtensionEvent request. + + SelectExtensionEvent + interest: LISTofEVENTCLASS + window: WINDOW + + Errors: Window, Class, Access + + This request specifies to the server the events within the + specified window which are of interest to the client. As with + the core XSelectInput function, multiple clients can select + input on the same window. + + XSelectExtensionEvent requires a list of event classes. An + event class is a 32-bit number that combines an event type and + device id, and is used to indicate which event a client wishes + to receive and from which device it wishes to receive it. + Macros are provided to obtain event classes from the data + returned by the XOpenDevice request. The names of these macros + correspond to the desired events, i.e. the DeviceKeyPress is + used to obtain the event class for DeviceKeyPress events. The + syntax of the macro invocation is: + DeviceKeyPress (device, event_type, event_class); + device: DEVICE + event_type: INT + event_class: INT + + The value returned in event_type is the value that will be + contained in the event type field of the XDeviceKeyPressEvent + when it is received by the client. The value returned in + event_class is the value that should be passed in making an + XSelectExtensionEvent request to receive DeviceKeyPress events. + + For DeviceButtonPress events, the client may specify whether or + not an implicit passive grab should be done when the button is + pressed. If the client wants to guarantee that it will receive + a DeviceButtonRelease event for each DeviceButtonPress event it + receives, it should specify the DeviceButtonPressGrab event + class as well as the DeviceButtonPress event class. This + restricts the client in that only one client at a time may + request DeviceButtonPress events from the same device and + window if any client specifies this class. + + If any client has specified the DeviceButtonPressGrab class, + any requests by any other client that specify the same device + and window and specify DeviceButtonPress or + DeviceButtonPressGrab will cause an Access error to be + generated. + + If only the DeviceButtonPress class is specified, no implicit + passive grab will be done when a button is pressed on the + device. Multiple clients may use this class to specify the same + device and window combination. + + A client may also specify the DeviceOwnerGrabButton class. If + it has specified both the DeviceButtonPressGrab and the + DeviceOwnerGrabButton classes, implicit passive grabs will + activate with owner_events set to True. If only the + DeviceButtonPressGrab class is specified, implicit passive + grabs will activate with owner_events set to False. + + The client may select DeviceMotion events only when a button is + down. It does this by specifying the event classes + Button1Motion through Button5Motion, or ButtonMotion. An input + device will only support as many button motion classes as it + has buttons. + +2.8 Determining Selected Events + + To determine which extension events are currently selected from + a given window, use GetSelectedExtensionEvents. + + GetSelectedExtensionEvents + window: WINDOW + => + this-client: LISTofEVENTCLASS + all-clients: LISTofEVENTCLASS + + Errors: Window + + This request returns two lists specifying the events selected + on the specified window. One list gives the extension events + selected by this client from the specified window. The other + list gives the extension events selected by all clients from + the specified window. This information is equivalent to that + returned by your-event-mask and all-event-masks in a + GetWindowAttributes request. + +2.9 Controlling Event Propagation + + Extension events propagate up the window hierarchy in the same + manner as core events. If a window is not interested in an + extension event, it usually propagates to the closest ancestor + that is interested, unless the dont_propagate list prohibits + it. Grabs of extension devices may alter the set of windows + that receive a particular extension event. + + Client programs may control extension event propagation through + the use of the following two requests. + + XChangeDeviceDontPropagateList adds an event to or deletes an + event from the do_not_propagate list of extension events for + the specified window. This list is maintained for the life of + the window, and is not altered if the client terminates. + + ChangeDeviceDontPropagateList + window: WINDOW + eventclass: LISTofEVENTCLASS + mode: {AddToList, DeleteFromList} + + Errors: Window, Class, Mode + + This function modifies the list specifying the events that are + not propagated to the ancestors of the specified window. You + may use the modes AddToList or DeleteFromList. + + GetDeviceDontPropagateList + window: WINDOW + Errors: Window + => + dont-propagate-list: LISTofEVENTCLASS + + This function returns a list specifying the events that are not + propagated to the ancestors of the specified window. + +2.10 Sending Extension Events + + One client program may send an event to another via the + XSendExtensionEvent function. + + The event in the XEvent structure must be one of the events + defined by the input extension, so that the X server can + correctly byte swap the contents as necessary. The contents of + the event are otherwise unaltered and unchecked by the X server + except to force send_event to True in the forwarded event and + to set the sequence number in the event correctly. + + XSendExtensionEvent returns zero if the conversion-to-wire + protocol failed, otherwise it returns nonzero. + + SendExtensionEvent + device: DEVICE + destination: WINDOW + propagate: BOOL + eventclass: LISTofEVENTCLASS + event: XEVENT + + Errors: Device, Value, Class, Window + +2.11 Getting Motion History + + GetDeviceMotionEvents + device: DEVICE + start, stop: TIMESTAMP or CurrentTime + => + nevents_return: CARD32 + mode_return: {Absolute, Relative} + axis_count_return: CARD8 + events: LISTofDEVICETIMECOORD + + where + + DEVICETIMECOORD: + [data: LISTofINT32 + time: TIMESTAMP] + + Errors: Device, Match + + This request returns all positions in the device's motion + history buffer that fall between the specified start and stop + times inclusive. If the start time is in the future, or is + later than the stop time, no positions are returned. + + The data field of the DEVICETIMECOORD structure is a sequence + of data items. Each item is of type INT32, and there is one + data item per axis of motion reported by the device. The number + of axes reported by the device is returned in the axis_count + variable. + + The value of the data items depends on the mode of the device, + which is returned in the mode variable. If the mode is + Absolute, the data items are the raw values generated by the + device. These may be scaled by the client program using the + maximum values that the device can generate for each axis of + motion that it reports. The maximum and minimum values for each + axis are reported by the ListInputDevices request. + + If the mode is Relative, the data items are the relative values + generated by the device. The client program must choose an + initial position for the device and maintain a current position + by accumulating these relative values. + +2.12 Changing The Core Devices + + These requests are provided to change which physical device is + used as the X pointer or X keyboard. These requests are + deprecated in servers supporting XI 1.4 and above, and will + always return a a BadDevice error. + + Using these requests may change the characteristics of the core + devices. The new pointer device may have a different number of + buttons than the old one did, or the new keyboard device may + have a different number of keys or report a different range of + keycodes. Client programs may be running that depend on those + characteristics. For example, a client program could allocate + an array based on the number of buttons on the pointer device, + and then use the button numbers received in button events as + indicies into that array. Changing the core devices could cause + such client programs to behave improperly or abnormally + terminate. + + These requests change the X keyboard or X pointer device and + generate an ChangeDeviceNotify event and a MappingNotify event. + The ChangeDeviceNotify event is sent only to those clients that + have expressed an interest in receiving that event via the + XSelectExtensionEvent request. The specified device becomes the + new X keyboard or X pointer device. The location of the core + device does not change as a result of this request. + + These requests fail and return AlreadyGrabbed if either the + specified device or the core device it would replace are + grabbed by some other client. They fail and return GrabFrozen + if either device is frozen by the active grab of another + client. + + These requests fail with a BadDevice error if the specified + device is invalid, or has not previously been opened via + OpenDevice. To change the X keyboard device, use the + ChangeKeyboardDevice request. The specified device must support + input class Keys (as reported in the ListInputDevices request) + or the request will fail with a BadMatch error. Once the device + has successfully replaced one of the core devices, it is + treated as a core device until it is in turn replaced by + another ChangeDevice request, or until the server terminates. + The termination of the client that changed the device will not + cause it to change back. Attempts to use the CloseDevice + request to close the new core device will fail with a BadDevice + error. + + The focus state of the new keyboard is the same as the focus + state of the old X keyboard. If the new keyboard was not + initialized with a FocusRec, one is added by the + ChangeKeyboardDevice request. The X keyboard is assumed to have + a KbdFeedbackClassRec. If the device was initialized without a + KbdFeedbackClassRec, one will be added by this request. The + KbdFeedbackClassRec will specify a null routine as the control + procedure and the bell procedure. + + ChangeKeyboardDevice + device: DEVICE + Errors: Device, Match + => + status: Success, AlreadyGrabbed, Frozen + + To change the X pointer device, use the ChangePointerDevice + request. The specified device must support input class + Valuators (as reported in the ListInputDevices request) or the + request will fail with a BadMatch error. The valuators to be + used as the x- and y-axes of the pointer device must be + specified. Data from other valuators on the device will be + ignored. + + The X pointer device does not contain a FocusRec. If the new + pointer was initialized with a FocusRec, it is freed by the + ChangePointerDevice request. The X pointer is assumed to have a + ButtonClassRec and a PtrFeedbackClassRec. If the device was + initialized without a ButtonClassRec or a PtrFeedbackClassRec, + one will be added by this request. The ButtonClassRec added + will have no buttons, and the PtrFeedbackClassRec will specify + a null routine as the control procedure. + + If the specified device reports absolute positional + information, and the server implementation does not allow such + a device to be used as the X pointer, the request will fail + with a BadDevice error. + + Once the device has successfully replaced one of the core + devices, it is treated as a core device until it is in turn + replaced by another ChangeDevice request, or until the server + terminates. The termination of the client that changed the + device will not cause it to change back. Attempts to use the + CloseDevice request to close the new core device will fail with + a BadDevice error. + + ChangePointerDevice + device: DEVICE + xaxis: CARD8 + yaxis: CARD8 + => + status: Success, AlreadyGrabbed, Frozen + + Errors: Device, Match + +2.12 Event Synchronization And Core Grabs + + Implementation of the input extension requires an extension of + the meaning of event synchronization for the core grab + requests. This is necessary in order to allow window managers + to freeze all input devices with a single request. + + The core grab requests require a pointer_mode and keyboard_mode + argument. The meaning of these modes is changed by the input + extension. For the XGrabPointer and XGrabButton requests, + pointer_mode controls synchronization of the pointer device, + and keyboard_mode controls the synchronization of all other + input devices. For the XGrabKeyboard and XGrabKey requests, + pointer_mode controls the synchronization of all input devices + except the X keyboard, while keyboard_mode controls the + synchronization of the keyboard. When using one of the core + grab requests, the synchronization of extension devices is + controlled by the mode specified for the device not being + grabbed. + +2.13 Extension Active Grabs + + Active grabs of extension devices are supported via the + GrabDevice request in the same way that core devices are + grabbed using the core GrabKeyboard request, except that a + Device is passed as a function parameter. A list of events that + the client wishes to receive is also passed. The UngrabDevice + request allows a previous active grab for an extension device + to be released. + + To grab an extension device, use the GrabDevice request. The + device must have previously been opened using the OpenDevice + request. + + GrabDevice + device: DEVICE + grab-window: WINDOW + owner-events: BOOL + event-list: LISTofEVENTCLASS + this-device-mode: {Synchronous, Asynchronous} + other-device-mode: {Synchronous, Asynchronous} + time:TIMESTAMP or CurrentTime + => + status: Success, AlreadyGrabbed, Frozen, + InvalidTime, NotViewable + + Errors: Device, Window, Value + + 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 overrides any previous + active grab by this client for this device. + + The event-list parameter is a pointer to a list of event + classes. These are used to indicate which events the client + wishes to receive while the device is grabbed. Only event + classes obtained from the grabbed device are valid. + + If owner-events is False, input events generated from this + device are reported with respect to grab-window, and are only + reported if selected by being included in the event-list. If + owner-events is True, then if a generated event would normally + be reported to this client, it is reported normally, otherwise + the event is reported with respect to the grab-window, and is + only reported if selected by being included in the event-list. + For either value of owner-events, unreported events are + discarded. + + If this-device-mode is Asynchronous, device event processing + continues normally. If the device is currently frozen by this + client, then processing of device events is resumed. If + this-device-mode is Synchronous, the state of the grabbed + device (as seen by means of the protocol) appears to freeze, + and no further device events are generated by the server until + the grabbing client issues a releasing AllowDeviceEvents + 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. + + If other-device-mode is Asynchronous, event processing is + unaffected by activation of the grab. If other-device-mode is + Synchronous, the state of all input devices except the grabbed + one (as seen by means of the protocol) appears to freeze, and + no further events are generated by the server until the + grabbing client issues a releasing AllowDeviceEvents request or + until the device grab is released. Actual events are not lost + while the devices are frozen; they are simply queued for later + processing. + + This request generates DeviceFocusIn and DeviceFocusOut events. + + This request fails and returns: + + AlreadyGrabbed + If the device is actively grabbed by some other client. + + NotViewable + If grab-window is not viewable. + + InvalidTime + If the specified time is earlier than the last-grab-time + for the specified device or later than the current X + server time. Otherwise, the last-grab-time for the + specified device is set to the specified time and + CurrentTime is replaced by the current X server time. + + Frozen + If the device is frozen by an active grab of another + client. + + If a grabbed device is closed by a client while an active grab + by that client is in effect, that active grab will be released. + Any passive grabs established by that client will be released. + If the device is frozen only by an active grab of the + requesting client, it is thawed. + + To release a grab of an extension device, use UngrabDevice. + + UngrabDevice + device: DEVICE + time: TIMESTAMP or CurrentTime + + Errors: Device + + This request releases the device if this client has it actively + grabbed (from either GrabDevice or GrabDeviceKey) and releases + any queued events. If any devices were frozen by the grab, + UngrabDevice thaws them. The request has no effect if the + specified time is earlier than the last-device-grab time or is + later than the current server time. + + This request generates DeviceFocusIn and DeviceFocusOut events. + + An UngrabDevice is performed automatically if the event window + for an active device grab becomes not viewable. + +2.14 Passively Grabbing A Key + + Passive grabs of buttons and keys on extension devices are + supported via the GrabDeviceButton and GrabDeviceKey requests. + These passive grabs are released via the UngrabDeviceKey and + UngrabDeviceButton requests. + + To passively grab a single key on an extension device, use + GrabDeviceKey. That device must have previously been opened + using the OpenDevice request. + + GrabDeviceKey + device: DEVICE + keycode: KEYCODE or AnyKey + modifiers: SETofKEYMASK or AnyModifier + modifier-device: DEVICE or NULL + grab-window: WINDOW + owner-events: BOOL + event-list: LISTofEVENTCLASS + this-device-mode: {Synchronous, Asynchronous} + other-device-mode: {Synchronous, Asynchronous} + + Errors: Device, Match, Access, Window, Value + + This request is analogous to the core GrabKey request. It + establishes a passive grab on a device. Consequently, in the + future: + * IF the device is not grabbed and the specified key, which + itself can be a modifier key, is logically pressed when the + specified modifier keys logically are down on the specified + modifier device (and no other keys are down), + * AND no other modifier keys logically are down, + * AND EITHER the grab window is an ancestor of (or is) the + focus window OR the grab window is a descendent of the + focus window and contains the pointer, + * AND a passive grab on the same device and key combination + does not exist on any ancestor of the grab window, + * THEN the device is actively grabbed, as for GrabDevice, the + last-device-grab time is set to the time at which the key + was pressed (as transmitted in the DeviceKeyPress event), + and the DeviceKeyPress event is reported. + + The interpretation of the remaining arguments is as for + GrabDevice. The active grab is terminated automatically when + logical state of the device has the specified key released + (independent of the logical state of the modifier keys). + + Note that the logical state of a device (as seen by means of + the X protocol) may lag the physical state if device event + processing is frozen. + + A modifier of AnyModifier is equivalent to issuing the request + for all possible modifier combinations (including the + combination of no modifiers). It is not required that all + modifiers specified have currently assigned keycodes. A key of + AnyKey is equivalent to issuing the request for all possible + keycodes. Otherwise, the key must be in the range specified by + min-keycode and max-keycode in the ListInputDevices request. If + it is not within that range, GrabDeviceKey generates a Value + error. + + NULL may be passed for the modifier_device. If the + modifier_device is NULL, the core X keyboard is used as the + modifier_device. + + An Access error is generated if some other client has issued a + GrabDeviceKey with the same device and key combination on the + same window. When using AnyModifier or AnyKey, the request + fails completely and the X server generates a Access error and + no grabs are established if there is a conflicting grab for any + combination. + + This request cannot be used to grab a key on the X keyboard + device. The core GrabKey request should be used for that + purpose. + + To release a passive grab of a single key on an extension + device, use UngrabDeviceKey. + + UngrabDeviceKey + device: DEVICE + keycode: KEYCODE or AnyKey + modifiers: SETofKEYMASK or AnyModifier + modifier-device: DEVICE or NULL + grab-window: WINDOW + + Errors: Device, Match, Window, Value, Alloc + + This request is analogous to the core UngrabKey request. It + releases the key combination on the specified window if it was + grabbed by this client. A modifier of AnyModifier is equivalent + to issuing the request for all possible modifier combinations + (including the combination of no modifiers). A key of AnyKey is + equivalent to issuing the request for all possible keycodes. + This request has no effect on an active grab. + + NULL may be passed for the modifier_device. If the + modifier_device is NULL, the core X keyboard is used as the + modifier_device. + +2.15 Passively Grabbing A Button + + To establish a passive grab for a single button on an extension + device, use GrabDeviceButton. + + GrabDeviceButton + device: DEVICE + button: BUTTON or AnyButton + modifiers: SETofKEYMASK or AnyModifier + modifier-device: DEVICE or NULL + grab-window: WINDOW + owner-events: BOOL + event-list: LISTofEVENTCLASS + this-device-mode: {Synchronous, Asynchr + onous} + other-device-mode: {Synchronous, Asynch + ronous} + + Errors: Device, Match, Window, Access, Value + + This request is analogous to the core GrabButton request. It + establishes an explicit passive grab for a button on an + extension input device. Since the server does not track + extension devices, no cursor is specified with this request. + For the same reason, there is no confine-to parameter. The + device must have previously been opened using the OpenDevice + request. + + The GrabDeviceButton request establishes a passive grab on a + device. Consequently, in the future, + + • + IF the device is not grabbed and the specified button is + logically pressed when the specified modifier keys + logically are down (and no other buttons or modifier + keys are down), + + • + AND the grab window contains the device, + + • + AND a passive grab on the same device and button/ key + combination does not exist on any ancestor of the grab + window, + + • + THEN the device is actively grabbed, as for GrabDevice, + the last-grab time is set to the time at which the + button was pressed (as transmitted in the + DeviceButtonPress event), and the DeviceButtonPress + event is reported. + + The interpretation of the remaining arguments is as for + GrabDevice. The active grab is terminated automatically when + logical state of the device has all buttons released + (independent of the logical state of the modifier keys). + + Note that the logical state of a device (as seen by means of + the X protocol) may lag the physical state if device event + processing is frozen. + + A modifier of AnyModifier is equivalent to issuing the request + for all possible modifier combinations (including the + combination of no modifiers). It is not required that all + modifiers specified have currently assigned keycodes. A button + of AnyButton is equivalent to issuing the request for all + possible buttons. It is not required that the specified button + be assigned to a physical button. + + NULL may be passed for the modifier_device. If the + modifier_device is NULL, the core X keyboard is used as the + modifier_device. + + An Access error is generated if some other client has issued a + GrabDeviceButton with the same device and button combination on + the same window. When using AnyModifier or AnyButton, the + request fails completely and the X server generates a Access + error and no grabs are established if there is a conflicting + grab for any combination. The request has no effect on an + active grab. + + This request cannot be used to grab a button on the X pointer + device. The core GrabButton request should be used for that + purpose. + + To release a passive grab of a button on an extension device, + use UngrabDeviceButton. + + UngrabDeviceButton + device: DEVICE + button: BUTTON or AnyButton + modifiers: SETofKEYMASK or AnyModifier + modifier-device: DEVICE or NULL + grab-window: WINDOW + + Errors: Device, Match, Window, Value, Alloc + + This request is analogous to the core UngrabButton request. It + releases the passive button/key combination on the specified + window if it was grabbed by the client. A modifiers of + AnyModifier is equivalent to issuing the request for all + possible modifier combinations (including the combination of no + modifiers). A button of AnyButton is equivalent to issuing the + request for all possible buttons. This request has no effect on + an active grab. The device must have previously been opened + using the OpenDevice request otherwise a Device error will be + generated. + + NULL may be passed for the modifier_device. If the + modifier_device is NULL, the core X keyboard is used as the + modifier_device. + + This request cannot be used to ungrab a button on the X pointer + device. The core UngrabButton request should be used for that + purpose. + +2.16 Thawing A Device + + To allow further events to be processed when a device has been + frozen, use AllowDeviceEvents. + + AllowDeviceEvents + device: DEVICE + event-mode: {AsyncThisDevice, SyncThisD + evice, AsyncOtherDevices, + ReplayThisdevice, AsyncAll, or SyncAll} + time:TIMESTAMP or CurrentTime + + Errors: Device, Value + + The AllowDeviceEvents request releases some queued events if + the client has caused a device to freeze. 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 following describes the processing that occurs depending on + what constant you pass to the event-mode argument: + + * If the specified device is frozen by the client, event + processing for that device continues as usual. If the + device is frozen multiple times by the client on behalf + of multiple separate grabs, AsyncThisDevice thaws for + all. AsyncThisDevice has no effect if the specified + device is not frozen by the client, but the device need + not be grabbed by the client. + + * If the specified device is frozen and actively grabbed + by the client, event processing for that device + continues normally until the next button or key event is + reported to the client. At this time, the specified + device again appears to freeze. However, if the reported + event causes the grab to be released, the specified + device does not freeze. SyncThisDevice has no effect if + the specified device is not frozen by the client or is + not grabbed by the client. + + * If the specified device is actively grabbed by the + client and is frozen as the result of an event having + been sent to the client (either from the activation of a + GrabDeviceButton or from a previous AllowDeviceEvents + with mode SyncThisDevice, but not from a Grab), the grab + is released and that event is completely reprocessed. + This time, however, the request ignores any passive + grabs at or above (towards the root) the grab-window of + the grab just released. The request has no effect if the + specified device is not grabbed by the client or if it + is not frozen as the result of an event. + + * If the remaining devices are frozen by the client, event + processing for them continues as usual. If the other + devices are frozen multiple times by the client on + behalf of multiple separate grabs, AsyncOtherDevices + “thaws” for all. AsyncOtherDevices has no effect if the + devices are not frozen by the client, but those devices + need not be grabbed by the client. + + * If all devices are frozen by the client, event + processing (for all devices) continues normally until + the next button or key event is reported to the client + for a grabbed device (button event for the grabbed + device, key or motion event for the device), at which + time the devices again appear to freeze. However, if the + reported event causes the grab to be released, then the + devices do not freeze (but if any device is still + grabbed, then a subsequent event for it will still cause + all devices to freeze). SyncAll has no effect unless all + devices are frozen by the client. If any device is + frozen twice by the client on behalf of two separate + grabs, SyncAll "thaws" for both (but a subsequent freeze + for SyncAll will only freeze each device once). + + * If all devices are frozen by the client, event + processing (for all devices) continues normally. If any + device is frozen multiple times by the client on behalf + of multiple separate grabs, AsyncAll "thaws" for all. + AsyncAll has no effect unless all devices are frozen by + the client. + + AsyncThisDevice, SyncThisDevice, and ReplayThisDevice + have no effect on the processing of events from the + remaining devices. AsyncOtherDevices has no effect on + the processing of events from the specified device. When + the event_mode is SyncAll or AsyncAll, the device + parameter is ignored. + + It is possible for several grabs of different devices + (by the same or different clients) to be active + simultaneously. If a device is frozen on behalf of any + grab, no event processing is performed for the device. + It is possible for a single device to be frozen because + of several grabs. In this case, the freeze must be + released on behalf of each grab before events can again + be processed. + +2.17 Controlling Device Focus + + The current focus window for an extension input device can be + determined using the GetDeviceFocus request. Extension devices + are focused using the SetDeviceFocus request in the same way + that the keyboard is focused using the SetInputFocus request, + except that a device is specified as part of the request. One + additional focus state, FollowKeyboard, is provided for + extension devices. + + To get the current focus state, revert state, and focus time of + an extension device, use GetDeviceFocus. + + GetDeviceFocus + device: DEVICE + => + focus: WINDOW, PointerRoot, FollowKeyboard, or None + revert-to: Parent, PointerRoot, FollowKeyboard, or None + focus-time: TIMESTAMP + + Errors: Device, Match + + This request returns the current focus state, revert-to state, + and last-focus-time of an extension device. + + To set the focus of an extension device, use SetDeviceFocus. + + SetDeviceFocus + device: DEVICE + focus: WINDOW, PointerRoot, FollowKeyboard, or None + revert-to: Parent, PointerRoot, FollowKeyboard, or None + focus-time: TIMESTAMP + + Errors: Device, Window, Value, Match + + This request changes the focus for an extension input device + and the last-focus-change-time. The request has no effect if + the specified time is earlier than the 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, with + CurrentTime replaced by the current server time. + + The action taken by the server when this request is requested + depends on the value of the focus argument: + + * If the focus argument is None, all input events from + this device will be discarded until a new focus window + is set. In this case, the revert-to argument is ignored. + + * If a window ID is assigned to the focus argument, it + becomes the focus window of the device. If an input + event from the device would normally be reported to this + window or to one of its inferiors, the event is reported + normally. Otherwise, the event is reported relative to + the focus window. + + * If you assign PointerRoot to the focus argument, the + focus window is dynamically taken to be the root window + of whatever screen the pointer is on at each input + event. In this case, the revert-to argument is ignored. + + * If you assign FollowKeyboard to the focus argument, the + focus window is dynamically taken to be the same as the + focus of the X keyboard at each input event. + + The specified focus window must be viewable at the time + of the request (else a Match error). If the focus window + later becomes not viewable, the X server evaluates the + revert-to argument to determine the new focus window. + + * If you assign RevertToParent to the revert-to argument, + the focus reverts to the parent (or the closest viewable + ancestor), and the new revert-to value is taken to be + RevertToNone. + + * If you assign RevertToPointerRoot, + RevertToFollowKeyboard, or RevertToNone to the revert-to + argument, the focus reverts to that value. + + When the focus reverts, the X server generates DeviceFocusIn + and DeviceFocusOut events, but the last-focus-change time is + not affected. + + This request causes the X server to generate DeviceFocusIn and + DeviceFocusOut events. + +2.18 Controlling Device Feedback + + To get the settings of feedbacks on an extension device, use + GetFeedbackControl. This request provides functionality + equivalent to the core GetKeyboardControl and GetPointerControl + functions. It also provides a way to control displays + associated with an input device that are capable of displaying + an integer or string. + + GetFeedbackControl + device: DEVICE + => + num_feedbacks_return: CARD16 + return_value: LISTofFEEDBACKSTATE + + where + + FEEDBACKSTATE: {KbdFeedbackState, PtrFeedbackState, + IntegerFeedbackState, StringFeedbackState, + BellFeedbackState, LedFeedbackState} + + Feedbacks are reported by class. Those feedbacks that are + reported for the core keyboard device are in class KbdFeedback, + and are returned in the KbdFeedbackState structure. The members + of that structure are as follows: + + CLASS Kbd: + [class: CARD8 + length: CARD16 + feedback id: CARD8 + key_click_percent: CARD8 + bell_percent: CARD8 + bell_pitch: CARD16 + bell_duration: CARD16 + led_value: BITMASK + global_auto_repeat: {AutoRepeatModeOn, AutoRepeatModeOff} + auto_repeats: LISTofCARD8] + + Those feedbacks that are equivalent to those reported for the + core pointer are in feedback class PtrFeedback and are reported + in the PtrFeedbackState structure. The members of that + structure are: + + CLASS Ptr: + [class: CARD8 + length: CARD16 + feedback id: CARD8 + accelNumerator: CARD16 + accelDenominator: CARD16 + threshold: CARD16] + + Some input devices provide a means of displaying an integer. + Those devices will support feedback class IntegerFeedback, + which is reported in the IntegerFeedbackState structure. The + members of that structure are: + + CLASS Integer: + [class: CARD8 + length: CARD16 + feedback id: CARD8 + resolution: CARD32 + min-val: INT32 + max-val: INT32] + + Some input devices provide a means of displaying a string. + Those devices will support feedback class StringFeedback, which + is reported in the StringFeedbackState structure. The members + of that structure are: + + CLASS String: + [class: CARD8 + length: CARD16 + feedback id: CARD8 + max_symbols: CARD16 + num_keysyms_supported: CARD16 + keysyms_supported: LISTofKEYSYM] + + Some input devices contain a bell. Those devices will support + feedback class BellFeedback, which is reported in the + BellFeedbackState structure. The members of that structure are: + + CLASS String: + [class: CARD8 + length: CARD16 + feedback id: CARD8 + percent: CARD8 + pitch: CARD16 + duration: CARD16] + + The percent sets the base volume for the bell between 0 (off) + and 100 (loud) inclusive, if possible. Setting to -1 restores + the default. Other negative values generate a Value error. + + The pitch sets the pitch (specified in Hz) of the bell, if + possible. Setting to -1 restores the default. Other negative + values generate a Value error. + + The duration sets the duration (specified in milliseconds) of + the bell, if possible. Setting to -1 restores the default. + Other negative values generate a Value error. + + A bell generator connected with the console but not directly on + the device is treated as if it were part of the device. Some + input devices contain LEDs. Those devices will support feedback + class Led, which is reported in the LedFeedbackState structure. + The members of that structure are: + + CLASS String: + [class: CARD8 + length: CARD16 + feedback id: CARD8 + led_mask: BITMASK + led_value: BITMASK] + + Each bit in led_mask indicates that the corresponding led is + supported by the feedback. At most 32 LEDs per feedback are + supported. No standard interpretation of LEDs is defined. + + This function will fail with a BadMatch error if the device + specified in the request does not support feedbacks. + + Errors: Device, Match + + To change the settings of a feedback on an extension device, + use ChangeFeedbackControl. + + ChangeFeedbackControl + device: DEVICE + feedbackid: CARD8 + value-mask: BITMASK + value: FEEDBACKCONTROL + FEEDBACKCONTROL: {KBDFEEDBACKCONTROL, + PTRFEEDBACKCONTROL, + INTEGERFEEDBACKCONTROL, + STRINGFEEDBACKCONTROL, + BELLFEEDBACKCONTROL, + LEDFEEDBACKCONTROL} + + Errors: Device, Match, Value + + Feedback controls are grouped by class. Those feedbacks that + are equivalent to those supported by the core keyboard are + controlled by feedback class KbdFeedbackClass using the + KbdFeedbackControl structure. The members of that structure + are: + + KBDFEEDBACKCTL + [class: CARD8 + length: CARD16 + feedback id: CARD8 + key_click_percent: INT8 + bell_percent: INT8 + bell_pitch: INT16 + bell_duration: INT16 + led_mask: INT32 + led_value: INT32 + key: KEYCODE + auto_repeat_mode: {AutoRepeatModeOn, AutoRepeatModeOff, + AutoRepeatModeDefault}] + + The key_click_percent sets the volume for key clicks between 0 + (off) and 100 (loud) inclusive, if possible. Setting to -1 + restores the default. Other negative values generate a Value + error. + + If both auto_repeat_mode and key are specified, then the + auto_repeat_mode of that key is changed, if possible. If only + auto_repeat_mode is specified, then the global auto-repeat mode + for the entire keyboard is changed, if possible, without + affecting the per-key settings. It is a Match error if a key is + specified without an auto_repeat_mode. + + The order in which controls are verified and altered is + server-dependent. If an error is generated, a subset of the + controls may have been altered. + + Those feedback controls equivalent to those of the core pointer + are controlled by feedback class PtrFeedbackClass using the + PtrFeedbackControl structure. The members of that structure are + as follows: + + PTRFEEDBACKCTL: + [class: CARD8 + length: CARD16 + feedback id: CARD8 + accelNumerator: INT16 + accelDenominator: INT16 + threshold: INT16] + + The acceleration, expressed as a fraction, is a multiplier for + movement. For example, specifying 3/1 means the device moves + three times as fast as normal. The fraction may be rounded + arbitrarily by the X server. Acceleration only takes effect if + the device moves more than threshold pixels at once and only + applies to the amount beyond the value in the threshold + argument. Setting a value to -1 restores the default. The + values of the do-accel and do-threshold arguments must be + nonzero for the device values to be set. Otherwise, the + parameters will be unchanged. Negative values generate a Value + error, as does a zero value for the accel-denominator argument. + + Some devices are capable of displaying an integer. This is done + using feedback class IntegerFeedbackClass using the + IntegerFeedbackControl structure. The members of that structure + are as follows: + + INTEGERCTL: + [class: CARD8 + length: CARD16 + feedback id: CARD8 + int_to_display: INT32] + + Some devices are capable of displaying an string. This is done + using feedback class StringFeedbackClass using the + StringFeedbackCtl structure. The members of that structure are + as follows: + + STRINGCTL: + [class: CARD8 + length: CARD16 + feedback id: CARD8 + syms_to_display: LISTofKEYSYMS] + + Some devices contain a bell. This is done using feedback class + BellFeedbackClass using the BellFeedbackControl structure. The + members of that structure are as follows: + + BELLCTL: + [class: CARD8 + length: CARD16 + feedback id: CARD8 + percent: INT8 + pitch: INT16 + duration: INT16] + + Some devices contain leds. These can be turned on and off using + the LedFeedbackControl structure. The members of that structure + are as follows: + + LEDCTL: + [class: CARD8 + length: CARD16 + feedback id: CARD8 + led_mask: BITMASK + led_value: BITMASK] + + Errors: Device, Match, Value + +2.20 Ringing a Bell on an Input Device + + To ring a bell on an extension input device, use DeviceBell. + + DeviceBell: + device: DEVICE + feedbackclass: CARD8 + feedbackid: CARD8 + percent: INT8 + + Errors: Device, Value + + This request is analogous to the core Bell request. It rings + the specified bell on the specified input device feedback, + using the specified volume. The specified volume is relative to + the base volume for the feedback. If the value for the percent + argument is not in the range -100 to 100 inclusive, a Value + error results. The volume at which the bell rings when the + percent argument is nonnegative is: + + base - [(base * percent) / 100] + percent + + The volume at which the bell rings when the percent argument is + negative is: + + base + [(base * percent) / 100] + + To change the base volume of the bell, use + ChangeFeedbackControl request. + +Controlling Device Encoding + + To get the keyboard mapping of an extension device that has + keys, use GetDeviceKeyMapping. + + GetDeviceKeyMapping + device: DEVICE + first-keycode: KEYCODE + count: CARD8 + => + keysyms-per-keycode: CARD8 + keysyms: LISTofKEYSYM + + Errors: Device, Match, Value + + This request returns the symbols for the specified number of + keycodes for the specified extension device, starting with the + specified keycode. The first-keycode must be greater than or + equal to min-keycode as returned in the connection setup (else + a Value error), and + + first-keycode + count - 1 + + must be less than or equal to max-keycode as returned in the + connection setup (else a Value error). The number of elements + in the keysyms list is + + count * keysyms-per-keycode + + and KEYSYM number N (counting from zero) for keycode K has an + index (counting from zero) of + + (K - first-keycode) * keysyms-per-keycode + N + + in keysyms. The keysyms-per-keycode value is chosen arbitrarily + by the server to be large enough to report all requested + symbols. A special KEYSYM value of NoSymbol is used to fill in + unused elements for individual keycodes. + + If the specified device has not first been opened by this + client via OpenDevice, or if that device does not support input + class Keys, this request will fail with a Device error. + + To change the keyboard mapping of an extension device that has + keys, use ChangeDeviceKeyMapping. + + ChangeDeviceKeyMapping + device: DEVICE + first-keycode: KEYCODE + keysyms-per-keycode: CARD8 + keysyms: LISTofKEYSYM + num_codes: CARD8 + + Errors: Device, Match, Value, Alloc + + This request is analogous to the core ChangeKeyMapping request. + It defines the symbols for the specified number of keycodes for + the specified extension device. If the specified device has not + first been opened by this client via OpenDevice, or if that + device does not support input class Keys, this request will + fail with a Device error. + + The number of elements in the keysyms list must be a multiple + of keysyms_per_keycode. Otherwise, ChangeDeviceKeyMapping + generates a Length error. The specified first_keycode must be + greater than or equal to the min_keycode value returned by the + ListInputDevices request, or this request will fail with a + Value error. In addition, if the following expression is not + less than the max_keycode value returned by the + ListInputDevices request, the request will fail with a Value + error: + + first_keycode + (num_codes / keysyms_per_keycode) - 1 + + To obtain the keycodes that are used as modifiers on an + extension device that has keys, use GetDeviceModifierMapping. + + GetDeviceModifierMapping + device: DEVICE + => + keycodes-per-modifier: CARD8 + keycodes: LISTofKEYCODE + + Errors: Device, Match + + This request is analogous to the core GetModifierMapping + request. This request returns the keycodes of the keys being + used as modifiers. The number of keycodes in the list is + 8*keycodes-per-modifier. The keycodes are divided into eight + sets, with each set containing keycodes-per-modifier elements. + The sets are assigned in order to the modifiers Shift, Lock, + Control, Mod1, Mod2, Mod3, Mod4, and Mod5. The + keycodes-per-modifier value is chosen arbitrarily by the + server; zeroes are used to fill in unused elements within each + set. If only zero values are given in a set, the use of the + corresponding modifier has been disabled. The order of keycodes + within each set is chosen arbitrarily by the server. + + To set which keycodes that are to be used as modifiers for an + extension device, use SetDeviceModifierMapping. + + SetDeviceModifierMapping + device: DEVICE + keycodes-per-modifier: CARD8 + keycodes: LISTofKEYCODE + => + status: {Success, Busy, Failed} + + Errors: Device, Match, Value, Alloc + + This request is analogous to the core SetModifierMapping + request. This request specifies the keycodes (if any) of the + keys to be used as modifiers. The number of keycodes in the + list must be 8*keycodes-per-modifier (else a Length error). The + keycodes are divided into eight sets, with the sets, with each + set containing keycodes-per-modifier elements. The sets are + assigned in order to the modifiers Shift, Lock, Control, Mod1, + Mod2, Mod3, Mod4, and Mod5. Only non-zero keycode values are + used within each set; zero values are ignored. All of the + non-zero keycodes must be in the range specified by min-keycode + and max-keycode in the ListInputDevices request (else a Value + error). The order of keycodes within a set does not matter. If + no non-zero values are specified in a set, the use of the + corresponding modifier is disabled, and the modifier bit will + always be zero. Otherwise, the modifier bit will be one + whenever at least one of the keys in the corresponding set is + in the down position. + + A server can impose restrictions on how modifiers can be + changed (for example, if certain keys do not generate up + transitions in hardware or if multiple keys per modifier are + not supported). The status reply is Failed if some such + restriction is violated, and none of the modifiers are changed. + + If the new non-zero keycodes specified for a modifier differ + from those currently defined, and any (current or new) keys for + that modifier are logically in the down state, then the status + reply is Busy, and none of the modifiers are changed. + + This request generates a DeviceMappingNotify event on a Success + status. The DeviceMappingNotify event will be sent only to + those clients that have expressed an interest in receiving that + event via the XSelectExtensionEvent request. + + A X server can impose restrictions on how modifiers can be + changed, for example, if certain keys do not generate up + transitions in hardware or if multiple modifier keys are not + supported. If some such restriction is violated, the status + reply is MappingFailed , and none of the modifiers are changed. + If the new keycodes specified for a modifier differ from those + currently defined and any (current or new) keys for that + modifier are in the logically down state, the status reply is + MappingBusy, and none of the modifiers are changed. + +2.20 Controlling Button Mapping + + These requests are analogous to the core GetPointerMapping and + ChangePointerMapping requests. They allow a client to determine + the current mapping of buttons on an extension device, and to + change that mapping. + + To get the current button mapping for an extension device, use + GetDeviceButtonMapping. + + GetDeviceButtonMapping + device: DEVICE + nmap: CARD8 + => + map_return: LISTofCARD8 + + Errors: Device, Match + + The GetDeviceButtonMapping function returns the current mapping + of the buttons on the specified device. Elements of the list + are indexed starting from one. The length of the list indicates + the number of physical buttons. The nominal mapping is the + identity mapping map[i]=i. + + nmap indicates the number of elements in the map_return array. + Only the first nmap entries will be copied by the library into + the map_return array. + + To set the button mapping for an extension device, use + SetDeviceButtonMapping. + + SetDeviceButtonMapping + device: DEVICE + map: LISTofCARD8 + nmap: CARD8 + => + status: CARD8 + + Errors: Device, Match, Value + + The SetDeviceButtonMapping function sets the mapping of the + specified device and causes the X server to generate a + DeviceMappingNotify event on a status of MappingSuccess. + Elements of the list are indexed starting from one. The length + of the list, specified in nmap, must be the same as + GetDeviceButtonMapping would return. Otherwise, + SetDeviceButtonMapping generates a Value error. A zero element + disables a button, and elements are not restricted in value by + the number of physical buttons. If any of the buttons to be + altered are in the down state, the status reply is MappingBusy + and the mapping is not changed. + + In servers supporting XI 1.x, no two elements can have the same + nonzero value. Otherwise, this function generates a Value + error. + +2.21 Obtaining The State Of A Device + + To obtain vectors that describe the state of the keys, buttons + and valuators of an extension device, use QueryDeviceState. + + QueryDeviceState + device: DEVICE + => + device-id: CARD8 + data: LISTofINPUTCLASS + + where + + INPUTCLASS: {VALUATOR, BUTTON, KEY} + CLASS VALUATOR: + [class: CARD8 + num_valuators: CARD8 + mode: CARD8 + #x01 device mode (0 = Relative, 1 = Absolute) + #x02 proximity state (0 = InProximity, 1 = OutOfProximity) + valuators: LISTofINT32] + CLASS BUTTON: + [class: CARD8 + num_buttons: CARD8 + buttons: LISTofCARD8] + CLASS KEY: + [class: CARD8 + num_keys: CARD8 + keys: LISTofCARD8] + + Errors: Device + + The QueryDeviceState request returns the current logical state + of the buttons, keys, and valuators on the specified input + device. The buttons and keys arrays, byte N (from 0) contains + the bits for key or button 8N to 8N+7 with the least + significant bit in the byte representing key or button 8N. + + If the device has valuators, a bit in the mode field indicates + whether the device is reporting Absolute or Relative data. If + it is reporting Absolute data, the valuators array will contain + the current value of the valuators. If it is reporting Relative + data, the valuators array will contain undefined data. + + If the device reports proximity information, a bit in the mode + field indicates whether the device is InProximity or + OutOfProximity. + +2.22 Listing Device Properties + + Introduced with XI 1.5 + + ListDeviceProperties + deviceid: CARD8 + => + nAtoms: CARD16 + Atoms: LISTofATOM + + Errors: Device + + Each device can store an arbitrary number of properties. These + properties can be allocated by either the client or the driver. + The client can change device properties and the server + guarantees that the device driver is notified about a change of + the device's properties. + + ListDeviceProperties returns all properties of a device. The + client is expected to retrieve details about the properties it + is interested in separately. + +2.23 Getting a Device Property + + Introduced with XI 1.5 + + GetDeviceProperty: + property: ATOM + type: ATOM + longOffset: CARD32 + longLength: CARD32 + deviceid: CARD8 + delete: BOOL + => + propertyType: ATOM + bytesAfter: CARD32 + nItems: CARD32 + format: CARD8 + deviceid: CARD8 + data: [LISTofCARD8] + + Errors: Atom, Device, Value, Access + + Retrieve the value for a property. If the property does not + exist, propertyType is None and all other fields are undefined. + + If type is not AnyPropertyType and does not match the + property's actual type, the propertyType, bytesAfter, and + format are returned but not the actual data. + + longOffset and longLength specify the offset and length + respectively in 32-bit multiples of the data to retrieve. + + If delete is True, the property is deleted after querying its + data. If the property cannot be deleted, a BadAccess error is + returned. + + propertyType returns the atom identifier that defines the + actual type of the property. + + If bytesAfter is non-zero, it specifies the number of data + 4-byte units after the retrieved chunk of data. + + format specifies whether the data should be viewed as a list of + 8-bit, 16-bit, or 32-bit quantities. Possible values are 8, 16, + and 32. This information allows the X server to correctly + perform byte-swap operations as necessary. + + nItem specifies the number of 8-bit, 16-bit, or 32-bit items + returned after the request. + +2.24 Changing a Device Property + + Introduced with XI 1.5 + + ChangeDeviceProperty: + property: ATOM + type: ATOM + deviceid: CARD8 + format: CARD8 + mode: CARD8 + nUnits: CARD32 + + Errors: Atom, Device, Value, Match, Access + + Changes the value of a specified property. + + The type specifies the atom identifier that defines the type of + the property. If mode is not PropModeReplace, the type must + match the current type of the property or a BadMatch error is + returned. + + format specifies whether the data should be viewed as a list of + 8-bit, 16-bit, or 32-bit quantities. Possible values are 8, 16, + and 32. This information allows the X server to correctly + perform byte-swap operations as necessary. + + If mode is PropModeReplace, a preexising value for this + property is replaced with the new value. If mode is + PropModePrepend or PropModeAppend, the value is prepended or + appended, respectively, to the current value of the property. + + nUnits specifies the number of 8-bit, 16-bit, or 32-bit items + supplied after the reply. + + Changing a device property results in a + DevicePropertyNotifyEvent being sent to all clients. + +2.25 Deleting a Device Property + + Introduced with XI 1.5 + + DeleteDeviceProperty: + property: ATOM + deviceid: CARD8 + + Errors: Atom, Device, Match, Access. + + Deletes the specified property. If the property cannot be + deleted by the client, a BadAccess error is returned. + +3. Events + + The input extension creates input events analogous to the core + input events. These extension input events are generated by + manipulating one of the extension input devices. + +3.1 Button, Key, and Motion Events + + DeviceKeyPress + DeviceKeyRelease + DeviceButtonPress, + DeviceButtonRelease + DeviceMotionNotify + device: CARD8 + root, event: WINDOW + child: Window or None + same-screen: BOOL + root-x, root-y, event-x, event-y: INT16 + detail: + state: SETofKEYBUTMASK + time: TIMESTAMP + + These events are generated when a key, button, or valuator + logically changes state. The generation of these logical + changes may lag the physical changes, if device event + processing is frozen. Note that DeviceKeyPress and + DeviceKeyRelease are generated for all keys, even those mapped + to modifier bits. The “source” of the event is the window the + pointer is in. The window with respect to which the event is + normally reported is found by looking up the hierarchy + (starting with the source window) for the first window on which + any client has selected interest in the event. The actual + window used for reporting can be modified by active grabs and + by the focus window.The window the event is reported with + respect to is called the “event” window. + + The root is the root window of the “source” window, and root-x + and root-y are the pointer coordinates relative to root's + origin at the time of the event. Event is the “event” window. + If the event window is on the same screen as root, then event-x + and event-y are the pointer coordinates relative to the event + window's origin. Otherwise, event-x and event-y are zero. If + the source window is an inferior of the event window, then + child is set to the child of the event window that is an + ancestor of (or is) the source window. Otherwise, it is set to + None. + + The state component gives the logical state of the buttons on + the X pointer and modifier keys on the core X keyboard just + before the event. + + The detail component type varies with the event type: + Event Component + DeviceKeyPress KEYCODE + DeviceKeyRelease KEYCODE + DeviceButtonPress BUTTON + DeviceButtonRelease BUTTON + DeviceMotionNotify { Normal , Hint } + + The granularity of motion events is not guaranteed, but a + client selecting for motion events is guaranteed to get at + least one event when a valuator changes. If DeviceMotionHint is + selected, the server is free to send only one + DeviceMotionNotify event (with detail Hint) to the client for + the event window, until either a key or button changes state, + the pointer leaves the event window, or the client issues a + QueryDeviceState or GetDeviceMotionEvents request. + +3.2 DeviceValuator Event + + DeviceValuator + device: CARD8 + device_state: SETofKEYBUTMASK + num_valuators: CARD8 + first_valuator: CARD8 + valuators: LISTofINT32 + + DeviceValuator events are generated to contain valuator + information for which there is insufficient space in DeviceKey, + DeviceButton, DeviceMotion, and Proximity wire events. For + events of these types, a second event of type DeviceValuator + follows immediately. The library combines these events into a + single event that a client can receive via XNextEvent. + DeviceValuator events are not selected for by clients, they + only exist to contain information that will not fit into some + event selected by clients. + + The device_state component gives the state of the buttons and + modifiers on the device generating the event. + + Extension motion devices may report motion data for a variable + number of axes. The valuators array contains the values of all + axes reported by the device. If more than 6 axes are reported, + more than one DeviceValuator event will be sent by the server, + and more than one DeviceKey, DeviceButton, DeviceMotion, or + Proximity event will be reported by the library. Clients should + examine the corresponding fields of the event reported by the + library to determine the total number of axes reported, and the + first axis reported in the current event. Axes are numbered + beginning with zero. + + For Button, Key and Motion events on a device reporting + absolute motion data the current value of the device's + valuators is reported. For devices that report relative data, + Button and Key events may be followed by a DeviceValuator event + that contains 0s in the num_valuators field. In this case, only + the device_state component will have meaning. + +3.3 Device Focus Events + + DeviceFocusIn + DeviceFocusOut + device: CARD8 + time: TIMESTAMP + event: WINDOW + mode: { Normal, WhileGrabbed, Grab, Ungrab} + detail: { Ancestor, Virtual, Inferior, Nonlinear, + NonlinearVirtual, Pointer, PointerRoot, None} + + These events are generated when the input focus changes and are + reported to clients selecting DeviceFocusChange for the + specified device and window. Events generated by SetDeviceFocus + when the device is not grabbed have mode Normal. Events + generated by SetDeviceFocus when the device is grabbed have + mode WhileGrabbed. Events generated when a device grab actives + have mode Grab, and events generated when a device grab + deactivates have mode Ungrab. + + All DeviceFocusOut events caused by a window unmap are + generated after any UnmapNotify event, but the ordering of + DeviceFocusOut with respect to generated EnterNotify, + LeaveNotify, VisibilityNotify and Expose events is not + constrained. + + DeviceFocusIn and DeviceFocusOut events are generated for focus + changes of extension devices in the same manner as focus events + for the core devices are generated. + +3.4 Device State Notify Event + + DeviceStateNotify + time: TIMESTAMP + device: CARD8 + num_keys: CARD8 + num_buttons: CARD8 + num_valuators: CARD8 + classes_reported: CARD8 {SetOfDeviceMode | SetOfInputClass} + SetOfDeviceMode: + #x80 ProximityState 0 = InProxmity, 1 = OutOfProximity + #x40 Device Mode (0 = Relative, 1 = Absolute) + SetOfInputClass: #x04 reporting valuators + #x02 reporting buttons + #x01 reporting keys + buttons: LISTofCARD8 + keys: LISTofCARD8 + valuators: LISTofCARD32 + + This event reports the state of the device just as in the + QueryDeviceState request. This event is reported to clients + selecting DeviceStateNotify for the device and window and is + generated immediately after every EnterNotify and + DeviceFocusIn. If the device has no more than 32 buttons, no + more than 32 keys, and no more than 3 valuators, This event can + report the state of the device. If the device has more than 32 + buttons, the event will be immediately followed by a + DeviceButtonStateNotify event. If the device has more than 32 + keys, the event will be followed by a DeviceKeyStateNotify + event. If the device has more than 3 valuators, the event will + be followed by one or more DeviceValuator events. + +3.5 Device KeyState and ButtonState Notify Events + + DeviceKeyStateNotify + device: CARD8 + keys: LISTofCARD8 + DeviceButtonStateNotify + device: CARD8 + buttons: LISTofCARD8 + + These events contain information about the state of keys and + buttons on a device that will not fit into the + DeviceStateNotify wire event. These events are not selected by + clients, rather they may immediately follow a DeviceStateNotify + wire event and be combined with it into a single + DeviceStateNotify client event that a client may receive via + XNextEvent. + +3.6 DeviceMappingNotify Event + + DeviceMappingNotify + time: TIMESTAMP + device: CARD8 + request: CARD8 + first_keycode: CARD8 + count: CARD8 + + This event reports a change in the mapping of keys, modifiers, + or buttons on an extension device. This event is reported to + clients selecting DeviceMappingNotify for the device and window + and is generated after every client SetDeviceButtonMapping, + ChangeDeviceKeyMapping, or ChangeDeviceModifierMapping request. + +3.7 ChangeDeviceNotify Event + + ChangeDeviceNotify + device: CARD8 + time: TIMESTAMP + request: CARD8 + + This event reports a change in the physical device being used + as the core X keyboard or X pointer device. ChangeDeviceNotify + events are reported to clients selecting ChangeDeviceNotify for + the device and window and is generated after every client + ChangeKeyboardDevice or ChangePointerDevice request. + +3.7 Proximity Events + + ProximityIn + ProximityOut + device: CARD8 + root, event: WINDOW + child: Window or None + same-screen: BOOL + root-x, root-y, event-x, event-y: INT16 + state: SETofKEYBUTMASK + time: TIMESTAMP + device-state: SETofKEYBUTMASK + axis-count: CARD8 + first-axis: CARD8 + axis-data: LISTofINT32 + + These events are generated by some devices (such as graphics + tablets or touchscreens) to indicate that a stylus has moved + into or out of contact with a positional sensing surface. + + The “source” of the event is the window the pointer is in. The + window with respect to which the event is normally reported is + found by looking up the hierarchy (starting with the source + window) for the first window on which any client has selected + interest in the event. The actual window used for reporting can + be modified by active grabs and by the focus window.The window + the event is reported with respect to is called the “event” + window. + + The root is the root window of the “source” window, and root-x + and root-y are the pointer coordinates relative to root's + origin at the time of the event. Event is the “event” window. + If the event window is on the same screen as root, then event-x + and event-y are the pointer coordinates relative to the event + window's origin. Otherwise, event-x and event-y are zero. If + the source window is an inferior of the event window, then + child is set to the child of the event window that is an + ancestor of (or is) the source window. Otherwise, it is set to + None. The state component gives the logical state of the + buttons on the core X pointer and modifier keys on the core X + keyboard just before the event. The device-state component + gives the state of the buttons and modifiers on the device + generating the event. + +3.8 DevicePresenceEvents + + Introduced with XI 1.4. + + DevicePresence + time: TIMESTAMP + devchange: BYTE + #x00: DeviceAdded + #x01: DeviceRemoved + #x02: DeviceEnabled + #x03: DeviceDisabled + #x04: DeviceUnrecoverable + #x05: DeviceControlChanged + deviceid: BYTE + control: CARD16 + + DevicePresence events are sent when the server adds or removes, + or enables or disables an input device. The client is expected + to query the server for the list of input devices using the + ListInputDevices request to obtain the updated list of input + devices. DevicePresence events are also sent when a control on + the device has been changed. + + The devchange field specifies the type of operation. In case of + DeviceAdded, a new device has been added to the server, but + this device does not yet send events. If devchange is set to + DeviceEnabled, the device is enabled and will generate events. + If the field is DeviceDisabled or DeviceRemoved, the given + device is disabled and stops sending events or was removed from + the server, respectively. If the field is DeviceUnrecoverable, + an IO-error has occured on the device and the device is + forcibly disabled and removed by the server. If devchange is + DeviceControlChanged, control specifies the type of control + that has been changed. + +3.9 DevicePropertyNotifyEvent + + Introduced with XI 1.5. + + DevicePropertyNotifyEvent + deviceid: CARD8 + state: CARD8 + time: TIMESTAMP + atom: ATOM + + A DevicePropertyNotifyEvent is sent to all clients when a + property on the device is created, deleted, or changes value. + + The deviceid specifies the device which's property has been + modified. + + The atom specifies the named identifier of the property that + has been altered. + + If state is PropertyNewValue, the given property has a new + value or has been newly created. If state is PropertyDeleted, + the given property has been deleted. From 34a9ab1151fb7b35a371cc98a34a20993816f78a Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 2 Oct 2009 11:38:12 +1000 Subject: [PATCH 203/388] inputproto 2.0 Signed-off-by: Peter Hutterer --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 5c43cca..1052dc2 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.57]) -AC_INIT([InputProto], [1.9.99.902], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [2.0], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) # Require xorg-macros: XORG_DEFAULT_OPTIONS From 9ad88d954d544db29972144f5a778bb05d9b19ad Mon Sep 17 00:00:00 2001 From: Gaetan Nadon Date: Sat, 14 Nov 2009 18:26:47 -0500 Subject: [PATCH 204/388] .gitignore: use common defaults with custom section # 24239 Using common defaults will reduce errors and maintenance. Only the very small or inexistent custom section need periodic maintenance when the structure of the component changes. Do not edit defaults. --- .gitignore | 84 +++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 74 insertions(+), 10 deletions(-) diff --git a/.gitignore b/.gitignore index 28ba404..d1359e6 100644 --- a/.gitignore +++ b/.gitignore @@ -1,14 +1,78 @@ +# +# X.Org module default exclusion patterns +# The next section if for module specific patterns +# +# Do not edit the following section +# GNU Build System (Autotools) +aclocal.m4 +autom4te.cache/ +autoscan.log +ChangeLog +compile +config.guess +config.h +config.h.in +config.log +config-ml.in +config.py +config.status +config.status.lineno +config.sub +configure +configure.scan +depcomp +.deps/ +INSTALL +install-sh +.libs/ +libtool +libtool.m4 +ltmain.sh +lt~obsolete.m4 +ltoptions.m4 +ltsugar.m4 +ltversion.m4 Makefile Makefile.in -aclocal.m4 -autom4te.cache -config.log -config.status -configure -install-sh +mdate-sh missing -inputproto.pc +mkinstalldirs +*.pc +py-compile +stamp-h? +symlink-tree +texinfo.tex +ylwrap + +# Do not edit the following section +# Edit Compile Debug Document Distribute *~ -inputproto-*.tar.* -ChangeLog -tags +*.[0-9] +*.[0-9]x +*.bak +*.bin +core +*.dll +*.exe +*-ISO*.bdf +*-JIS*.bdf +*-KOI8*.bdf +*.kld +*.ko +*.ko.cmd +*.lai +*.l[oa] +*.[oa] +*.obj +*.patch +*.so +*.pcf.gz +*.pdb +*.tar.bz2 +*.tar.gz +# +# Add & Override patterns for inputproto +# +# Edit the following section as needed +# For example, !report.pc overrides *.pc. See 'man gitignore' +# From bf66af595c9b43e4086401a11c5a7b269857f039 Mon Sep 17 00:00:00 2001 From: Gaetan Nadon Date: Sun, 15 Nov 2009 13:55:25 -0500 Subject: [PATCH 205/388] configure.ac: AM_MAINTAINER_MODE missing #24238 This turns off maintainer mode build rules in tarballs. Works in conjunction with autogen.sh --enable-maintainer-mode --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index 1052dc2..0e547c9 100644 --- a/configure.ac +++ b/configure.ac @@ -1,6 +1,7 @@ AC_PREREQ([2.57]) AC_INIT([InputProto], [2.0], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) +AM_MAINTAINER_MODE # Require xorg-macros: XORG_DEFAULT_OPTIONS m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.3 or later before running autoconf/autogen])]) From 2ee03af19d17c973072bbacaf7ab44a8fd8b64b1 Mon Sep 17 00:00:00 2001 From: Gaetan Nadon Date: Sun, 15 Nov 2009 18:11:36 -0500 Subject: [PATCH 206/388] configure.ac: deploy the new XORG_DEFAULT_OPTIONS #24242 This macro aggregate a number of existing macros that sets commmon X.Org components configuration options. It shields the configuration file from future changes. --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 0e547c9..2e3f2b6 100644 --- a/configure.ac +++ b/configure.ac @@ -4,9 +4,9 @@ AM_INIT_AUTOMAKE([foreign dist-bzip2]) AM_MAINTAINER_MODE # Require xorg-macros: XORG_DEFAULT_OPTIONS -m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.3 or later before running autoconf/autogen])]) +m4_ifndef([XORG_MACROS_VERSION], + [m4_fatal([must install xorg-macros 1.3 or later before running autoconf/autogen])]) XORG_MACROS_VERSION(1.3) - XORG_DEFAULT_OPTIONS AC_OUTPUT([Makefile From ee09bc24cebbb18c2a2ed81336ab4ead600d2e94 Mon Sep 17 00:00:00 2001 From: Gaetan Nadon Date: Sun, 15 Nov 2009 18:31:28 -0500 Subject: [PATCH 207/388] Makefile.am: INSTALL file is missing or incorrect #24206 The standard GNU file on building/installing tarball is copied using the XORG_INSTALL macro contained in XORG_DEFAULT_OPTIONS Add INSTALL target --- Makefile.am | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index 85ca02f..b7fcbc5 100644 --- a/Makefile.am +++ b/Makefile.am @@ -13,9 +13,12 @@ EXTRA_DIST = inputproto.pc.in EXTRA_DIST += ChangeLog XI2proto.txt XIproto.txt MAINTAINERCLEANFILES = ChangeLog -.PHONY: ChangeLog +.PHONY: ChangeLog INSTALL + +INSTALL: + $(INSTALL_CMD) ChangeLog: $(CHANGELOG_CMD) -dist-hook: ChangeLog +dist-hook: ChangeLog INSTALL From 7ddcd9b428797e37c3d362b27975b157647aceeb Mon Sep 17 00:00:00 2001 From: Gaetan Nadon Date: Sun, 15 Nov 2009 19:45:26 -0500 Subject: [PATCH 208/388] Makefile.am: ChangeLog not required: EXTRA_DIST or *CLEANFILES #24432 ChangeLog filename is known to Automake and requires no further coding in the makefile. --- Makefile.am | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index b7fcbc5..e49f90d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -10,8 +10,7 @@ pkgconfig_DATA = inputproto.pc EXTRA_DIST = inputproto.pc.in -EXTRA_DIST += ChangeLog XI2proto.txt XIproto.txt -MAINTAINERCLEANFILES = ChangeLog +EXTRA_DIST += XI2proto.txt XIproto.txt .PHONY: ChangeLog INSTALL From 30c2e875941b1dcce06821fb0c5af6a15ca98d4e Mon Sep 17 00:00:00 2001 From: Gaetan Nadon Date: Mon, 16 Nov 2009 11:13:30 -0500 Subject: [PATCH 209/388] README: file created or updated #24206 Contains a set of URLs to freedesktop.org. --- README | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 README diff --git a/README b/README new file mode 100644 index 0000000..6b98e2b --- /dev/null +++ b/README @@ -0,0 +1,30 @@ + X Input Extension + +This extension defines a protocol to provide additional input devices +management such as graphic tablets. + +Extension name: XInputExtension + +All questions regarding this software should be directed at the +Xorg mailing list: + + http://lists.freedesktop.org/mailman/listinfo/xorg + +Please submit bug reports to the Xorg bugzilla: + + https://bugs.freedesktop.org/enter_bug.cgi?product=xorg + +The master development code repository can be found at: + + git://anongit.freedesktop.org/git/xorg/proto/inputproto + + http://cgit.freedesktop.org/xorg/proto/inputproto + +For patch submission instructions, see: + + http://www.x.org/wiki/Development/Documentation/SubmittingPatches + +For more information on the git code manager, see: + + http://wiki.x.org/wiki/GitPage + From e0ec5c81eef67a2b98396189b22b439953b616c0 Mon Sep 17 00:00:00 2001 From: Gaetan Nadon Date: Sun, 22 Nov 2009 19:24:48 -0500 Subject: [PATCH 210/388] Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES Now that the INSTALL file is generated. Allows running make maintainer-clean. --- Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index e49f90d..5954c43 100644 --- a/Makefile.am +++ b/Makefile.am @@ -9,9 +9,10 @@ pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = inputproto.pc EXTRA_DIST = inputproto.pc.in - EXTRA_DIST += XI2proto.txt XIproto.txt +MAINTAINERCLEANFILES = ChangeLog INSTALL + .PHONY: ChangeLog INSTALL INSTALL: From 0746aed42e50d7ac10fd1545cf6b89a8bc809884 Mon Sep 17 00:00:00 2001 From: Gaetan Nadon Date: Mon, 21 Dec 2009 19:00:00 -0500 Subject: [PATCH 211/388] Add Red Had Copyright in the COPYING file. Refer to XI2.h and XI2proto.h Signed-off-by: Gaetan Nadon --- COPYING | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/COPYING b/COPYING index aac40e8..f0b75c0 100644 --- a/COPYING +++ b/COPYING @@ -39,3 +39,25 @@ ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + +Copyright © 2009 Red Hat, Inc. + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + From 33bab5091b5c16133d88269744f5305dfd4e4fcb Mon Sep 17 00:00:00 2001 From: Gaetan Nadon Date: Sun, 28 Mar 2010 17:46:57 -0400 Subject: [PATCH 212/388] config: install and distribute XI2proto.txt XIproto.txt It will now be installed in $docdir in addition to being distributed in the tarball. Signed-off-by: Gaetan Nadon --- Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 5954c43..62e247b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -8,8 +8,9 @@ input_HEADERS = \ pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = inputproto.pc +dist_doc_DATA = XI2proto.txt XIproto.txt + EXTRA_DIST = inputproto.pc.in -EXTRA_DIST += XI2proto.txt XIproto.txt MAINTAINERCLEANFILES = ChangeLog INSTALL From 5e22edcb54a29393ffb72e4014010835d1ceab69 Mon Sep 17 00:00:00 2001 From: Gaetan Nadon Date: Sun, 28 Mar 2010 19:00:31 -0400 Subject: [PATCH 213/388] config: remove the pkgconfig pc.in file from EXTRA_DIST Automake always includes it in the tarball. Signed-off-by: Gaetan Nadon --- Makefile.am | 1 - 1 file changed, 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 62e247b..77d1ea7 100644 --- a/Makefile.am +++ b/Makefile.am @@ -10,7 +10,6 @@ pkgconfig_DATA = inputproto.pc dist_doc_DATA = XI2proto.txt XIproto.txt -EXTRA_DIST = inputproto.pc.in MAINTAINERCLEANFILES = ChangeLog INSTALL From b2e8bd74f0922e742ab41e9ccc202c0fdd9e152f Mon Sep 17 00:00:00 2001 From: Gaetan Nadon Date: Sun, 28 Mar 2010 19:25:52 -0400 Subject: [PATCH 214/388] config: update AC_PREREQ statement to 2.60 Unrelated to the previous patches, the new value simply reflects the reality that the minimum level for autoconf to configure all x.org modules is 2.60 dated June 2006. ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.60.tar.gz Signed-off-by: Gaetan Nadon --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 2e3f2b6..7466dc3 100644 --- a/configure.ac +++ b/configure.ac @@ -1,4 +1,4 @@ -AC_PREREQ([2.57]) +AC_PREREQ([2.60]) AC_INIT([InputProto], [2.0], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) AM_MAINTAINER_MODE From 617c4a2db48e98d06f728fa6b8caa18fbbfb66fc Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 23 Nov 2009 10:21:17 +1000 Subject: [PATCH 215/388] XI2proto.txt: fix up some request names. Leftovers from previous versions of the spec before the requests were renamed. Signed-off-by: Peter Hutterer --- XI2proto.txt | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/XI2proto.txt b/XI2proto.txt index 706f50a..79a1483 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -296,7 +296,7 @@ are required to be 0. value: FP3232 resolution: CARD32 } - XIQueryDevices details information about the requested input devices. + XIQueryDevice details information about the requested input devices. devices The device to list. If devices is AllDevices, all enabled and @@ -871,7 +871,7 @@ are required to be 0. └─── This request releases the device if this client has it actively grabbed - (from either XIGrabDevice, XIGrabDeviceKey or XIGrabDeviceButton) and + (from either XIGrabDevice or XIPassiveGrabDevice) and releases any queued events. If any devices were frozen by the grab, XIUngrabDevice thaws them. @@ -1223,7 +1223,7 @@ are required to be 0. until server reset. A property cannot be deleted by setting nitems to zero. To delete a - property, use XIDeleteDeviceProperty. + property, use XIDeleteProperty. This request generates an XIPropertyEvent. @@ -1443,8 +1443,7 @@ EVENTHEADER { type: BYTE 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 XQueryInputDevice - request. + For a detailed description of classes, see the XQueryDevice request. ┌─── DeviceEvent: @@ -1554,8 +1553,8 @@ EVENTHEADER { type: BYTE axisvalues_raw: LISTofFP3232 └─── - A RawDevice event provides the information provided by the driver to the - client. RawDevice provide both the raw data as supplied by the driver and + 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 not limited to, axis clipping and acceleration. Transformed valuator data may be equivalent to raw data. In this case, From 993ca70d7ecfb88037edfd77bccfcb671aea4c7b Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 11 Jan 2010 17:02:55 +1000 Subject: [PATCH 216/388] Define the error cases for XSetDeviceMode better. Take the error codes as described in the man page for XSetDeviceMode. This is more likely to be what clients expect, especially since the protocol spec doesn't actually define when BadMode is to be reported. This behaviour is the same as specified in the XSetDeviceMode man page. Signed-off-by: Peter Hutterer Reviewed-by: Fernando Carrijo --- XIproto.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/XIproto.txt b/XIproto.txt index 20cc02a..f9d19f0 100644 --- a/XIproto.txt +++ b/XIproto.txt @@ -577,7 +577,9 @@ already has the device open with a different mode. It will fail and return AlreadyGrabbed if another client has the device grabbed. The request will fail with a BadMatch error if the - requested mode is not supported by the device. + device has no valuators and reports no axes of motion. The + request will fail with a BadMode error if the requested mode + is not supported by the device. SetDeviceMode device:DEVICE From 3dc8e70f761f7da338c632a5acb0176bef515b33 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 6 Aug 2010 09:52:33 +1000 Subject: [PATCH 217/388] Spell out event types for XIDeviceEvent. Signed-off-by: Peter Hutterer --- XI2proto.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/XI2proto.txt b/XI2proto.txt index 79a1483..78eae8e 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -1485,7 +1485,8 @@ EVENTHEADER { type: BYTE 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. + press or a key release. The event type may be one of KeyPress, + KeyRelease, ButtonPress, ButtonRelease, Motion. detail The button number or key code, or 0. From 52e92f280c4e065d6a3f040493a0b46d2c8bee1d Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Mon, 2 Aug 2010 15:53:52 +1000 Subject: [PATCH 218/388] Typo fix: GrabTypeFocusIn -> GrabtypeFocusIn Signed-off-by: Peter Hutterer --- XI2proto.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XI2proto.txt b/XI2proto.txt index 78eae8e..10f58c2 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -999,7 +999,7 @@ are required to be 0. └─── GRABTYPE { GrabtypeButton, GrabtypeKeycode, GrabtypeEnter, - GrabTypeFocusIn} + GrabtypeFocusIn} GRABMODIFIERINFO { status: Access modifiers: CARD32 } From 56ffb564712257e0f998170e83071a6ee85aa231 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Thu, 11 Nov 2010 14:10:26 +1000 Subject: [PATCH 219/388] inputproto 2.0.1 Signed-off-by: Peter Hutterer --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 7466dc3..39e4df9 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.60]) -AC_INIT([InputProto], [2.0], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_INIT([InputProto], [2.0.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) AM_MAINTAINER_MODE From 5c2d5fd99d73ae52aef62376046b5708c58a4271 Mon Sep 17 00:00:00 2001 From: Chase Douglas Date: Fri, 17 Dec 2010 17:11:09 +0000 Subject: [PATCH 220/388] Include stdint.h I'm now getting build failures due to missing stdint.h. It seems we should include it explicitly in XI2proto.h anyways. Signed-off-by: Chase Douglas Signed-off-by: Daniel Stone Signed-off-by: Peter Hutterer --- XI2proto.h | 1 + 1 file changed, 1 insertion(+) diff --git a/XI2proto.h b/XI2proto.h index 2fd91eb..84574a5 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -60,6 +60,7 @@ #include #include #include +#include /* make sure types have right sizes for protocol structures. */ #define Window uint32_t From 13baef91f071ee1607f4c3bf6c1fea60e6651b89 Mon Sep 17 00:00:00 2001 From: Fernando Carrijo Date: Thu, 27 Jan 2011 22:40:11 -0200 Subject: [PATCH 221/388] Fix typos in XIproto.txt Signed-off-by: Fernando Carrijo Signed-off-by: Peter Hutterer --- XIproto.txt | 30 ++++++++++-------------------- 1 file changed, 10 insertions(+), 20 deletions(-) diff --git a/XIproto.txt b/XIproto.txt index f9d19f0..83cf9dd 100644 --- a/XIproto.txt +++ b/XIproto.txt @@ -1650,7 +1650,7 @@ feedback class BellFeedback, which is reported in the BellFeedbackState structure. The members of that structure are: - CLASS String: + CLASS Bell: [class: CARD8 length: CARD16 feedback id: CARD8 @@ -1676,7 +1676,7 @@ class Led, which is reported in the LedFeedbackState structure. The members of that structure are: - CLASS String: + CLASS Led: [class: CARD8 length: CARD16 feedback id: CARD8 @@ -1781,7 +1781,7 @@ feedback id: CARD8 int_to_display: INT32] - Some devices are capable of displaying an string. This is done + Some devices are capable of displaying a string. This is done using feedback class StringFeedbackClass using the StringFeedbackCtl structure. The members of that structure are as follows: @@ -1978,29 +1978,19 @@ Controlling Device Encoding A server can impose restrictions on how modifiers can be changed (for example, if certain keys do not generate up transitions in hardware or if multiple keys per modifier are - not supported). The status reply is Failed if some such - restriction is violated, and none of the modifiers are changed. + not supported). If some such restriction is violated, the status + reply is MappingFailed, and none of the modifiers are changed. - If the new non-zero keycodes specified for a modifier differ - from those currently defined, and any (current or new) keys for - that modifier are logically in the down state, then the status - reply is Busy, and none of the modifiers are changed. + If the new keycodes specified for a modifier differ from those + currently defined and any (current or new) keys for that + modifier are in the logically down state, the status reply is + MappingBusy, and none of the modifiers are changed. This request generates a DeviceMappingNotify event on a Success status. The DeviceMappingNotify event will be sent only to those clients that have expressed an interest in receiving that event via the XSelectExtensionEvent request. - A X server can impose restrictions on how modifiers can be - changed, for example, if certain keys do not generate up - transitions in hardware or if multiple modifier keys are not - supported. If some such restriction is violated, the status - reply is MappingFailed , and none of the modifiers are changed. - If the new keycodes specified for a modifier differ from those - currently defined and any (current or new) keys for that - modifier are in the logically down state, the status reply is - MappingBusy, and none of the modifiers are changed. - 2.20 Controlling Button Mapping These requests are analogous to the core GetPointerMapping and @@ -2350,7 +2340,7 @@ Controlling Device Encoding specified device and window. Events generated by SetDeviceFocus when the device is not grabbed have mode Normal. Events generated by SetDeviceFocus when the device is grabbed have - mode WhileGrabbed. Events generated when a device grab actives + mode WhileGrabbed. Events generated when a device grab activates have mode Grab, and events generated when a device grab deactivates have mode Ungrab. From 99f15a2346c882237c78afbd638932f132d6113c Mon Sep 17 00:00:00 2001 From: Daniel Stone Date: Mon, 7 Feb 2011 10:19:06 +0000 Subject: [PATCH 222/388] Add touch classes and events, bump to 2.1 Introduce multitouch support through a new TouchClass, as well as new TouchBegin, TouchEnd, TouchOwnership, TouchUpdate, and TouchUpdateUnowned events. Bump to version 2.1. Signed-off-by: Daniel Stone Co-authored-by: Chase Douglas Co-authored-by: Peter Hutterer --- XI2.h | 34 +++- XI2proto.h | 64 +++++++- XI2proto.txt | 431 +++++++++++++++++++++++++++++++++++++++++++++++++-- configure.ac | 2 +- 4 files changed, 514 insertions(+), 17 deletions(-) diff --git a/XI2.h b/XI2.h index 6ba1377..40c9ca6 100644 --- a/XI2.h +++ b/XI2.h @@ -36,6 +36,7 @@ #define XI_2_Major 2 #define XI_2_Minor 0 +#define XI_2_1_Minor 1 /* Property event flags */ #define XIPropertyDeleted 0 @@ -65,6 +66,8 @@ #define XIGrabtypeKeycode 1 #define XIGrabtypeEnter 2 #define XIGrabtypeFocusIn 3 +#define XIGrabtypeTouchBegin 4 +#define XIGrabtypeTouchBeginInert 5 /* Passive grab modifier */ #define XIAnyModifier (1U << 31) @@ -79,6 +82,11 @@ #define XIAsyncPair 4 #define XISyncPair 5 +/* XIAllowTouchEvents bitmask event-modes */ +#define XITouchOwnerAccept (1 << 0) +#define XITouchOwnerRejectEnd (1 << 1) +#define XITouchOwnerRejectContinue (1 << 2) + /* DeviceChangedEvent change reasons */ #define XISlaveSwitch 1 #define XIDeviceChange 2 @@ -113,15 +121,27 @@ #define XISlaveKeyboard 4 #define XIFloatingSlave 5 -/* Device classes */ +/* Device classes: classes that are not identical to Xi 1.x classes must be + * numbered starting from 8. */ #define XIKeyClass 0 #define XIButtonClass 1 #define XIValuatorClass 2 +#define XITouchClass 8 +#define XITouchValuatorClass 9 /* Device event flags (common) */ /* Device event flags (key events only) */ #define XIKeyRepeat (1 << 16) /* Device event flags (pointer events only) */ +#define XIPointerEmulated (1 << 16) +/* Device event flags (touch events only) */ +#define XITouchPendingEnd (1 << 16) +/* Device event flags (touch end events only) */ +#define XITouchAccepted (1 << 17) + +/* Touch modes */ +#define XIDirectTouch 1 +#define XIDependentTouch 2 /* XI2 event mask macros */ #define XISetMask(ptr, event) (((unsigned char*)(ptr))[(event)>>3] |= (1 << ((event) & 7))) @@ -151,7 +171,12 @@ #define XI_RawButtonPress 15 #define XI_RawButtonRelease 16 #define XI_RawMotion 17 -#define XI_LASTEVENT XI_RawMotion +#define XI_TouchBegin 18 +#define XI_TouchEnd 19 +#define XI_TouchOwnership 20 +#define XI_TouchUpdate 21 +#define XI_TouchUpdateUnowned 22 +#define XI_LASTEVENT XI_TouchUpdateUnowned /* 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. */ @@ -177,5 +202,10 @@ #define XI_RawButtonPressMask (1 << XI_RawButtonPress) #define XI_RawButtonReleaseMask (1 << XI_RawButtonRelease) #define XI_RawMotionMask (1 << XI_RawMotion) +#define XI_TouchBeginMask (1 << XI_TouchBegin) +#define XI_TouchEndMask (1 << XI_TouchEnd) +#define XI_TouchOwnershipChangedMask (1 << XI_TouchOwnershipChanged) +#define XI_TouchUpdateMask (1 << XI_TouchUpdate) +#define XI_TouchUpdateUnownedMask (1 << XI_TouchUpdateUnowned) #endif /* _XI2_H_ */ diff --git a/XI2proto.h b/XI2proto.h index 84574a5..f6348b4 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -92,9 +92,10 @@ #define X_XIDeleteProperty 58 #define X_XIGetProperty 59 #define X_XIGetSelectedEvents 60 +#define X_XIAllowTouchEvents 61 /** Number of XI requests */ -#define XI2REQUESTS (X_XIGetSelectedEvents - X_XIQueryPointer + 1) +#define XI2REQUESTS (X_XIAllowTouchEvents - X_XIQueryPointer + 1) /** Number of XI2 events */ #define XI2EVENTS (XI_LASTEVENT + 1) @@ -188,6 +189,31 @@ typedef struct { uint16_t pad2; } xXIValuatorInfo; +/** + * Denotes multitouch capability on a device. + */ +typedef struct { + uint16_t type; /**< Always TouchClass */ + uint16_t length; /**< Length in 4 byte units */ + uint16_t sourceid; /**< source device for this class */ + uint8_t mode; /**< DirectTouch or DependentTouch */ + uint8_t num_touches; /**< Maximum number of touches (0==unlimited) */ +} xXITouchInfo; + +/** + * Denotes a multitouch valuator capability on a device. + * One XITouchValuatorInfo describes exactly one valuator (axis) on the device. + */ +typedef struct { + uint16_t type; /**< Always TouchValuatorClass */ + uint16_t length; /**< Length in 4 byte units */ + uint16_t sourceid; /**< source device for this class */ + uint16_t number; /**< Valuator number */ + Atom label; /**< Axis label */ + FP3232 min; /**< Min value */ + FP3232 max; /**< Max value */ + uint32_t resolution; /**< Resolutions in units/m */ +} xXITouchValuatorInfo; /** * Used to select for events on a given window. @@ -772,6 +798,20 @@ 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 * @@ -857,7 +897,27 @@ typedef struct } xXIDeviceChangedEvent; /** - * Default input event for pointer or keyboard input. + * The owner of a touch stream has passed on ownership to another client. + */ +typedef struct +{ + uint8_t type; /**< Always GenericEvent */ + uint8_t extension; /**< XI extension offset */ + uint16_t sequenceNumber; + uint32_t length; /**< Length in 4 byte units */ + uint16_t evtype; /**< XI_TouchOwnership */ + uint16_t deviceid; /**< Device that has changed */ + Time time; + uint16_t sourceid; /**< Source of the new classes */ + uint16_t pad0; + uint32_t touchid; + uint32_t flags; + uint32_t pad1; + uint32_t pad2; +} xXITouchOwnershipEvent; + +/** + * Default input event for pointer, keyboard or touch input. */ typedef struct { diff --git a/XI2proto.txt b/XI2proto.txt index 10f58c2..5ebe59d 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -1,11 +1,20 @@ The X Input Extension Version 2.0 + Version 2.1 Peter Hutterer peter.hutterer@redhat.com Red Hat, Inc. + Daniel Stone + daniel@fooishbar.org + Collabora, Ltd. + + Chase Douglas + chase.douglas@canonical.com + Canonical, Ltd. + 1. Introduction @@ -31,6 +40,41 @@ 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). +1.1 X Input Extension version 2.1 (XI 2.1) +XI 2.1 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 multiple independent input points per physical device. +Furthermore, as such devices are often direct input devices (e.g. touchscreens, +able to focus without a pointer), the virtual abstraction of master devices is +not always necessary. + +The additions in XI 2.1 aim to: +- support a dynamic number of simultaneous touch points, +- support devices that are both multi-touch and traditional pointer devices, +- while supporting pre-XI2.1 clients through emulation of XI 2.0 and core + pointer events. + +XI 2.1 caters for two modes of touch input devices: +- direct multi-touch input devices such as touch screens. These devices + provide independent touchpoints that can occur anywhere on the screen and + are usually the result of direct touch interaction. +- indirect touch input devices such as multi-touch trackpads. These devices + provide independent touchpoints that may need to be interpreted + relative to the current position of the pointer on that same device. Such + interactions are usually the result of a gesture performed on the device. + +A device may change its touch mode at runtime. Clients are informed which +type of touch device they are dealing with. See XIQueryDevice for more +information. + +Touch device support is only available to clients supporting version 2.1 or +later of the X Input Extension. Clients must use the XIQueryVersion request to +announce support of this version. + +XI 2.1 requires devices to track touch points over time. Devices that cannot +do so in hardware must employ software trackers to be usable with XI 2.1. + ❧❧❧❧❧❧❧❧❧❧❧ 2. Notations used in this document @@ -149,7 +193,76 @@ 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 +4.4 Touch device support +Touch event processing differs from normal event processing in a few ways, +most notably in that touch events are processed partially out-of-band from +pointer and keyboard events. + +Touch input follows a three-stage cycle: init - move - move - ... - destroy, +i.e. “init” the sequence by touching the device, “move” the current touch +location any number of times, and finally “destroy” the sequence by ceasing +to touch the device. The init and destroy stage of this sequence are always +present, while the move 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 at least TouchBegin, +TouchOwnership, TouchUpdate, and TouchEnd simultaneously; it may also select +for TouchUpdateUnowned events if it wants to receive the full touch stream, +rather than just the final state. + +A touch sequence is only considered to be meaningful in its entirety: clients +may not capture part of a touch sequence, interpret only that part, and then +pass a partial touch sequence on to the next client. To this end, all clients +with active “grabs” on the window hierarchy for a touch sequence receive events +from that touch sequence, as well as the client with the deepest selection +(i.e. furthest from the root window). Clients currently in control of the +touch sequence receive TouchUpdate events, whereas clients not in control +receive TouchUpdateUnowned events. + +Touch grabs are similar to standard input event grabs in that they take +precedence over selections and are searched from the root window to the child +window. The first grab found for a touch sequence will be the owner of that +touch sequence, however events for that touch sequence will continue to be +delivered to all clients with grabs in the window tree, as well as the client +with the deepest selection. The first client may either “accept” the touch, +which claims the touch sequence and stops delivery to all other clients for +the duration of the touch sequence, or “reject” the touch sequence, which +will remove that client from the delivery set and pass ownership on to the +next client. + +Window sets for direct device touches 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. For +the first dependent touch on a device, the window set contains the windows from +the root to the current window underneath the position of the device's pointer. +For subsequent touches on this device, the window set is identical to +the window set of the first touch. Once all touches have been released, the +window set is reset and re-calculated on the first subsequent touch. + +No touches from a dependent device may begin while the device is floating, as +it does not have an associated pointer position to focus events. + +If there is no touch grab on a window and the server supports pointer +emulation, it will look for a pointer grab on that window and include it as +part of the delivery set; similarly, if no client has selected to receive +touch events on a window, the server may look for pointer event selections +on that window to add to the delivery set. + +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, nor is it +affected by new grabs or selections. + +A TouchEnd event will always be sent to a client when it will receive no more +events from a particular touch, regardless of why (grab or selection removed, +owner accepted, the client having rejected that touch, etc). + +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 +implementation-specific, however any pointer event generated from a touch +event will have the PointerEmulated flag set. Emulated pointer/keyboard events +follow the core and XI2 grab semantics. + +4.5. The ClientPointer principle Many core protocol and some extension requests are ambiguous when multiple master devices are available (e.g. QueryPointer does not specfy which pointer). @@ -271,7 +384,7 @@ are required to be 0. name: LISTofCHAR8 classes: LISTofCLASS } - CLASS { BUTTONCLASS, KEYCLASS, AXISCLASS } + CLASS { BUTTONCLASS, KEYCLASS, AXISCLASS, TOUCHCLASS*, TOUCHAXISCLASS* } BUTTONCLASS { type: ButtonClass length: CARD16 @@ -296,6 +409,26 @@ are required to be 0. value: FP3232 resolution: CARD32 } + TOUCHCLASS* { type: TouchClass + length: CARD16 + sourceid: CARD16 + mode: TOUCHMODE + num_touches: CARD16 } + + TOUCHAXISCLASS* { + type: TouchAxisClass + length: CARD16 + sourceid: CARD16 + axisnumber: CARD16 + label: ATOM + min: FP3232 + max: FP3232 + resolution: CARD32 } + + TOUCHMODE* { DirectTouch, DependentTouch } + + * since XI 2.1 + XIQueryDevice details information about the requested input devices. devices @@ -397,6 +530,54 @@ are required to be 0. 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. + XI 2.1: + + 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. Touch sequences from a device + of type DirectTouch should be interpreted as directly occuring on + the position they are reported on. Touch sequences from a device of + type DependentTouch should be interpreted as dependent of the + current position of the pointer. + 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. + + A device with a TouchClass must provide one or more TOUCHAXISCLASS + specifiers. + + TouchAxisClass: + type + Always TouchAxisClass. + length + Length in 4 byte units. + sourceid + The device this class originates from. + axisnumber + Axis number of this axis. The axis number is in device-native + order and potential axis mappings are ignored. + label + Atom specifying the axis name. An Atom of None specifies an unlabeled + axis. + min + Minimum value for this axis. + max + Maximum value for this axis. + resolution + Resolution in counts/meter. + + Devices generating touch events must provide exactly one TouchClass and + two or more TouchAxisClasses. TouchAxisClasses and AxisClasses are not + interchangable. A TouchAxisClass may only be part of a touch event, + whereas an AxisClass may only be part of non-touch events. + ┌─── XISelectEvents window: Window @@ -439,6 +620,14 @@ are required to be 0. 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_TouchOwnership, + XI_TouchUpdate or XI_TouchEnd must select for all three events at the + same time, else BadValue will be returned. A client selecting for + XI_TouchUpdateUnowned 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. + ┌─── XIGetSelectedEvents window: Window @@ -794,7 +983,8 @@ are required to be 0. 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.1 + touch events. deviceid The device to grab. @@ -999,7 +1189,8 @@ are required to be 0. └─── GRABTYPE { GrabtypeButton, GrabtypeKeycode, GrabtypeEnter, - GrabtypeFocusIn} + GrabtypeFocusIn, GrabtypeTouchBegin, + GrabtypeTouchBeginInert } GRABMODIFIERINFO { status: Access modifiers: CARD32 } @@ -1015,7 +1206,8 @@ are required to be 0. 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 @@ -1030,6 +1222,8 @@ are required to be 0. 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. + Must be Asynchronous for GrabtypeTouchBegin and + GrabtypeTouchBeginInert (see section 4.4). mask_len Length of mask in 4 byte units. mask @@ -1087,6 +1281,16 @@ are required to be 0. - a passive grab of the same grab_type + modifier combination does not does not exist on an ancestor of grab_window. + Or if grab_type is GrabtypeTouchBegin or GrabtypeTouchBeginInert, a + touch grab (see section 4.4) begins if: + - a touch begins in grab_window or one of its ancestors, and + - the specified modifier keys are down + Ownership of the touch sequence is granted to the grabbing client if: + - grab_type is not GrabtypeTouchBeginInert, and + - a TouchBegin, TouchBeginInert, or pointer passive grab 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 @@ -1097,6 +1301,9 @@ are required to be 0. 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 or GrabtypeTouchBeginInert grab is released when + the touch sequence ends, or a client uses XIAllowTouchEvents to reject + the touch and remove itself from the touch delivery sequence. 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. @@ -1109,10 +1316,11 @@ are required to be 0. 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 @@ -1133,6 +1341,11 @@ are required to be 0. XIPassiveUngrabNotify are generated and sent to the grabbing client before the grab deactivates. + 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. + ┌─── XIPassiveUngrabDevice deviceid: DEVICEID @@ -1149,7 +1362,8 @@ are required to be 0. 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 @@ -1308,6 +1522,44 @@ are required to be 0. deleted from the device, and a XIPropertyNotify event is generated on the device. + ┌─── + XIAllowTouchEvents: (since XI 2.1) + deviceid: DEVICEID + touchid: CARD32 + event_mode: ALLOWTOUCHMODE + flags: SETofALLOWTOUCHFLAGS + └─── + + ALLOWTOUCHMODE { TouchOwnerAccept, TouchOwnerRejectEnd, + TouchOwnerRejectContinue } + ALLOWTOUCHFLAGS (none currently defined) + + The XIAllowTouchEvents request allows the current owner of a touch + sequence to direct further delivery. + + deviceid + The grabbed device ID. + touchid + The ID of the currently-grabbed touch sequence. + event_mode + Given TouchOwnerAccept, 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 TouchOwnerRejectEnd, 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. + Given TouchOwnerRejectContinue, the client is not interested in + ownership, but still wishes to receive TouchUpdate events; + 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. + 8. Events: @@ -1338,6 +1590,12 @@ Version 2.0: FocusIn FocusOut PropertyEvent +Version 2.1: + TouchBegin + TouchUpdate + TouchUpdateUnowned + TouchOwnership + TouchEnd All events have a set of common fields specified as EVENTHEADER. @@ -1481,15 +1739,20 @@ EVENTHEADER { type: BYTE DEVICEEVENTFLAGS (all events): none DEVICEEVENTFLAGS (key events only): { KeyRepeat } - DEVICEEVENTFLAGS (pointer events only): none + DEVICEEVENTFLAGS (pointer events only): { PointerEmulated } + DEVICEEVENTFLAGS (touch events only): { TouchPendingEnd } + DEVICEEVENTFLAGS (touch end events only): { TouchAccepted } 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.1: The event type may also be TouchBegin, TouchUpdate, + TouchUpdateUnowned, or TouchEnd. + detail - The button number or key code, or 0. + The button number, key code, touch ID, or 0. root event child @@ -1517,8 +1780,12 @@ EVENTHEADER { type: BYTE Button state before the event. valuators Bitmask of valuators provided in axisvalues. + XI 2.1: For event types TouchBegin, TouchUpdate, TouchUpdateUnowned, and + TouchEnd, the valuators are those specified as TouchAxisClass. axisvalues Valuator data in device-native resolution. + XI 2.1: For event types TouchBegin, TouchUpdate, TouchUpdateUnowned, and + TouchEnd, the valuators are those specified as TouchAxisClass. flags Miscellaneous information about this event; the union of the common flag set and either the key or pointer flag set, @@ -1526,6 +1793,20 @@ EVENTHEADER { type: BYTE 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 means that this event is an emulated pointer event + caused by a touch device. A client listening to touch events and pointer + events should ignore PointerEmulated events to avoid duplicate + processing. This is only valid for pointer events (MotionNotify, + ButtonPress, ButtonRelease). + 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 motion events once an event with TouchPendingEnd has been + received. Modifier state in mods is detailed as follows: base_mods @@ -1543,6 +1824,30 @@ EVENTHEADER { type: BYTE locked_group XKB locked group state. + XI 2.1: + + 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 touch axis valuator value + changes, or a 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 in value for each new + touch, wrapping back to 0 upon reaching the numerical limit of IDs. + + Touch events do not generate enter/leave events, and are not affected by + other grabs (including device freezing), although any pointer events + generated by emulation will still be subject to all the same constraints + as normal pointer events, including enter/leave events, and being affected + by frozen devices. + ┌─── RawEvent EVENTHEADER @@ -1673,5 +1978,107 @@ EVENTHEADER { type: BYTE what Specifies what has been changed. +XI 2.1: + + ┌─── + TouchOwnershipEvent (since XI 2.1): + EVENTHEADER + sourceid: DEVICEID + touchid: CARD32 + 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. + + sourceid + The source device that originally generated the event. + touchid + The identifier of the touch sequence. + flags + A bitmask of flags for this event. + ❧❧❧❧❧❧❧❧❧❧❧ + + +Appendix A: XI 2.1 Use-cases + +All use-cases that include the receiving and processing of touch events +require the client to announce XI 2.1 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|UpdateUnowned|Ownership|End} from D on W. + ⊳ C receives TouchBegin whenever a touch sequence starts within + W's borders. + ⊳ C receives a TouchOwnership event indicating that it is now the owner + of the touch sequence. + ⊳ C receives TouchUpdate events whenever a touch axis valuator value + changes for a touch sequence it received a TouchBegin event for. + ⊳ C receives TouchEnd whenever a touch it received an TouchBegin event + for ceases. + +∙ Client C wants to process touch events from a device D on window W, while + client I wants to pre-process these events. + ⊳ C calls XISelectEvent for + XI_Touch{Begin|Update|UpdateUnowned|Ownership|End} from D on W. + ⊳ I calls XIPassiveGrab for + XI_Touch{Begin|Update|UpdateUnowned|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 a touch axis valuator changes in this touch sequence, I receives a + TouchUpdate event, while C receives a TouchUpdateUnowned event. I may + process the events to determine if it is going to claim or reject the + touch, whereas C may perform reversible processing. + ⊳ If I decides it is going to claim the event for its exclusive + processing, it calls XIAllowTouchEvents with the XITouchOwnerAccept flag + set; at this point, C receives a TouchEnd event with the + TouchAccepted flag set, and undoes any processing it may have done + on the touch sequence. Further TouchUpdate events are delivered only + to I. + ⊳ Alternately, if I decides it does not want to receive further events from + this touch sequence, it calls XIAllowTouchEvents with the + XITouchOwnerReject 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. + ⊳ When the touch physically ceases, a TouchEnd event is sent to all + clients still receiving TouchUpdate events. + +∙ Client C wants to process touch events from a device D on window W, while + client I wants to process pointer events on window Y, which is W's parent. + ⊳ I calls XIPassiveGrab for XI_{ButtonPress,MotionNotify,ButtonRelease} + from D on Y. + ⊳ C calls XISelectEvent for + XI_Touch{Begin|Update|UpdateUnowned|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, I will receive a MotionNotify event, and C + will receive a TouchUpdateUnowned event. Event delivery to I will be + subject to the standard delivery mechanism (including being queued if + the device is frozen, et al), while C receives events as soon as they + are processed by the server. + ⊳ I may assert ownership by calling XIAllowEvents on Y with AsyncDevice, + which will cause all further events to be sent only to I, with a + TouchEnd event being sent to C. + ⊳ Alternately, I may assert disinterest by calling XIAllowEvents on Y + with 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 TouchMotion. + +∙ Driver DRV provides touch support from tracked device D: + ⊳ DRV initializes a TouchClass for the device and a TouchAxisClass for + each axis available on 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. diff --git a/configure.ac b/configure.ac index 39e4df9..894d2cd 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.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) AM_MAINTAINER_MODE From db7c0eccc74e95f247d78541e4c4a28cfa87b5b4 Mon Sep 17 00:00:00 2001 From: Chase Douglas Date: Sun, 20 Feb 2011 16:35:09 -0500 Subject: [PATCH 223/388] Updates for pointer emulation and more touch device modes Also includes resolutions for dependent devices and implicit grabs and how to handle slave touch device attachment and touch selections. Signed-off-by: Chase Douglas --- XI2.h | 9 +-- XI2proto.txt | 196 ++++++++++++++++++++++++++++++++++++--------------- 2 files changed, 144 insertions(+), 61 deletions(-) diff --git a/XI2.h b/XI2.h index 40c9ca6..dbf14a8 100644 --- a/XI2.h +++ b/XI2.h @@ -32,6 +32,7 @@ #define Dont_Check 0 #endif #define XInput_2_0 7 +#define XInput_2_1 8 #define XI_2_Major 2 @@ -132,16 +133,16 @@ /* Device event flags (common) */ /* Device event flags (key events only) */ #define XIKeyRepeat (1 << 16) -/* Device event flags (pointer events only) */ +/* Device event flags (pointer and touch events only) */ #define XIPointerEmulated (1 << 16) /* Device event flags (touch events only) */ -#define XITouchPendingEnd (1 << 16) -/* Device event flags (touch end events only) */ -#define XITouchAccepted (1 << 17) +#define XITouchPendingEnd (1 << 17) /* Touch modes */ #define XIDirectTouch 1 #define XIDependentTouch 2 +#define XIIndependentPointer 3 +#define XISemiMultitouch 4 /* XI2 event mask macros */ #define XISetMask(ptr, event) (((unsigned char*)(ptr))[(event)>>3] |= (1 << ((event) & 7))) diff --git a/XI2proto.txt b/XI2proto.txt index 5ebe59d..212425d 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -52,7 +52,7 @@ not always necessary. The additions in XI 2.1 aim to: - support a dynamic number of simultaneous touch points, - support devices that are both multi-touch and traditional pointer devices, -- while supporting pre-XI2.1 clients through emulation of XI 2.0 and core +- while supporting pre-XI2.1 clients through emulation of XInput and core pointer events. XI 2.1 caters for two modes of touch input devices: @@ -194,6 +194,9 @@ delivered on W. Once an event has been delivered as either XI or core event, event processing stops. 4.4 Touch device support + +4.4.1 Touch event sequences + Touch event processing differs from normal event processing in a few ways, most notably in that touch events are processed partially out-of-band from pointer and keyboard events. @@ -205,62 +208,145 @@ to touch the device. The init and destroy stage of this sequence are always present, while the move 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 at least TouchBegin, -TouchOwnership, TouchUpdate, and TouchEnd simultaneously; it may also select -for TouchUpdateUnowned events if it wants to receive the full touch stream, -rather than just the final state. +TouchUpdate, and TouchEnd simultaneously. It may also select for +TouchUpdateUnowned and TouchOwnership events if it wants to receive the full +touch stream while other clients own or have active grabs involving the touch. +An example of this usage is a touch painting program that paints touches while +a gesture recognizer has an active grab. Such clients must be able to undo state +if the touch ends without the client receiving ownership of the touch. A touch sequence is only considered to be meaningful in its entirety: clients may not capture part of a touch sequence, interpret only that part, and then pass a partial touch sequence on to the next client. To this end, all clients -with active “grabs” on the window hierarchy for a touch sequence receive events -from that touch sequence, as well as the client with the deepest selection -(i.e. furthest from the root window). Clients currently in control of the -touch sequence receive TouchUpdate events, whereas clients not in control -receive TouchUpdateUnowned events. +with “grabs” on the window hierarchy for a touch sequence receive events from +that touch sequence, as well as potentially the client with the deepest +selection (i.e. furthest from the root window). Clients currently in control of +the touch sequence receive TouchUpdate events, whereas clients not in control +receive receive TouchUpdateUnowned events. Touch grabs are similar to standard input event grabs in that they take precedence over selections and are searched from the root window to the child window. The first grab found for a touch sequence will be the owner of that touch sequence, however events for that touch sequence will continue to be -delivered to all clients with grabs in the window tree, as well as the client -with the deepest selection. The first client may either “accept” the touch, -which claims the touch sequence and stops delivery to all other clients for -the duration of the touch sequence, or “reject” the touch sequence, which +delivered to all clients with grabs in the window tree, as well as potentially +the client with the deepest selection. The first client may either “accept” the +touch, which claims the touch sequence and stops delivery to all other clients +for the duration of the touch sequence, or “reject” the touch sequence, which will remove that client from the delivery set and pass ownership on to the -next client. +next client. When a client, including the initial owner, becomes the owner of a +touch, it will receive a TouchOwnership event. When an owning client accepts a +touch, further clients receiving unowned events will receive TouchEnd events. -Window sets for direct device touches 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. For -the first dependent touch on a device, the window set contains the windows from -the root to the current window underneath the position of the device's pointer. -For subsequent touches on this device, the window set is identical to -the window set of the first touch. Once all touches have been released, the -window set is reset and re-calculated on the first subsequent touch. - -No touches from a dependent device may begin while the device is floating, as -it does not have an associated pointer position to focus events. - -If there is no touch grab on a window and the server supports pointer -emulation, it will look for a pointer grab on that window and include it as -part of the delivery set; similarly, if no client has selected to receive -touch events on a window, the server may look for pointer event selections -on that window to add to the delivery set. - -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, nor is it -affected by new grabs or selections. +Clients selecting for touch events may select for either unowned events or only +owned events. The event stream for an unowned selection is identical to a touch +grab. When a client does not select for unowned and ownership events, it will +receive a TouchBegin event when it becomes the owner of a touch stream. +TouchUpdate and TouchEnd events will be received in the same manner as for touch +grabs. A TouchEnd event will always be sent to a client when it will receive no more events from a particular touch, regardless of why (grab or selection removed, owner accepted, the client having rejected that touch, etc). -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 -implementation-specific, however any pointer event generated from a touch -event will have the PointerEmulated flag set. Emulated pointer/keyboard events -follow the core and XI2 grab semantics. +Only one client may select or grab touch events for a device on a window. As an +example, selecting for AllDevices will prevent any other client from selecting +on the same window. When a slave device is attached to a master device, any +selections on any windows for touch events for the slave device ID will be +canceled. Clients selecting for individual slave devices are suggested to select +for HierarchyChanged events to be notified when this occurs. + +4.4.2 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 according to where the touch occurs in the mapped + screen region. 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 pointer on screen. An Example of a DependentTouch device + is a trackpad. + +IndependentPointer: + These devices do not have any correlation between touch events and pointer + events. IndependentPointer devices are a subset of DependentTouch devices. + An example of an IndependentPointer device is a mouse with a touch surface. + +SemiMultitouch: + These devices may report touch events that correlate to the two opposite + corners of the bounding box of all touches. The number of active touch + sequences represents the number of touches on the device, and the position + of any given touch event will be equal to either of the two corners of the + bounding box. However, the physical location of the touches is unknown. + SemiMultitouch devices are a subset of DependentTouch devices. Although + DirectTouch and IndependentPointer devices may also be SemiMultitouch + devices, such devices are not allowed through this protocol. + +A device is identified as only one of the device modes above at any time. For +the purposes of this protocol, IndependentPointer and SemiMultitouch devices are +treated the same as DependentTouch devices unless stated otherwise. + +4.4.3 Touch event delivery + +Window sets for event propagation for direct device touches 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. For +the first dependent touch on a device, the window set contains the windows from +the root to the current window underneath the position of the device's pointer. +For subsequent touches on the device, the window set is identical to the window +set of the first touch. Once all touches have been released, the window set is +reset and re-calculated on the first subsequent 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, nor is it +affected by new grabs or selections. + +No touches from a dependent device may begin while the device is floating, as +it does not have an associated pointer position to focus events. + +In order to prevent touch events delivered to one window while pointer events +are implicitly grabbed by another, all touches from indirect devices will end +when an implicit grab is activated on the slave or attached master device. New +touches may begin while the device is implicitly grabbed. + +Many touch devices will emit pointer events as well, usually by mapping one +touch sequence to pointer events. In these cases, events for both the pointer +and its associated touch sequence will have the XIPointerEmulated flag set. + +4.4.4 Pointer emulation for direct touch devices + +In order to facilitate backwards compatibility with legacy clients, direct touch +devices will emulate pointer events. Pointer emulation events will only be +delivered through the attached master device; no pointer events will be emulated +for floating touch devices. Further, only one touch from any attached slave +touch device may be emulated per master device at any time. + +A touch event stream must be delivered to clients in a mutually exclusive +fashion. This extends to emulated pointer events. For the purposes of +exclusivity, emulated pointer events between an emulated button press and +button release are considered. An emulated button press event is considered +exclusively delivered once it has been delivered through an event selection, an +asynchronous pointer grab, or it and a further event are delivered through a +synchronous pointer grab. + +Touch and pointer grabs are also mutually exclusive. For a given window, any +touch grab is activated first. If the touch grab is rejected, the pointer grab +is activated. If an emulated button press event is exclusively delivered to the +grabbing client as outlined above, the touch sequence is ended for all clients +still listening for unowned events. Otherwise, when the pointer stream is +replayed the next window in the window set is checked for touch grabs. + +If the touch sequence is not exclusively delivered to any client through a grab, +the touch and emulated pointer events may be delivered to clients selecting for +the events. Event propagation for the touch sequence ends at the first client +selecting for touch and/or pointer events. Note that a client may receive both +touch and emulated pointer events for the same touch sequence through event +selection. 4.5. The ClientPointer principle @@ -425,7 +511,8 @@ are required to be 0. max: FP3232 resolution: CARD32 } - TOUCHMODE* { DirectTouch, DependentTouch } + TOUCHMODE* { DirectTouch, DependentTouch, IndependentPointer, + SemiMultitouch } * since XI 2.1 @@ -540,11 +627,7 @@ are required to be 0. sourceid The device this class originates from. mode - The device type of the touch device. Touch sequences from a device - of type DirectTouch should be interpreted as directly occuring on - the position they are reported on. Touch sequences from a device of - type DependentTouch should be interpreted as dependent of the - current position of the pointer. + The device type of the touch device. 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 @@ -866,6 +949,9 @@ are required to be 0. 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. @@ -1538,9 +1624,9 @@ are required to be 0. sequence to direct further delivery. deviceid - The grabbed device ID. + The slave device ID for a grabbed touch sequence. touchid - The ID of the currently-grabbed touch sequence. + The ID of the touch sequence to modify. event_mode Given TouchOwnerAccept, the client is deemed to have taken control of the touch sequence; TouchEnd events will be sent to all other @@ -1739,9 +1825,8 @@ EVENTHEADER { type: BYTE 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 } - DEVICEEVENTFLAGS (touch end events only): { TouchAccepted } 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 @@ -1840,13 +1925,10 @@ EVENTHEADER { type: BYTE 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. + touch, wrapping back to 0 upon reaching the numerical limit of IDs. IDs are + unique per each slave touch device. - Touch events do not generate enter/leave events, and are not affected by - other grabs (including device freezing), although any pointer events - generated by emulation will still be subject to all the same constraints - as normal pointer events, including enter/leave events, and being affected - by frozen devices. + Touch events do not generate enter/leave events. ┌─── RawEvent From a02566ca7fd37d279b957037e1251a3b3419866d Mon Sep 17 00:00:00 2001 From: Chase Douglas Date: Thu, 10 Mar 2011 11:53:57 -0500 Subject: [PATCH 224/388] Many more updates to the XI 2.1 protocol Signed-off-by: Chase Douglas --- XI.h | 11 -- XI2.h | 25 +--- XI2proto.h | 1 + XI2proto.txt | 383 +++++++++++++++++++++++++++++---------------------- 4 files changed, 228 insertions(+), 192 deletions(-) diff --git a/XI.h b/XI.h index 7b44399..378b34a 100644 --- a/XI.h +++ b/XI.h @@ -135,17 +135,6 @@ SOFTWARE. #define XI_FOOTMOUSE "FOOTMOUSE" #define XI_JOYSTICK "JOYSTICK" -/* Indices into the versions[] array (XExtInt.c). Used as a index to - * retrieve the minimum version of XI from _XiCheckExtInit */ -#define Dont_Check 0 -#define XInput_Initial_Release 1 -#define XInput_Add_XDeviceBell 2 -#define XInput_Add_XSetDeviceValuators 3 -#define XInput_Add_XChangeDeviceControl 4 -#define XInput_Add_DevicePresenceNotify 5 -#define XInput_Add_DeviceProperties 6 -/* DO NOT ADD TO HERE -> XI2 */ - #define XI_Absent 0 #define XI_Present 1 diff --git a/XI2.h b/XI2.h index dbf14a8..5ef8983 100644 --- a/XI2.h +++ b/XI2.h @@ -25,16 +25,6 @@ #ifndef _XI2_H_ #define _XI2_H_ -/* Indices into the versions[] array (XExtInt.c). Used as a index to - * retrieve the minimum version of XI from _XiCheckExtInit. - * For indices 0 to 6 see XI.h */ -#ifndef Dont_Check /* defined in XI.h */ -#define Dont_Check 0 -#endif -#define XInput_2_0 7 -#define XInput_2_1 8 - - #define XI_2_Major 2 #define XI_2_Minor 0 #define XI_2_1_Minor 1 @@ -68,7 +58,7 @@ #define XIGrabtypeEnter 2 #define XIGrabtypeFocusIn 3 #define XIGrabtypeTouchBegin 4 -#define XIGrabtypeTouchBeginInert 5 +#define XIGrabtypeTouchObserve 5 /* Passive grab modifier */ #define XIAnyModifier (1U << 31) @@ -84,9 +74,9 @@ #define XISyncPair 5 /* XIAllowTouchEvents bitmask event-modes */ -#define XITouchOwnerAccept (1 << 0) -#define XITouchOwnerRejectEnd (1 << 1) -#define XITouchOwnerRejectContinue (1 << 2) +#define XITouchAccept (1 << 0) +#define XITouchReject (1 << 1) +#define XITouchObserve (1 << 2) /* DeviceChangedEvent change reasons */ #define XISlaveSwitch 1 @@ -133,9 +123,10 @@ /* Device event flags (common) */ /* Device event flags (key events only) */ #define XIKeyRepeat (1 << 16) -/* Device event flags (pointer and touch events only) */ +/* Device event flags (pointer events only) */ #define XIPointerEmulated (1 << 16) /* Device event flags (touch events only) */ +#define XIPointerEmulated (1 << 16) #define XITouchPendingEnd (1 << 17) /* Touch modes */ @@ -176,8 +167,7 @@ #define XI_TouchEnd 19 #define XI_TouchOwnership 20 #define XI_TouchUpdate 21 -#define XI_TouchUpdateUnowned 22 -#define XI_LASTEVENT XI_TouchUpdateUnowned +#define XI_LASTEVENT XI_TouchUpdate /* 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. */ @@ -207,6 +197,5 @@ #define XI_TouchEndMask (1 << XI_TouchEnd) #define XI_TouchOwnershipChangedMask (1 << XI_TouchOwnershipChanged) #define XI_TouchUpdateMask (1 << XI_TouchUpdate) -#define XI_TouchUpdateUnownedMask (1 << XI_TouchUpdateUnowned) #endif /* _XI2_H_ */ diff --git a/XI2proto.h b/XI2proto.h index f6348b4..a631335 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -944,6 +944,7 @@ 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/XI2proto.txt b/XI2proto.txt index 212425d..590a443 100644 --- a/XI2proto.txt +++ b/XI2proto.txt @@ -206,54 +206,76 @@ i.e. “init” the sequence by touching the device, “move” the current touc location any number of times, and finally “destroy” the sequence by ceasing to touch the device. The init and destroy stage of this sequence are always present, while the move 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 at least TouchBegin, -TouchUpdate, and TouchEnd simultaneously. It may also select for -TouchUpdateUnowned and TouchOwnership events if it wants to receive the full -touch stream while other clients own or have active grabs involving the touch. -An example of this usage is a touch painting program that paints touches while -a gesture recognizer has an active grab. Such clients must be able to undo state -if the touch ends without the client receiving ownership of the touch. +"touch sequence" is used to describe the above chain of events. In the this +protocol, the init stage is represented by a touch begin event, then move stage +is represented by a touch update event, and the destroy stage is represented by +a touch end event. -A touch sequence is only considered to be meaningful in its entirety: clients -may not capture part of a touch sequence, interpret only that part, and then -pass a partial touch sequence on to the next client. To this end, all clients -with “grabs” on the window hierarchy for a touch sequence receive events from -that touch sequence, as well as potentially the client with the deepest -selection (i.e. furthest from the root window). Clients currently in control of -the touch sequence receive TouchUpdate events, whereas clients not in control -receive receive TouchUpdateUnowned events. +Touch sequences may send events to multiple clients in parallel. At any given +time, only one client is in control of the touch sequence and is referred to as +the "owner" of the sequence. + +Clients may want to receive events only after they become the owner of a touch +sequence. This prevents unnecessary process wakeups and provides for simpler +handling of a stream of touch events. Such clients must select for touch begin, +update, and end events. When the client becomes the owner of a touch sequence, +a touch begin event will be sent. This event will represent the position and +properties of the touch when it began on the touch device. The server may buffer +copies of multiple touch update events while the touch sequence was owned by +another client. After sending the touch begin event, any buffered touch update +events will be sent. If the touch position or properties have changed since the +touch began, at least one touch update or touch end event will be sent to denote +the new position and properties. There is no guarantee that any more than one +touch update or touch end event will be buffered. The event timestamp of the +buffered events represent the time the event occurred. + +Other clients may want access to the stream of touch events from a touch +sequence before they become the owner of the sequence. Clients must use caution +when handling these events; any action taken must be undone if the touch +sequence ends without the client becoming the owner. Such clients must select +for touch begin, update, end, and ownership events. A touch begin event is sent +to all such clients when a touch sequence has initiated. When touch position or +properties are changed, the client will be sent touch update events. Once the +client, including the initial owner, becomes the owner of the touch sequence, a +touch ownership event will be sent. When the touch ends, the owner will receive +a touch end event if it is a touch grabbing client and has accepted the touch +sequence as outlined below or if it is receiving touch events through a +selection. Otherwise, the owner will receive a touch update event with the +pending end flag set. All other clients will receive a touch update event with +the pending end flag set. Touch grabs are similar to standard input event grabs in that they take precedence over selections and are searched from the root window to the child -window. The first grab found for a touch sequence will be the owner of that -touch sequence, however events for that touch sequence will continue to be -delivered to all clients with grabs in the window tree, as well as potentially -the client with the deepest selection. The first client may either “accept” the -touch, which claims the touch sequence and stops delivery to all other clients -for the duration of the touch sequence, or “reject” the touch sequence, which -will remove that client from the delivery set and pass ownership on to the -next client. When a client, including the initial owner, becomes the owner of a -touch, it will receive a TouchOwnership event. When an owning client accepts a -touch, further clients receiving unowned events will receive TouchEnd events. +window. When a touch grab is activated, the client will receive a touch +ownership event. The owner must either “accept” or "reject" the touch sequence, +though it may do so at any time, including after the touch sequence has ended. +If the owner accepts the touch sequence, touch end events will be sent to all +other clients listening to events from the touch sequence. If the owner rejects +the touch sequence, a touch end event will be sent to the owner and further +grabs will be checked for the touch sequence. If any touch client becomes the +owner of the touch sequence, it will be sent a touch ownership event. Touch +grabbing clients must register for touch ownership events through the grab and +be able to handle events while they are not the owner of the touch sequence. -Clients selecting for touch events may select for either unowned events or only -owned events. The event stream for an unowned selection is identical to a touch -grab. When a client does not select for unowned and ownership events, it will -receive a TouchBegin event when it becomes the owner of a touch stream. -TouchUpdate and TouchEnd events will be received in the same manner as for touch -grabs. +A touch sequence is only considered to be meaningful in its entirety: clients +may not capture part of a touch sequence, interpret only that part, and then +pass ownership of the touch sequence on to another client. A special exception +to this rule is made for clients who passively grab a touch with grab type +TouchObserve, or for when a client rejects a touch with mode TouchObserve. Such +clients are passed over for touch ownership, but will continue to receive touch +update events for the touch sequence. A TouchEnd event will always be sent to a client when it will receive no more events from a particular touch, regardless of why (grab or selection removed, -owner accepted, the client having rejected that touch, etc). +owner accepted, the client having rejected the touch, etc). -Only one client may select or grab touch events for a device on a window. As an -example, selecting for AllDevices will prevent any other client from selecting -on the same window. When a slave device is attached to a master device, any -selections on any windows for touch events for the slave device ID will be -canceled. Clients selecting for individual slave devices are suggested to select -for HierarchyChanged events to be notified when this occurs. +Only one client may select, and only one client may grab, touch events for a +physical device on a window. As an example, selecting for AllDevices will +prevent any other client from selecting for touch events for any device on the +same window. When a slave device is attached to a master device, any selections +on any windows for touch events for the slave device ID will be canceled. +Clients selecting for individual slave devices are suggested to select for +HierarchyChanged events to be notified when this occurs. 4.4.2 Touch device modes @@ -262,41 +284,41 @@ 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 according to where the touch occurs in the mapped - screen region. An example of a DirectTouch device is a touchscreen. + focus is determined according to where the touch occurs in the mapped screen + region. 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 pointer on screen. An Example of a DependentTouch device - is a trackpad. + location of the device's cursor. An Example of a DependentTouch device is a + trackpad. IndependentPointer: These devices do not have any correlation between touch events and pointer - events. IndependentPointer devices are a subset of DependentTouch devices. - An example of an IndependentPointer device is a mouse with a touch surface. + events. Pointer events are generated by physical interactions with the + device that are independent of any touch events. An example of an + IndependentPointer device is a mouse with a touch surface used for scrolling + or other gestural input. SemiMultitouch: - These devices may report touch events that correlate to the two opposite - corners of the bounding box of all touches. The number of active touch - sequences represents the number of touches on the device, and the position - of any given touch event will be equal to either of the two corners of the - bounding box. However, the physical location of the touches is unknown. - SemiMultitouch devices are a subset of DependentTouch devices. Although - DirectTouch and IndependentPointer devices may also be SemiMultitouch - devices, such devices are not allowed through this protocol. + These devices only report the number of touches and the bounding box of the + touches on the touch surface. The touch information is sent as one touch + event sequence with four touch valuators defining the bounding box. Touch + events are delivered according to the location of the device's cursor. + Although DirectTouch and IndependentPointer devices may also be + SemiMultitouch devices, such devices are not allowed through this protocol. A device is identified as only one of the device modes above at any time. For -the purposes of this protocol, IndependentPointer and SemiMultitouch devices are -treated the same as DependentTouch devices unless stated otherwise. +the purposes of this protocol document, indirect touch devices refers to +DependentTouch, IndependentPointer, and SemiMultitouch devices. 4.4.3 Touch event delivery Window sets for event propagation for direct device touches 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. For -the first dependent touch on a device, the window set contains the windows from +Indirect device window sets depend on whether other touches are active. For +the first touch on an indirect device, the window set contains the windows from the root to the current window underneath the position of the device's pointer. For subsequent touches on the device, the window set is identical to the window set of the first touch. Once all touches have been released, the window set is @@ -306,47 +328,78 @@ 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, nor is it affected by new grabs or selections. -No touches from a dependent device may begin while the device is floating, as +No touches from an indirect device may begin while the device is floating, as it does not have an associated pointer position to focus events. -In order to prevent touch events delivered to one window while pointer events -are implicitly grabbed by another, all touches from indirect devices will end -when an implicit grab is activated on the slave or attached master device. New -touches may begin while the device is implicitly grabbed. +4.4.4 Pointer event handling for indirect touch devices -Many touch devices will emit pointer events as well, usually by mapping one -touch sequence to pointer events. In these cases, events for both the pointer -and its associated touch sequence will have the XIPointerEmulated flag set. +Indirect touch devices are expected to generate pointer events. In contrast with +direct touch devices, as stated below, the server will not generate pointer +events on behalf of indirect touch devices. Further, pointer events from +indirect touch devices are delivered independently of touch events. -4.4.4 Pointer emulation for direct touch devices +DependentTouch and SemiMultitouch devices may generate pointer events by mapping +one touch sequence to the pointer. In these cases, events for both the pointer +and its associated touch sequence will have the PointerEmulated flag set. + +When the cursor of an attached master pointer of an indirect device leaves the +window of a touch grab or selection, or when a client activates a pointer grab +on either the master or slave device, touch begin and touch update events will +be withheld. When the pointer re-enters the window or the pointer grab is +deactivated, touch update events will be sent with updates to any touch +positions and properties since the last touch event sent. Touch begin events for +any new touches will also be sent, along with touch update events for new +touches that have changed position or properties since the touch began. No events +will be delivered for touches that began and ended while touch events were +withheld. + +4.4.5 Pointer emulation for direct touch devices In order to facilitate backwards compatibility with legacy clients, direct touch devices will emulate pointer events. Pointer emulation events will only be delivered through the attached master device; no pointer events will be emulated for floating touch devices. Further, only one touch from any attached slave -touch device may be emulated per master device at any time. +direct touch device may be emulated per master device at any time. -A touch event stream must be delivered to clients in a mutually exclusive -fashion. This extends to emulated pointer events. For the purposes of -exclusivity, emulated pointer events between an emulated button press and -button release are considered. An emulated button press event is considered -exclusively delivered once it has been delivered through an event selection, an -asynchronous pointer grab, or it and a further event are delivered through a -synchronous pointer grab. +Pointer events are emulated as follows: -Touch and pointer grabs are also mutually exclusive. For a given window, any -touch grab is activated first. If the touch grab is rejected, the pointer grab -is activated. If an emulated button press event is exclusively delivered to the -grabbing client as outlined above, the touch sequence is ended for all clients -still listening for unowned events. Otherwise, when the pointer stream is -replayed the next window in the window set is checked for touch grabs. +* Touch begin events generate a pointer motion event to the location of the + touch, followed by a button press event for button 1. +* Touch update events generate a pointer motion event to update the location + of the touch. +* Touch end events generate a pointer motion event to the location of the touch + if the touch has moved, followed by a button release event for button 1. -If the touch sequence is not exclusively delivered to any client through a grab, -the touch and emulated pointer events may be delivered to clients selecting for -the events. Event propagation for the touch sequence ends at the first client -selecting for touch and/or pointer events. Note that a client may receive both -touch and emulated pointer events for the same touch sequence through event -selection. +A touch sequence may only be owned by one client at a time. When pointer events +are emulated from a touch sequence and delivered through a pointer grab, the +grabbing client implicitly becomes the owner of the touch sequence. + +A pointer grabbing client is considered to have accepted ownership of the touch +sequence when the following occurs: + +* The emulated button press event is delivered through an asynchronous grab. +* The emulated button press event is delivered through a synchronous grab and + further events are allowed through to the grabbing client. +* The emulated button press event is delivered through a synchronous grab and + then the grab is deactivated without replaying the button press event. + +Touch and pointer grabs are mutually exclusive. For a given window, any touch +grab is activated first. If there is no touch grab or the touch grab is +rejected, any pointer grab is activated. If there is a pointer grab and the +grabbing client accepts ownership of the touch sequence as outlined above, the +touch sequence is ended for all other clients listening for touch events. +Otherwise, if there is no pointer grab or the grabbing client replays the +pointer events without accepting the touch sequence, the next window in the +window set is checked for grabs. + +If the touch sequence is not accepted by any client through a grab, the touch +and emulated pointer events may be delivered to a client selecting for them. +Event propagation for the touch sequence ends at the first client selecting for +touch or pointer events. If a window has both touch and pointer event +selections, only the touch events will be delivered. + +Both the emulated pointer events and their associated touch events will have the +PointerEmulated flag set. 4.5. The ClientPointer principle @@ -703,13 +756,12 @@ are required to be 0. 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_TouchOwnership, - XI_TouchUpdate or XI_TouchEnd must select for all three events at the - same time, else BadValue will be returned. A client selecting for - XI_TouchUpdateUnowned 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. + A client selecting for any of XI_TouchBegin, XI_TouchUpdate, or XI_TouchEnd + must select for all three events at the same time, else BadValue will be + returned. 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. ┌─── XIGetSelectedEvents @@ -1276,7 +1328,7 @@ are required to be 0. GRABTYPE { GrabtypeButton, GrabtypeKeycode, GrabtypeEnter, GrabtypeFocusIn, GrabtypeTouchBegin, - GrabtypeTouchBeginInert } + GrabtypeTouchObserve } GRABMODIFIERINFO { status: Access modifiers: CARD32 } @@ -1309,7 +1361,7 @@ are required to be 0. released. Actual device input events are not lost while the device is frozen; they are simply queued for later processing. Must be Asynchronous for GrabtypeTouchBegin and - GrabtypeTouchBeginInert (see section 4.4). + GrabtypeTouchObserve (see section 4.4). mask_len Length of mask in 4 byte units. mask @@ -1367,15 +1419,15 @@ are required to be 0. - a passive grab of the same grab_type + modifier combination does not does not exist on an ancestor of grab_window. - Or if grab_type is GrabtypeTouchBegin or GrabtypeTouchBeginInert, a + Or if grab_type is GrabtypeTouchBegin or GrabtypeTouchObserve, a touch grab (see section 4.4) begins if: - a touch begins in grab_window or one of its ancestors, and - the specified modifier keys are down Ownership of the touch sequence is granted to the grabbing client if: - - grab_type is not GrabtypeTouchBeginInert, and - - a TouchBegin, TouchBeginInert, or pointer passive grab with the same - modifier set does not exist on an ancestor of grab_window, or all - applicable grabs have released ownership. + - grab_type is not GrabtypeTouchObserve, and + - 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 @@ -1387,9 +1439,11 @@ are required to be 0. 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 or GrabtypeTouchBeginInert grab is released when - the touch sequence ends, or a client uses XIAllowTouchEvents to reject - the touch and remove itself from the touch delivery sequence. + A GrabtypeTouchBegin grab is released when the touch sequence ends or + the client uses XIAllowTouchEvents with mode TouchReject. + A GrabtypeTouchBegin grab is converted to a GrabtypeTouchObserve grab + when the client uses XIAllowTouchEvents with mode TouchObserve. + A GrabtypeTouchObserve grab is released when the touch sequence ends. 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. @@ -1616,8 +1670,7 @@ are required to be 0. flags: SETofALLOWTOUCHFLAGS └─── - ALLOWTOUCHMODE { TouchOwnerAccept, TouchOwnerRejectEnd, - TouchOwnerRejectContinue } + ALLOWTOUCHMODE { TouchAccept, TouchReject, TouchObserve } ALLOWTOUCHFLAGS (none currently defined) The XIAllowTouchEvents request allows the current owner of a touch @@ -1628,16 +1681,16 @@ are required to be 0. touchid The ID of the touch sequence to modify. event_mode - Given TouchOwnerAccept, 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 TouchOwnerRejectEnd, 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. - Given TouchOwnerRejectContinue, the client is not interested in - ownership, but still wishes to receive TouchUpdate events; - ownership will be passed on to the next listener. + 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. + Given TouchObserve, the client is not interested in ownership, but + still wishes to receive TouchUpdate events; ownership will be passed on + to the next listener. flags A bitmask of applicable flags. @@ -1679,7 +1732,6 @@ Version 2.0: Version 2.1: TouchBegin TouchUpdate - TouchUpdateUnowned TouchOwnership TouchEnd @@ -1707,7 +1759,7 @@ EVENTHEADER { type: BYTE deviceid Numerical device id for a device. time - Time in ms. + Time in ms when the event occurred. ┌─── @@ -1809,6 +1861,7 @@ EVENTHEADER { type: BYTE buttons: SETofBUTTONMASK valuators: SETofVALUATORMASK axisvalues: LISTofFP3232 + active_touches: CARD32 └─── BUTTONBIT { (1 << Button1), (1 << Button2), ... , (1 << ButtonN) } @@ -1833,8 +1886,7 @@ EVENTHEADER { type: BYTE press or a key release. The event type may be one of KeyPress, KeyRelease, ButtonPress, ButtonRelease, Motion. - XI 2.1: The event type may also be TouchBegin, TouchUpdate, - TouchUpdateUnowned, or TouchEnd. + XI 2.1: The event type may also be TouchBegin, TouchUpdate, or TouchEnd. detail The button number, key code, touch ID, or 0. @@ -1865,12 +1917,12 @@ EVENTHEADER { type: BYTE Button state before the event. valuators Bitmask of valuators provided in axisvalues. - XI 2.1: For event types TouchBegin, TouchUpdate, TouchUpdateUnowned, and - TouchEnd, the valuators are those specified as TouchAxisClass. + XI 2.1: For event types TouchBegin, TouchUpdate, and TouchEnd, the + valuators are those specified as TouchAxisClass. axisvalues Valuator data in device-native resolution. - XI 2.1: For event types TouchBegin, TouchUpdate, TouchUpdateUnowned, and - TouchEnd, the valuators are those specified as TouchAxisClass. + XI 2.1: For event types TouchBegin, TouchUpdate, and TouchEnd, the + valuators are those specified as TouchAxisClass. flags Miscellaneous information about this event; the union of the common flag set and either the key or pointer flag set, @@ -1892,6 +1944,14 @@ EVENTHEADER { type: BYTE accepted or passed on ownership. The touch will not generate any further motion events once an event with TouchPendingEnd has been received. + active_touches + Only in XI 2.1 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 + includes the new touch for a TouchBegin event, and does not include the + ending touch for a TouchEnd event. Modifier state in mods is detailed as follows: base_mods @@ -2093,68 +2153,65 @@ require the client to announce XI 2.1 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|UpdateUnowned|Ownership|End} from D on W. + XI_Touch{Begin|Update|End} from D on W. ⊳ C receives TouchBegin whenever a touch sequence starts within W's borders. - ⊳ C receives a TouchOwnership event indicating that it is now the owner - of the touch sequence. ⊳ C receives TouchUpdate events whenever a touch axis valuator value changes for a touch sequence it received a TouchBegin event for. - ⊳ C receives TouchEnd whenever a touch it received an TouchBegin event + ⊳ C receives TouchEnd whenever a touch it received a TouchBegin event for ceases. -∙ Client C wants to process touch events from a device D on window W, while - client I wants to pre-process these events. +∙ 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|UpdateUnowned|Ownership|End} from D on W. + XI_Touch{Begin|Update|Ownership|End} from D on W. ⊳ I calls XIPassiveGrab for - XI_Touch{Begin|Update|UpdateUnowned|Ownership|End} from D on a parent + 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 a touch axis valuator changes in this touch sequence, I receives a - TouchUpdate event, while C receives a TouchUpdateUnowned event. I may - process the events to determine if it is going to claim or reject the - touch, whereas C may perform reversible processing. - ⊳ If I decides it is going to claim the event for its exclusive - processing, it calls XIAllowTouchEvents with the XITouchOwnerAccept flag - set; at this point, C receives a TouchEnd event with the - TouchAccepted flag set, and undoes any processing it may have done - on the touch sequence. Further TouchUpdate events are delivered only - to I. - ⊳ Alternately, if I decides it does not want to receive further events from - this touch sequence, it calls XIAllowTouchEvents with the - XITouchOwnerReject flag set; at this point, I receives a TouchEnd event + ⊳ When a touch 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 XIAllowTouchEvents with the XITouchAccept flag set; + 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. - ⊳ When the touch physically ceases, a TouchEnd event is sent to all - clients still receiving TouchUpdate events. + ⊳ When the touch physically ceases, a TouchEnd event is sent to C. -∙ Client C wants to process touch events from a device D on window W, while - client I wants to process pointer events on window Y, which is W's parent. - ⊳ I calls XIPassiveGrab for XI_{ButtonPress,MotionNotify,ButtonRelease} - from D on Y. +∙ 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|UpdateUnowned|Ownership|End} from D on W. + 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, I will receive a MotionNotify event, and C - will receive a TouchUpdateUnowned event. Event delivery to I will be - subject to the standard delivery mechanism (including being queued if - the device is frozen, et al), while C receives events as soon as they - are processed by the server. - ⊳ I may assert ownership by calling XIAllowEvents on Y with AsyncDevice, - which will cause all further events to be sent only to I, with a - TouchEnd event being sent to C. - ⊳ Alternately, I may assert disinterest by calling XIAllowEvents on Y - with 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 TouchMotion. + ⊳ When the touchpoint moves, C will receive a TouchUpdate event. Event + delivery to I is be 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 and a TouchAxisClass for From f21f00bd9b8e641d639d70d086df1b14faa34e38 Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Wed, 16 Mar 2011 09:57:10 +1000 Subject: [PATCH 225/388] Add minimal asciidoc syntax Though this protocol description is mainly to be viewed as textfile, a few minor changes make it parsable for asciidoc to spit out reasonably nicely-formatted html code. Changes include: - underline section headers with the matching lines - add linebreaks before lists to parse them as lists - change indentation level for normal text to be left-marging aligned and for 
 text to be indented
- comment out section dividers

It's possible to run asciidoc XI2proto.txt and get some nice html output
now.

Reviewed-by: Gaetan Nadon 
Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 XI2proto.txt | 778 +++++++++++++++++++++++++++------------------------
 1 file changed, 408 insertions(+), 370 deletions(-)

diff --git a/XI2proto.txt b/XI2proto.txt
index 10f58c2..5d1b275 100644
--- a/XI2proto.txt
+++ b/XI2proto.txt
@@ -1,5 +1,6 @@
+The X Input Extension
+=====================
 
-                            The X Input Extension
                                 Version 2.0
 
                               Peter Hutterer
@@ -9,11 +10,13 @@
 
 
 1. Introduction
+---------------
 
 The X Input Extension version 2.0 (XI2) is the second major release of the X
 Input Extension.
 
 XI2 provides a number of enhancements over version 1.5, including:
+
 - use of XGE and GenericEvents. GenericEvents are of flexible length with a
   minimum length of 32 bytes.
 - explicit device hierarchy of master and slave devices. See Section 4.
@@ -31,47 +34,56 @@ 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. 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
-└───
+
+    ┌───
+        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
-└───
+
+    ┌───
+        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 }
+    COMPLEXFIELDTYPE:  { name of subfield:   type of subfield,
+                         name of subfield:   type of subfield }
 
-                              ❧❧❧❧❧❧❧❧❧❧❧
+//                            ❧❧❧❧❧❧❧❧❧❧❧
 
 3. Interoperability between version 1.x and 2.0
+-----------------------------------------------
 
 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
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 XI2 provides a larger range for some fields than XI1. As a result, XI1 clients
 may not receive data an XI2 client receives.
 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.
@@ -81,6 +93,7 @@ These fields include:
 
 
 3.2 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.
@@ -89,20 +102,23 @@ not be grabbed with the same modifier combination by an XI2 or XI 1.x client,
 respectively.
 
 3.3 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.
 
-                              ❧❧❧❧❧❧❧❧❧❧❧
+//                            ❧❧❧❧❧❧❧❧❧❧❧
 
 4. 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
+~~~~~~~~~~~~~~~~~~
 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
@@ -115,12 +131,14 @@ Clients can use this pairing behaviour to implement input paradigms that
 require pointer and keyboard interation (e.g. SHIFT + Click).
 
 4.2 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
 type (e.g. a physical pointer device can be attached to any master pointer).
 
 If an event is generated by an SD
+
 - if the SD is attached to a master pointer, it changes the position and/or
   button state of the master pointer.
 - if the SD is attached to a master keyboard, it sends events to this
@@ -132,8 +150,10 @@ If an event is generated by an SD
   program.
 
 4.3 Event processing for attached slave devices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Whenever an SD changes its logical state,
+
 - the event is delivered as an XI event to any interested clients. If the
   device is floating, event processing stops.
   Otherwise, if the device is attached,
@@ -150,6 +170,7 @@ delivered on W. Once an event has been delivered as either XI or core event,
 event processing stops.
 
 4.4. The ClientPointer principle
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Many core protocol and some extension requests are ambiguous when multiple
 master devices are available (e.g. QueryPointer does not specfy which pointer).
@@ -169,57 +190,63 @@ 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.
 
-                              ❧❧❧❧❧❧❧❧❧❧❧
+//                            ❧❧❧❧❧❧❧❧❧❧❧
+
 5. Data types
+-------------
 
-BUTTONMASK
-        A binary mask defined as (1 << button number).
-        A SETofBUTTONMASK is a binary OR of zero or more BUTTONMASK.
+    BUTTONMASK
+            A binary mask defined as (1 << button number).
+            A SETofBUTTONMASK is a binary OR of zero or more BUTTONMASK.
 
-DEVICE { DEVICEID, AllDevices, AllMasterDevices }
-        A DEVICE specifies either a DEVICEID or AllDevices or
-        AllMasterDevices.
+    DEVICE { DEVICEID, AllDevices, AllMasterDevices }
+            A DEVICE specifies either a DEVICEID or AllDevices or
+            AllMasterDevices.
 
-DEVICEID { CARD16 }
-        A DEVICEID is a numerical ID for a device currently available in the
-        server. The server may re-use a device ID after a device's removal.
-        The device IDs 0 and 1 are reserved.
-        AllDevices ........ 0
-        AllMasterDevices .. 1
+    DEVICEID { CARD16 }
+            A DEVICEID is a numerical ID for a device currently available in the
+            server. The server may re-use a device ID after a device's removal.
+            The device IDs 0 and 1 are reserved.
+            AllDevices ........ 0
+            AllMasterDevices .. 1
 
-DEVICEUSE { MasterPointer, MasterKeyboard, SlavePointer,
-            SlaveKeyboard, FloatingSlave }
-        A DEVICEUSE field specifies the current use of a device in the MD/SD
-        device hierarchy. See Section 4 for more information.
+    DEVICEUSE { MasterPointer, MasterKeyboard, SlavePointer,
+                SlaveKeyboard, FloatingSlave }
+            A DEVICEUSE field specifies the current use of a device in the MD/SD
+            device hierarchy. See Section 4 for more information.
 
-EVENTMASK
-        An EVENTMASK is a binary mask defined as (1 << event type).
-        A SETofEVENTMASK is a binary OR of zero or more EVENTMASK.
+    EVENTMASK
+            An EVENTMASK is a binary mask defined as (1 << event type).
+            A SETofEVENTMASK is a binary OR of zero or more EVENTMASK.
 
-FP1616
-        Fixed point decimal in 16.16 format as one INT16 and one CARD16.
-        The INT16 contains the integral part, the CARD32 the decimal fraction
-        shifted by 16.
+    FP1616
+            Fixed point decimal in 16.16 format as one INT16 and one CARD16.
+            The INT16 contains the integral part, the CARD32 the decimal fraction
+            shifted by 16.
 
-FP3232
-        Fixed point decimal in 32.32 format as one INT32 and one CARD32.
-        The INT32 contains the integral part, the CARD32 the decimal fraction
-        shifted by 32.
+    FP3232
+            Fixed point decimal in 32.32 format as one INT32 and one CARD32.
+            The INT32 contains the integral part, the CARD32 the decimal fraction
+            shifted by 32.
 
-VALUATORMASK
-        A binary mask defined as (1 << valuator number).
-        A SETofVALUATORMASK is a binary OR of zero or more VALUATORMASK.
+    VALUATORMASK
+            A binary mask defined as (1 << valuator number).
+            A SETofVALUATORMASK is a binary OR of zero or more VALUATORMASK.
+
+//                            ❧❧❧❧❧❧❧❧❧❧❧
 
-                              ❧❧❧❧❧❧❧❧❧❧❧
 6. Errors
+---------
 
 Errors are sent using core X error reports.
 
-Device
-        A value for a DEVICE argument does not specify a valid DEVICE.
+    Device
+            A value for a DEVICE argument does not specify a valid DEVICE.
+
+//                            ❧❧❧❧❧❧❧❧❧❧❧
 
-                              ❧❧❧❧❧❧❧❧❧❧❧
 7. 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
@@ -230,6 +257,7 @@ 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
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
     ┌───
         XIQueryVersion
@@ -240,19 +268,19 @@ are required to be 0.
         minor_version:          CARD16
     └───
 
-    The client sends the highest supported version to the server and the
-    server sends the highest version it supports, but no higher than the
-    requested version. Major versions changes can introduce incompatibilities
-    in existing functionality, minor version changes introduce only backward
-    compatible changes.  It is the client's responsibility to ensure that the
-    server supports a version which is compatible with its expectations.
+The client sends the highest supported version to the server and the
+server sends the highest version it supports, but no higher than the
+requested version. Major versions changes can introduce incompatibilities
+in existing functionality, minor version changes introduce only backward
+compatible changes.  It is the client's responsibility to ensure that the
+server supports a version which is compatible with its expectations.
 
     major_version
         Major XI2 version.
     minor_version
         Minor XI2 version.
 
-    If major_version is less than 2, a BadValue error occurs.
+If major_version is less than 2, a BadValue error occurs.
 
     ┌───
         XIQueryDevice
@@ -296,7 +324,7 @@ are required to be 0.
                   value:                FP3232
                   resolution:           CARD32 }
 
-    XIQueryDevice details information about the requested input devices.
+XIQueryDevice details information about the requested input devices.
 
     devices
         The device to list. If devices is AllDevices, all enabled and
@@ -306,7 +334,8 @@ are required to be 0.
     num_devices
         The number of deviceinfos returned.
 
-    Each deviceinfo is detailed as follows:
+Each deviceinfo is detailed as follows:
+
     deviceid
         The unique ID of the device. Device IDs may get re-used when a device
         is removed.
@@ -334,10 +363,10 @@ are required to be 0.
     name
         The device's name. padded to a multiple of 4 bytes.
 
-    For all classes, type specifies the device class. Clients are required
-    to ignore unknown device classes. The length field specifies the length
-    of the class in 4 byte units.
-    The following classes may occur only once: ButtonClass, KeyClass
+For all classes, type specifies the device class. Clients are required
+to ignore unknown device classes. The length field specifies the length
+of the class in 4 byte units.
+The following classes may occur only once: ButtonClass, KeyClass
 
     ButtonClass:
     type
@@ -394,8 +423,8 @@ are required to be 0.
     value
         Last published axis value (if mode is absolute).
 
-    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.
+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.
 
     ┌───
         XISelectEvents
@@ -420,24 +449,24 @@ are required to be 0.
     mask
         Event mask. An event mask for an event type T is defined as (1 << T).
 
-    XISelectEvents selects for XI2 events on window.
+XISelectEvents selects for XI2 events on window.
 
-    If num_masks is 0, a BadValue error occurs.
+If num_masks is 0, a BadValue error occurs.
 
-    Each mask sets the (and overwrites a previous) event mask for the DEVICE
-    specified through deviceid. The device AllDevices or
-    AllMasterDevices is treated as a separate device by server. A client's
-    event mask is the union of AllDevices, AllMasterDevices and the
-    per-device event mask.
-    The removal of device from the server unsets the event masks for the
-    device. If an event mask is set for AllDevices or AllMasterDevices, the
-    event mask is not cleared on device removal and affects all future
-    devices.
+Each mask sets the (and overwrites a previous) event mask for the DEVICE
+specified through deviceid. The device AllDevices or
+AllMasterDevices is treated as a separate device by server. A client's
+event mask is the union of AllDevices, AllMasterDevices and the
+per-device event mask.
+The removal of device from the server unsets the event masks for the
+device. If an event mask is set for AllDevices or AllMasterDevices, the
+event mask is not cleared on device removal and affects all future
+devices.
 
-    If mask_len is 0, the event mask for the given device is cleared.
+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.
+The mask for XIHierarchyEvents may only be selected for XIAllDevices.
+Setting it for any other device results in a BadValue error.
 
     ┌───
         XIGetSelectedEvents
@@ -454,13 +483,13 @@ are required to be 0.
     masks
         Selected event masks by this client.
 
-    Masks are returned on a per-device basis, with masks for AllDevices and
-    AllMasterDevices returned separately. A client can calculate the
-    effective mask for a device with a bitwise OR of the AllDevices, the
-    AllMasterDevices and the device-specific mask.
+Masks are returned on a per-device basis, with masks for AllDevices and
+AllMasterDevices returned separately. A client can calculate the
+effective mask for a device with a bitwise OR of the AllDevices, the
+AllMasterDevices and the device-specific mask.
 
-    If num_masks is 0, no events have been selected by this client on the
-    given window.
+If num_masks is 0, no events have been selected by this client on the
+given window.
 
     ┌───
         XIQueryPointer
@@ -480,7 +509,7 @@ are required to be 0.
             buttons:        SETofBUTTONMASK
     └───
 
-    Query a master pointer device for its current position.
+Query a master pointer device for its current position.
 
     root
         The root window the pointer is logically on.
@@ -503,8 +532,8 @@ are required to be 0.
     buttons
         Button state.
 
-    If the device is not a master pointer device or not a floating slave
-    pointer, a BadDevice error results.
+If the device is not a master pointer device or not a floating slave
+pointer, a BadDevice error results.
 
     ┌───
         XIWarpPointer
@@ -519,9 +548,9 @@ are required to be 0.
             deviceid:        DEVICEID
     └───
 
-    WarpPointer moves the pointer of deviceid as if the user had moved
-    the pointer. WarpPointer can only be called for MasterPointer and
-    FloatingSlave devices.
+WarpPointer moves the pointer of deviceid as if the user had moved
+the pointer. WarpPointer can only be called for MasterPointer and
+FloatingSlave devices.
 
     src_win
        If src_window is not None, the move only takes place if src_window
@@ -544,12 +573,12 @@ are required to be 0.
     deviceid
         The device to warp.
 
-    This request cannot be used to move the pointer outside the confine-to
-    window of an active pointer grab. An attempt will only move the pointer as
-    far as the closest edge of the confine-to window.
+This request cannot be used to move the pointer outside the confine-to
+window of an active pointer grab. An attempt will only move the pointer as
+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.
+This request will generate events just as if the user had instantaneously
+moved the pointer.
 
     ┌───
         XIChangeCursor
@@ -558,7 +587,7 @@ are required to be 0.
             deviceid:        DEVICEID
     └───
 
-    Change a master pointer's cursor on the specified window.
+Change a master pointer's cursor on the specified window.
 
     window
         The window.
@@ -567,19 +596,19 @@ are required to be 0.
     deviceid
         The master pointer device.
 
-    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
-      protocol's window attributes, display cursor C(w).
-    - repeat on parent window until a cursor has been found.
+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
+  protocol's window attributes, display cursor C(w).
+- repeat on parent window until a cursor has been found.
 
-    The device cursor for a given window is reset once the window is destroyed
-    or the device is removed, whichever comes earlier.
+The device cursor for a given window is reset once the window is destroyed
+or the device is removed, whichever comes earlier.
 
-    If deviceid does not specify a master pointer, a BadDevice error
-    is returned.
+If deviceid does not specify a master pointer, a BadDevice error
+is returned.
 
     ┌───
         XIChangeHierarchy
@@ -616,18 +645,18 @@ are required to be 0.
                   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 MD/SD device
+hierarchy (see Section 4).
 
     num_changes
         The number of changes to apply to the current hierarchy.
     changes
         The list of changes.
 
-    The server processes the changes in the order received from the client and
-    applies each requested change immediately. If an error occurs, processing
-    stops at the current change and returns the number of successfully applied
-    changes in the error.
+The server processes the changes in the order received from the client and
+applies each requested change immediately. If an error occurs, processing
+stops at the current change and returns the number of successfully applied
+changes in the error.
 
     ADDMASTER creates a pair of master devices.
     type
@@ -664,8 +693,8 @@ are required to be 0.
         return_mode is Attach. If return_mode is Float, return_pointer
         and return_keyboard are undefined.
 
-    Removing a master pointer removes the paired master keyboard and vice
-    versa.
+Removing a master pointer removes the paired master keyboard and vice
+versa.
 
     ATTACHSLAVE attaches a slave device to a given master device.
     type
@@ -691,30 +720,30 @@ are required to be 0.
             deviceid:        DEVICEID
     └───
 
-    Set the ClientPointer for the client owning win to the given device.
+Set the ClientPointer for the client owning win to the given device.
 
     win
          Window or client ID.
     deviceid
          The master pointer or master keyboard that acts as ClientPointer.
 
-    Some protocol requests are ambiguous and the server has to choose a device
-    to provide data for a request or a reply. By default, the server will
-    choose a client's ClientPointer device to provide the data, unless the
-    client currently has a grab on another device. See section 4.4 for more
-    details.
+Some protocol requests are ambiguous and the server has to choose a device
+to provide data for a request or a reply. By default, the server will
+choose a client's ClientPointer device to provide the data, unless the
+client currently has a grab on another device. See section 4.4 for more
+details.
 
-    If win is None, the ClientPointer for this client is set to the given
-    device. Otherwise, if win is a valid window, the ClientPointer for the
-    client owning this window is set to the given device. Otherwise, if win is
-    not a valid window but a client with the client mask equal to win exists,
-    this client's ClientPointer is set to the given device.
+If win is None, the ClientPointer for this client is set to the given
+device. Otherwise, if win is a valid window, the ClientPointer for the
+client owning this window is set to the given device. Otherwise, if win is
+not a valid window but a client with the client mask equal to win exists,
+this client's ClientPointer is set to the given device.
 
-    If deviceid does not specify a master pointer or master keyboard, a
-    BadDevice error is returned.
+If deviceid does not specify a master pointer or master keyboard, a
+BadDevice error is returned.
 
-    If window does not specify a valid window or client ID and is not None, a
-    BadWindow error is returned.
+If window does not specify a valid window or client ID and is not None, a
+BadWindow error is returned.
 
     ┌───
         XIGetClientPointer
@@ -724,7 +753,7 @@ are required to be 0.
             deviceid:        DEVICEID
     └───
 
-    Query the ClientPointer for the client owning win.
+Query the ClientPointer for the client owning win.
 
     win
         The window or client ID.
@@ -733,9 +762,9 @@ are required to be 0.
     deviceid
         The master pointer that acts as a ClientPointer if set is True.
 
-    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.
+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.
 
     ┌───
         XISetFocus
@@ -744,9 +773,9 @@ are required to be 0.
             time:            Time
     └───
 
-    Set the focus for the given device to the given window. Future key events
-    from this device are sent to this window.
-    This request generates FocusIn and FocusOut events.
+Set the focus for the given device to the given window. Future key events
+from this device are sent to this window.
+This request generates FocusIn and FocusOut events.
 
     focus
         A viewable window or None.
@@ -755,17 +784,17 @@ are required to be 0.
     time
         Specifies the time to change the focus or CurrentTime.
 
-    If focus is None, key events from this device are discarded until a new
-    focus window is set. If focus is a viewable window, key events from this
-    device are sent to this window. If the window becomes unviewable, the
-    window's first viewable ancestor automatically becomes the focus window
-    and FocusIn and FocusOut events are sent as if a client had changed the
-    focus window.
-    This is equivalent to RevertToParent in the core XSetInputFocus window.
+If focus is None, key events from this device are discarded until a new
+focus window is set. If focus is a viewable window, key events from this
+device are sent to this window. If the window becomes unviewable, the
+window's first viewable ancestor automatically becomes the focus window
+and FocusIn and FocusOut events are sent as if a client had changed the
+focus window.
+This is equivalent to RevertToParent in the core XSetInputFocus window.
 
-    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.
+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.
 
     ┌───
         XIGetFocus
@@ -774,7 +803,7 @@ are required to be 0.
             focus:           Window
     └───
 
-    Return the current focus window for the given device.
+Return the current focus window for the given device.
 
     ┌───
         XIGrabDevice
@@ -791,10 +820,10 @@ are required to be 0.
             status:          Success, AlreadyGrabbed, Frozen, InvalidTime, NotViewable
     └───
 
-    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.
+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.
 
     deviceid
         The device to grab.
@@ -819,40 +848,41 @@ are required to be 0.
     status
         Success or the reason why the grab could not be established.
 
-    The masks parameter specifies which events the client wishes to receive
-    while the device is grabbed.
+The masks parameter specifies which events the client wishes to receive
+while the device is grabbed.
 
-    If owner-events is False, input events generated from this device are
-    reported with respect to grab-window, and are only reported if selected by
-    being included in the event-list.  If owner-events is True, then if a
-    generated event would normally be reported to this client, it is reported
-    normally, otherwise the event is reported with respect to the grab-window,
-    and is only reported if selected by being included in the event-list. For
-    either value of owner-events, unreported events are discarded.
+If owner-events is False, input events generated from this device are
+reported with respect to grab-window, and are only reported if selected by
+being included in the event-list.  If owner-events is True, then if a
+generated event would normally be reported to this client, it is reported
+normally, otherwise the event is reported with respect to the grab-window,
+and is only reported if selected by being included in the event-list. For
+either value of owner-events, unreported events are discarded.
 
-    If grab-mode is Asynchronous, device event processing continues normally.
-    If the device is currently frozen by this client, then processing of
-    device events is resumed. If grab-mode is Synchronous, the state of the
-    grabbed device (as seen by means of the protocol) appears to freeze,
-    and no further device events are 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.
+If grab-mode is Asynchronous, device event processing continues normally.
+If the device is currently frozen by this client, then processing of
+device events is resumed. If grab-mode is Synchronous, the state of the
+grabbed device (as seen by means of the protocol) appears to freeze,
+and no further device events are 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.
 
-    If the device is a slave device, the paired-device-mode is ignored.
-    Otherwise, if this device is a master device and paired-device-mode is
-    Asynchronous, event processing is unaffected by activation of the grab. If
-    this device is a master device and paired-device-mode is Synchronous, the
-    state of the master device paired with this device (as seen by means of the
-    protocol) appears to freeze, and no further events are generated by the
-    server until the grabbing client issues a releasing XIAllowEvents request
-    or until the device grab is released. Actual events are not lost while the
-    devices are frozen; they are simply queued for later processing.
+If the device is a slave device, the paired-device-mode is ignored.
+Otherwise, if this device is a master device and paired-device-mode is
+Asynchronous, event processing is unaffected by activation of the grab. If
+this device is a master device and paired-device-mode is Synchronous, the
+state of the master device paired with this device (as seen by means of the
+protocol) appears to freeze, and no further events are generated by the
+server until the grabbing client issues a releasing XIAllowEvents request
+or until the device grab is released. Actual events are not lost while the
+devices are frozen; they are simply queued for later processing.
 
-    If the cursor is not None and the device is a master pointer device, the
-    cursor will be displayed until the device is ungrabbed.
+If the cursor is not None and the device is a master pointer device, the
+cursor will be displayed until the device is ungrabbed.
+
+This request fails and returns:
 
-    This request fails and returns:
     AlreadyGrabbed: If the device is actively grabbed by some other client.
     NotViewable: If grab-window is not viewable.
     InvalidTime: If the specified time is earlier than the last-grab-time for
@@ -862,7 +892,7 @@ are required to be 0.
                  current X server time.
     Frozen: If the device is frozen by an active grab of another client.
 
-    To release a grab of a device, use XIUngrabDevice.
+To release a grab of a device, use XIUngrabDevice.
 
     ┌───
         XIUngrabDevice
@@ -870,21 +900,21 @@ are required to be 0.
             time:            TIMESTAMP or CurrentTime
     └───
 
-    This request releases the device if this client has it actively grabbed
-    (from either XIGrabDevice or  XIPassiveGrabDevice) and
-    releases any queued events. If any devices were frozen by the grab,
-    XIUngrabDevice thaws them.
+This request releases the device if this client has it actively grabbed
+(from either XIGrabDevice or  XIPassiveGrabDevice) and
+releases any queued events. If any devices were frozen by the grab,
+XIUngrabDevice thaws them.
 
     deviceid
         The device to grab.
     time
         A valid server time or CurrentTime.
 
-    The request has no effect if the specified time is earlier than the
-    last-device-grab time or is later than the current server time.
-    This request generates FocusIn and FocusOut events.
-    An XIUngrabDevice is performed automatically if the event window for an
-    active device grab becomes not viewable.
+The request has no effect if the specified time is earlier than the
+last-device-grab time or is later than the current server time.
+This request generates FocusIn and FocusOut events.
+An XIUngrabDevice is performed automatically if the event window for an
+active device grab becomes not viewable.
 
     ┌───
         XIAllowEvents:
@@ -895,8 +925,8 @@ are required to be 0.
                                ReplayDevice, AsyncPair, SyncPair }
     └───
 
-    The XIAllowEvents request releases some queued events if the client
-    has caused a device to freeze.
+The XIAllowEvents request releases some queued events if the client
+has caused a device to freeze.
 
     deviceid
         The device to grab.
@@ -906,12 +936,13 @@ are required to be 0.
         Specifies whether a device is to be thawed and events are to be
         replayed.
 
-    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 following describes the processing that occurs depending on what constant
+you pass to the event-mode argument:
 
-    The following describes the processing that occurs depending on what constant
-    you pass to the event-mode argument:
     AsyncDevice:
         If the specified device is frozen by the client, event processing for that
         device continues as usual. If the device is frozen multiple times  by the
@@ -1004,8 +1035,8 @@ are required to be 0.
         GRABMODIFIERINFO {   status:    Access
                              modifiers: CARD32 }
 
-        Establish an explicit passive grab for a button or keycode
-        on the specified input device.
+Establish an explicit passive grab for a button or keycode
+on the specified input device.
 
         cursor
             The cursor to display for the duration of the grab. If grab_type
@@ -1046,27 +1077,28 @@ are required to be 0.
         modifiers_return
             XKB modifier state that could not be grabbed.
 
-        If owner-events is False, input events generated from this device are
-        reported with respect to grab-window, and are only reported if
-        selected by being included in the event-list.  If owner-events is
-        True, then if a generated event would normally be reported to this
-        client, it is reported normally, otherwise the event is reported
-        with respect to the grab-window, and is only reported if selected
-        by being included in the event-list. For either value of
-        owner-events, unreported events are discarded.
+If owner-events is False, input events generated from this device are
+reported with respect to grab-window, and are only reported if
+selected by being included in the event-list.  If owner-events is
+True, then if a generated event would normally be reported to this
+client, it is reported normally, otherwise the event is reported
+with respect to the grab-window, and is only reported if selected
+by being included in the event-list. For either value of
+owner-events, unreported events are discarded.
 
-        If deviceid specifies a master pointer, the modifiers of the paired
-        master keyboard are used. If deviceid specifies a slave pointer
-        the modifiers of the master keyboard paired with the attached master
-        pointers are used. If deviceid specifies a slave keyboard, the
-        modifiers of the attached master keyboard are used. Note that
-        activating a grab on a slave device detaches the device from its
-        master. In this case, the modifiers after activation of the grab are
-        from the slave device only and may be different to the modifier state
-        when the grab was triggered.
+If deviceid specifies a master pointer, the modifiers of the paired
+master keyboard are used. If deviceid specifies a slave pointer
+the modifiers of the master keyboard paired with the attached master
+pointers are used. If deviceid specifies a slave keyboard, the
+modifiers of the attached master keyboard are used. Note that
+activating a grab on a slave device detaches the device from its
+master. In this case, the modifiers after activation of the grab are
+from the slave device only and may be different to the modifier state
+when the grab was triggered.
+
+In the future, if grab_type is GrabtypeButton or GrabtypeKeyboard, the
+device is actively grabbed if:
 
-        In the future, if grab_type is GrabtypeButton or GrabtypeKeyboard, the
-        device is actively grabbed if:
         - the device is not grabbed, and
         - the specified modifier keys are down, and
         - the grab_type is GrabtypeButton and the button specified in detail
@@ -1076,8 +1108,9 @@ are required to be 0.
         - a passive grab on the same button/keycode + modifier
           combination does not exist on an ancestor of grab_window.
 
-        Otherwise, if grab_type is GrabtypeEnter or GrabtypeFocusIn, the
-        device is actively grabbed if:
+Otherwise, if grab_type is GrabtypeEnter or GrabtypeFocusIn, the
+device is actively grabbed if:
+
         - the device is not actively grabbed, and
         - the specified modifier keys are down, and
         - the grab_type is GrabtypeEnter and the device's pointer has moved
@@ -1087,51 +1120,51 @@ are required to be 0.
         - a passive grab of the same grab_type + modifier combination does not
           does not exist on an ancestor of grab_window.
 
-        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
-        combinations in the same request.
+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
+combinations in the same request.
 
-        A GrabtypeButton or GrabtypeKeyboard grab is released when all buttons
-        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.
-        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.
+A GrabtypeButton or GrabtypeKeyboard grab is released when all buttons
+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.
+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.
 
-        This request overrides all previous passive grabs by the same
-        client on the same button/key/enter/focus in + modifier combinations
-        on the same window.
+This request overrides all previous passive grabs by the same
+client on the same button/key/enter/focus in + modifier combinations
+on the same window.
 
-        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.
+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.
 
-        If a button grab or enter grab activates, EnterNotify and LeaveNotify
-        events with mode Grab are generated as if the pointer were to suddenly
-        warp from its current position some position in the grab_window.
-        However, the pointer does not warp, and the pointer position is used
-        as both the initial and final positions for the events.
+If a button grab or enter grab activates, EnterNotify and LeaveNotify
+events with mode Grab are generated as if the pointer were to suddenly
+warp from its current position some position in the grab_window.
+However, the pointer does not warp, and the pointer position is used
+as both the initial and final positions for the events.
 
-        If a keycode grab or focus grab activates, FocusIn and FocusOut events
-        with mode Grab are generated as if the focus were to change from the
-        current window to the grab_window.
+If a keycode grab or focus grab activates, FocusIn and FocusOut events
+with mode Grab are generated as if the focus were to change from the
+current window to the grab_window.
 
-        If an enter or focus in grab activates, additional EnterNotify events
-        with mode XIPassiveGrabNotify are generated as if the pointer or focus
-        were to suddenly warp from its current position to some position in
-        the grab window.  These events are sent to the grabbing client only
-        and only if the grab event mask has selected for it. If such a passive
-        grab deactivates, addional LeaveNotify events with mode
-        XIPassiveUngrabNotify are generated and sent to the grabbing client
-        before the grab deactivates.
+If an enter or focus in grab activates, additional EnterNotify events
+with mode XIPassiveGrabNotify are generated as if the pointer or focus
+were to suddenly warp from its current position to some position in
+the grab window.  These events are sent to the grabbing client only
+and only if the grab event mask has selected for it. If such a passive
+grab deactivates, addional LeaveNotify events with mode
+XIPassiveUngrabNotify are generated and sent to the grabbing client
+before the grab deactivates.
 
     ┌───
         XIPassiveUngrabDevice
@@ -1143,7 +1176,7 @@ are required to be 0.
             modifiers:       MODIFIERINFO
     └───
 
-        Release an explicit passive grab on the specified input device.
+Release an explicit passive grab on the specified input device.
 
         deviceid
             The device to establish the passive grab on.
@@ -1159,9 +1192,9 @@ are required to be 0.
         num_modifiers
             Number of elements in modifiers.
 
-        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.
+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.
 
     ┌───
         XIListProperties
@@ -1171,7 +1204,7 @@ are required to be 0.
             properties:      LISTofATOM
     └───
 
-        List the properties associated with the given device.
+List the properties associated with the given device.
 
         deviceid
             The device to list the properties for.
@@ -1191,7 +1224,7 @@ are required to be 0.
             data:            LISTofINT8, or LISTofINT16, or LISTofINT32
     └───
 
-        Change the given property on the given device.
+Change the given property on the given device.
 
         deviceid
             The device to change the property on.
@@ -1206,26 +1239,26 @@ are required to be 0.
         data
             Property data (nitems * format/8 bytes)
 
-        The type is uninterpreted by the server. The format specifies whether
-        the data should be viewed as a list of 8-bit, 16-bit, or 32-bit
-        quantities so that the server can correctly byte-swap as necessary.
+The type is uninterpreted by the server. The format specifies whether
+the data should be viewed as a list of 8-bit, 16-bit, or 32-bit
+quantities so that the server can correctly byte-swap as necessary.
 
-        If the mode is Replace, the previous propert y value is discarded.  If
-        the mode is Prepend or Append, then the type and format must match the
-        existing property value (or a Match error results). If the property is
-        undefined, it is treated as defined with the correct type and format
-        with zero-length data. For Prepend, the data is tacked on to the
-        beginning of the existing data, and for Append, it is tacked on to the
-        end of the existing data.
+If the mode is Replace, the previous propert y value is discarded.  If
+the mode is Prepend or Append, then the type and format must match the
+existing property value (or a Match error results). If the property is
+undefined, it is treated as defined with the correct type and format
+with zero-length data. For Prepend, the data is tacked on to the
+beginning of the existing data, and for Append, it is tacked on to the
+end of the existing data.
 
-        The lifetime of a property is not tied to the storing client. Properties
-        remain until explicitly deleted, until the device is removed, or
-        until server reset.
+The lifetime of a property is not tied to the storing client. Properties
+remain until explicitly deleted, until the device is removed, or
+until server reset.
 
-        A property cannot be deleted by setting nitems to zero. To delete a
-        property, use XIDeleteProperty.
+A property cannot be deleted by setting nitems to zero. To delete a
+property, use XIDeleteProperty.
 
-        This request generates an XIPropertyEvent.
+This request generates an XIPropertyEvent.
 
     ┌───
         XIDeleteProperty
@@ -1233,15 +1266,15 @@ are required to be 0.
             property:        ATOM
     └───
 
-        Deletes the given property on the given device.
+Deletes the given property on the given device.
 
         deviceid
             The device to delete the property on.
         property
             The property to delete.
 
-        If the property is deleted, an XIPropertyEvent is generated on the device.
-        If the property does not exist, this request does nothing.
+If the property is deleted, an XIPropertyEvent is generated on the device.
+If the property does not exist, this request does nothing.
 
     ┌───
         XIGetProperty
@@ -1259,7 +1292,7 @@ are required to be 0.
             data:            LISTofINT8, or LISTofINT16, or LISTofINT32
     └───
         
-        Get the data for the given property on the given device.
+Get the data for the given property on the given device.
 
         deviceid
             The device to retrieve the property data from.
@@ -1282,34 +1315,37 @@ are required to be 0.
         data
             Property data (nitems * format/8 bytes)
 
-        If the specified property does not exist for the specified device, then
-        the return type is None, the format and bytes-after are zero, and the value is
-        empty. The delete argument is ignored in this case. If the specified property
-        exists but its type does not match the specified type, then the return
-        type is the actual type of the property, the format is the actual format of the
-        property (never zero), the bytes-after is the length of the property in bytes
-        (even if the format is 16 or 32), and the value is empty. The delete
-        argument is ignored in this case. If the specified property exists and
-        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.  
+If the specified property does not exist for the specified device, then
+the return type is None, the format and bytes-after are zero, and the value is
+empty. The delete argument is ignored in this case. If the specified property
+exists but its type does not match the specified type, then the return
+type is the actual type of the property, the format is the actual format of the
+property (never zero), the bytes-after is the length of the property in bytes
+(even if the format is 16 or 32), and the value is empty. The delete
+argument is ignored in this case. If the specified property exists and
+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:
+----------
 
 An event specifies its length in 4-byte units after the initial 32 bytes.
 Future versions of the protocol may provide additional information
@@ -1342,13 +1378,13 @@ Version 2.0:
 All events have a set of common fields specified as EVENTHEADER.
 
 
-EVENTHEADER { type:                       BYTE
-              extension:                  BYTE
-              sequenceNumber:             CARD16
-              length:                     CARD32
-              evtype:                     CARD16
-              deviceid:                   DEVICEID
-              time:                       Time }
+    EVENTHEADER { type:                       BYTE
+                  extension:                  BYTE
+                  sequenceNumber:             CARD16
+                  length:                     CARD32
+                  evtype:                     CARD16
+                  deviceid:                   DEVICEID
+                  time:                       Time }
 
     type
         Always GenericEvent.
@@ -1391,26 +1427,27 @@ EVENTHEADER { type:                       BYTE
     info:
         The current hierarchy information.
 
-    An XIHierarchyEvent is sent whenever the device hierarchy been
-    changed. The flags specify all types of hierarchy modifiations that have
-    occured.
-    For all devices, info details the hierarchy information after the
-    modification of the hierarchy has occured. For each device specified with
-    deviceid:
-    - if type is MasterPointer or MasterKeyboard, attachment decribes the
-      pairing of this device.
-    - if type is SlavePointer or SlaveKeyboard, attachment describes the
-      master device this device is attached to.
-    - if type is FloatingSlave device, attachment is undefined.
+An XIHierarchyEvent is sent whenever the device hierarchy been
+changed. The flags specify all types of hierarchy modifiations that have
+occured.
+For all devices, info details the hierarchy information after the
+modification of the hierarchy has occured. For each device specified with
+deviceid:
+
+- if type is MasterPointer or MasterKeyboard, attachment decribes the
+  pairing of this device.
+- if type is SlavePointer or SlaveKeyboard, attachment describes the
+  master device this device is attached to.
+- if type is FloatingSlave device, attachment is undefined.
 
     enabled
          True if the device is enabled and can send events. A disabled master
          device will not forward events from an attached, enabled slave
          device.
 
-    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.
+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.
 
     ┌───
         DeviceChangedEvent:
@@ -1423,9 +1460,9 @@ EVENTHEADER { type:                       BYTE
 
     CHANGEREASON { SlaveSwitch, DeviceChange }
 
-    A DeviceChangeEvent is sent whenever a device changes it's capabilities.
-    This can happen either by a new slave device sending events through a
-    master device, or by a physical device changing capabilities at runtime.
+A DeviceChangeEvent is sent whenever a device changes it's capabilities.
+This can happen either by a new slave device sending events through a
+master device, or by a physical device changing capabilities at runtime.
 
     reason
         The reason for generating this event.
@@ -1443,7 +1480,7 @@ EVENTHEADER { type:                       BYTE
         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 XQueryDevice request.
 
     ┌───
         DeviceEvent:
@@ -1483,10 +1520,10 @@ EVENTHEADER { type:                       BYTE
     DEVICEEVENTFLAGS (key events only): { KeyRepeat }
     DEVICEEVENTFLAGS (pointer events only): none
 
-    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.
+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.
 
     detail
         The button number or key code, or 0.
@@ -1527,7 +1564,8 @@ EVENTHEADER { type:                       BYTE
         the physical state of the key has not changed.  This is only
         valid for KeyPress events.
 
-    Modifier state in mods is detailed as follows:
+Modifier state in mods is detailed as follows:
+
     base_mods
         XKB base modifier state.
     latched_mods
@@ -1554,14 +1592,14 @@ EVENTHEADER { type:                       BYTE
             axisvalues_raw:            LISTofFP3232
     └───
 
-    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
-    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.
+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
+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.
 
     eventtype
         The type of event that occured on the device.
@@ -1603,22 +1641,22 @@ EVENTHEADER { type:                       BYTE
     NOTIFYDETAIL { Ancestor, Virtual, Inferior, Nonlinear, NonlinearVirtual,
                    Pointer, PointerRoot, None }
 
-    Enter or Leave events are sent whenever a device's pointer enters or
-    leaves a window.
-    FocusIn or FocusOut events are sent whenever a device's focus is set to or
-    away from a window.
-    The enter/leave and focus in/out model is described in the core protocol
-    specification, Section 11. (EnterNotify, LeaveNotify events).
+Enter or Leave events are sent whenever a device's pointer enters or
+leaves a window.
+FocusIn or FocusOut events are sent whenever a device's focus is set to or
+away from a window.
+The enter/leave and focus in/out model is described in the core protocol
+specification, Section 11. (EnterNotify, LeaveNotify events).
 
-    For enter and leave events, the modifier and group state is the state of
-    the paired master device if the device is a master device, or the state of
-    the attached master keyboard if the device is an attached slave device, or
-    zero if the device is a floating slave device.
+For enter and leave events, the modifier and group state is the state of
+the paired master device if the device is a master device, or the state of
+the attached master keyboard if the device is an attached slave device, or
+zero if the device is a floating slave device.
 
-    For focus in and out events, the button state is the state of the paired
-    master device if the device is a master device, or the state of the
-    attached master keyboard if the device is an attached slave device, or
-    zero if the device is a floating slave device.
+For focus in and out events, the button state is the state of the paired
+master device if the device is a master device, or the state of the
+attached master keyboard if the device is an attached slave device, or
+zero if the device is a floating slave device.
 
     root
     event
@@ -1665,8 +1703,8 @@ EVENTHEADER { type:                       BYTE
             what:               { PropertyCreated, PropertyDeleted, PropertyModified }
     └───
 
-    XIPropertyEvents are sent whenever a device property is created, deleted or
-    modified by a client.
+XIPropertyEvents are sent whenever a device property is created, deleted or
+modified by a client.
 
     property
         The property that has been created, deleted, or modified
@@ -1674,4 +1712,4 @@ EVENTHEADER { type:                       BYTE
         Specifies what has been changed.
      
 
-                              ❧❧❧❧❧❧❧❧❧❧❧
+//                            ❧❧❧❧❧❧❧❧❧❧❧

From 0ac450f47c55fb2bac394f6377f1aabde1ab8429 Mon Sep 17 00:00:00 2001
From: Gaetan Nadon 
Date: Tue, 15 Mar 2011 15:43:48 -0400
Subject: [PATCH 226/388] specs: convert XI2proto.txt to html using asciidoc

Signed-off-by: Gaetan Nadon 
---
 Makefile.am                        |  6 +++---
 configure.ac                       |  9 ++++++---
 specs/.gitignore                   |  1 +
 specs/Makefile.am                  | 16 ++++++++++++++++
 XI2proto.txt => specs/XI2proto.txt |  0
 XIproto.txt => specs/XIproto.txt   |  0
 6 files changed, 26 insertions(+), 6 deletions(-)
 create mode 100644 specs/.gitignore
 create mode 100644 specs/Makefile.am
 rename XI2proto.txt => specs/XI2proto.txt (100%)
 rename XIproto.txt => specs/XIproto.txt (100%)

diff --git a/Makefile.am b/Makefile.am
index 77d1ea7..3312f2f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,3 +1,6 @@
+
+SUBDIRS = specs
+
 inputdir = $(includedir)/X11/extensions
 input_HEADERS = \
 	XI.h \
@@ -8,9 +11,6 @@ input_HEADERS = \
 pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA = inputproto.pc
 
-dist_doc_DATA = XI2proto.txt XIproto.txt
-
-
 MAINTAINERCLEANFILES = ChangeLog INSTALL
 
 .PHONY: ChangeLog INSTALL
diff --git a/configure.ac b/configure.ac
index 39e4df9..bd5f046 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3,11 +3,14 @@ AC_INIT([InputProto], [2.0.1], [https://bugs.freedesktop.org/enter_bug.cgi?produ
 AM_INIT_AUTOMAKE([foreign dist-bzip2])
 AM_MAINTAINER_MODE
 
-# Require xorg-macros: XORG_DEFAULT_OPTIONS
+# Require xorg-macros: XORG_WITH_ASCIIDOC
 m4_ifndef([XORG_MACROS_VERSION],
-          [m4_fatal([must install xorg-macros 1.3 or later before running autoconf/autogen])])
-XORG_MACROS_VERSION(1.3)
+          [m4_fatal([must install xorg-macros 1.10 or later before running autoconf/autogen])])
+XORG_MACROS_VERSION(1.10)
 XORG_DEFAULT_OPTIONS
+XORG_ENABLE_SPECS
+XORG_WITH_ASCIIDOC(8.4.5)
 
 AC_OUTPUT([Makefile
+           specs/Makefile
            inputproto.pc])
diff --git a/specs/.gitignore b/specs/.gitignore
new file mode 100644
index 0000000..2d19fc7
--- /dev/null
+++ b/specs/.gitignore
@@ -0,0 +1 @@
+*.html
diff --git a/specs/Makefile.am b/specs/Makefile.am
new file mode 100644
index 0000000..ad51453
--- /dev/null
+++ b/specs/Makefile.am
@@ -0,0 +1,16 @@
+
+if ENABLE_SPECS
+if HAVE_ASCIIDOC
+
+doc_DATA = XI2proto.html
+dist_doc_DATA = XI2proto.txt
+
+%.html: %.txt
+	$(AM_V_GEN)$(ASCIIDOC) -o $@ $<
+
+CLEANFILES = $(doc_DATA)
+
+EXTRA_DIST = XIproto.txt
+
+endif
+endif
diff --git a/XI2proto.txt b/specs/XI2proto.txt
similarity index 100%
rename from XI2proto.txt
rename to specs/XI2proto.txt
diff --git a/XIproto.txt b/specs/XIproto.txt
similarity index 100%
rename from XIproto.txt
rename to specs/XIproto.txt

From 5f43b8b19e6abd00a6295692f3346295bb01b973 Mon Sep 17 00:00:00 2001
From: Gaetan Nadon 
Date: Tue, 15 Mar 2011 21:29:43 -0400
Subject: [PATCH 227/388] XI2proto.txt: fix whitespace issues

Signed-off-by: Gaetan Nadon 
---
 specs/XI2proto.txt | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 5d1b275..1e3adbe 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -144,7 +144,7 @@ If an event is generated by an SD
 - if the SD is attached to a master keyboard, it sends events to this
   keyboard's focus window (if applicable) and/or changes the modifier state of
   this keyboard.
-- if the SD is not attached to an MD ("floating"), it does not change 
+- if the SD is not attached to an MD ("floating"), it does not change
   any master device. The SD has its own (invisible) sprite and its own focus.
   Both the sprite and the focus must be managed explicitly by the client
   program.
@@ -1291,7 +1291,7 @@ If the property does not exist, this request does nothing.
             format:          { 8, 16, 32 }
             data:            LISTofINT8, or LISTofINT16, or LISTofINT32
     └───
-        
+
 Get the data for the given property on the given device.
 
         deviceid
@@ -1341,8 +1341,8 @@ 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.  
-     
+the device.
+
 
 8. Events:
 ----------
@@ -1710,6 +1710,6 @@ modified by a client.
         The property that has been created, deleted, or modified
     what
         Specifies what has been changed.
-     
+
 
 //                            ❧❧❧❧❧❧❧❧❧❧❧

From 47901cd142e832eb930166cbfa769e4fbca969c5 Mon Sep 17 00:00:00 2001
From: Gaetan Nadon 
Date: Tue, 15 Mar 2011 21:37:39 -0400
Subject: [PATCH 228/388] XIproto.txt: fix whitespace issues

Signed-off-by: Gaetan Nadon 
---
 specs/XIproto.txt | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/specs/XIproto.txt b/specs/XIproto.txt
index 83cf9dd..4b6b8f1 100644
--- a/specs/XIproto.txt
+++ b/specs/XIproto.txt
@@ -4,7 +4,7 @@
                  X Version 11, Release 6.8
                Mark Patrick, Ardent Computer
                George Sachs, Hewlett-Packard
-               
+
                       Version 1.5
                     Peter Hutterer
 
@@ -83,10 +83,10 @@
    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 
+   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 
+   from using this protocol specification. Instead, the use of XI 2.x
    is recommended.
 
 1.1 Design Approach
@@ -115,8 +115,8 @@
    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 
+   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
@@ -280,7 +280,7 @@
    header file XI.h. Each version is a superset of the previous
    versions.
 
-   The name must be the name of the Input Extension as defined 
+   The name must be the name of the Input Extension as defined
    in the header file XI.h.
 
 2.2 Listing Available Devices

From fe19202c220ce010a85fe5abc0b5a6a0c314ea9a Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Thu, 17 Mar 2011 16:29:08 +1000
Subject: [PATCH 229/388] specs: add a linebreak for asciidoc parsing

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 97051da..92907c1 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -931,6 +931,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

From a4583dcd3e1c18e5c0cc616c143aafbf7ec1d88b Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 18 Mar 2011 12:02:21 +1000
Subject: [PATCH 230/388] specs: move from "init move destroy" to "begin update
 end"

And rewrite that paragraph a bit.

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 92907c1..d76962d 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -226,15 +226,18 @@ Touch event processing differs from normal event processing in a few ways,
 most notably in that touch events are processed partially out-of-band from
 pointer and keyboard events.
 
-Touch input follows a three-stage cycle: init - move - move - ... - destroy,
-i.e. “init” the sequence by touching the device, “move” the current touch
-location any number of times, and finally “destroy” the sequence by ceasing
-to touch the device. The init and destroy stage of this sequence are always
-present, while the move stage is optional. Within this document, the term
-"touch sequence" is used to describe the above chain of events. In the this
-protocol, the init stage is represented by a touch begin event, then move stage
-is represented by a touch update event, and the destroy stage is represented by
-a touch end event.
+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 chain of events.
+In the protocol, the three stages are represented with the event
+types TouchBegin, TouchUpdate, and TouchEnd, respectively.
+A touch sequence always generates TouchBeing and TouchEnd events. It may
+generate TouchUpdate events.
 
 Touch sequences may send events to multiple clients in parallel. At any given
 time, only one client is in control of the touch sequence and is referred to as

From 1d720b30c996a693014f2c70004c9717945b574f Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 18 Mar 2011 12:12:47 +1000
Subject: [PATCH 231/388] specs: move touch sequence handling (owner-only) up a
 bit.

This is to restructure to get the simple cases clarified up first before
explaining more complex changes.

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index d76962d..508c867 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -239,6 +239,24 @@ types TouchBegin, TouchUpdate, and TouchEnd, respectively.
 A touch sequence always generates TouchBeing and TouchEnd events. It may
 generate TouchUpdate events.
 
+A client must select for TouchBegin, TouchUpdate, and TouchEnd events. A
+TouchBegin event is sent to the client with the position information and
+properties of the touch when it began on the touch device.
+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
+affected by grabs. The event timestamp of touch events always represents the
+time the event occurred.
+
+A TouchUpdate event is sent to the client whenever the position or any other
+property of the touch changes. Note that the server may compress multiple
+TouchUpdate events into one. If compression occurs, the TouchUpdate event
+represents the last state of the touch.
+
+A TouchEnd event is sent to the client when the touch ceases.
+
+4.4.2 Ownership of touch events
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
 Touch sequences may send events to multiple clients in parallel. At any given
 time, only one client is in control of the touch sequence and is referred to as
 the "owner" of the sequence.

From 0e4a782339403f270de6e072262680b3a4baec01 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 18 Mar 2011 13:52:09 +1000
Subject: [PATCH 232/388] specs: move warning about out-of-band processing up a
 bit.

The out-of-band processing is really only important for pointer emulation.

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 508c867..bab822a 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -219,12 +219,14 @@ event processing stops.
 4.4 Touch device support
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-4.4.1 Touch event sequences
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
 Touch event processing differs from normal event processing in a few ways,
 most notably in that touch events are processed partially out-of-band from
-pointer and keyboard events.
+pointer and keyboard events (see section 4.4.5) and in that
+touch events may be sent to multiple clients simultaneously (see sections
+4.4.2 and 4.4.3).
+
+4.4.1 Touch event sequences
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Touch input follows a three-stage cycle: 
 

From f24c9ae749c84d953ee3b35be1ea937dce7b86d3 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 18 Mar 2011 13:58:29 +1000
Subject: [PATCH 233/388] spec: Move ClientPointer up again.

Prep work to have a separate first-class headline for touch processing

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index bab822a..9d32699 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -216,8 +216,29 @@ 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 Touch device support
-~~~~~~~~~~~~~~~~~~~~~~~~
+4.4. The ClientPointer principle
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Many core protocol and some extension requests are ambiguous when multiple
+master devices are available (e.g. QueryPointer does not specfy 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.
+QueryPointer), the ClientPointer or the keyboard paired with the ClientPointer
+is chosen to provide the data for this request.
+
+This ClientPointer may be explicitly assigned to a client with the
+SetClientPointer call. If no ClientPointer is set when a client issues an
+ambiguous request, the server choses one device as the ClientPointer. The
+method of chosing a ClientPointer from the available master pointers is
+implementation-specific.
+
+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.
+
+5 Touch device support
+----------------------
 
 Touch event processing differs from normal event processing in a few ways,
 most notably in that touch events are processed partially out-of-band from

From 35710924957791e389e10fcc67b75967769f001c Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 18 Mar 2011 14:16:55 +1000
Subject: [PATCH 234/388] specs: clean/rewrite touch grab and ownership bits

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 174 ++++++++++++++++++++++-----------------------
 1 file changed, 86 insertions(+), 88 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 9d32699..0a863ae 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -244,12 +244,12 @@ Touch event processing differs from normal event processing in a few ways,
 most notably in that touch events are processed partially out-of-band from
 pointer and keyboard events (see section 4.4.5) and in that
 touch events may be sent to multiple clients simultaneously (see sections
-4.4.2 and 4.4.3).
+5.1.1 and 5.1.2).
 
-4.4.1 Touch event sequences
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+5.1 Touch event sequences
+~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Touch input follows a three-stage cycle: 
+Touch input follows a three-stage cycle:
 
         begin - update - update - ... - end
 
@@ -277,77 +277,96 @@ represents the last state of the touch.
 
 A TouchEnd event is sent to the client when the touch ceases.
 
-4.4.2 Ownership of touch events
+Only one client may select for touch events from a device on a window.
+
+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. See XIPassiveGrabDevice for more information on passive
+grab activation. When a touch grab activates, the client whose grab
+activates becomes the “owner” of this touch sequence. For all other clients,
+the logical state of a device (as seen by means of the protocol) may now lag
+the physical state.
+
+The owner must either “accept” or "reject" the touch sequence. If a touch
+sequence is rejected, a TouchEnd event is sent to the owner. The touch
+sequence is then re-processed on the next window and a new passive grab may
+activate or the sequence may be delivered to the client with an event
+selection. The client who now receives the touch sequence becomes the new
+owner of the touch sequence. If a touch sequence is accepted, the touch
+sequence is exclusively delivered to the current owner.
+
+If the touch sequence ends while the client is the owner of the touch
+sequence, the client receives a TouchEnd event. The client must accept or
+reject the sequence nonetheless.
+
+5.1.1 Ownership of touch sequences
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Clients may opt for touch events to be delivered before they become the
+owner of the touch sequence. In this case, the logical state 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. 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
+TouchEndEvent.
+
+5.1.2 Observing touch sequences
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+A client that is the current owner of the sequence and rejects the sequence
+with TouchObserve will not be sent a TouchEnd event immediately. Instead,
+this client continues to receive touch events as they occur on the device.
+However, a client hat has rejected a touch sequence may not become the owner
+of this sequence again.
 
-Touch sequences may send events to multiple clients in parallel. At any given
-time, only one client is in control of the touch sequence and is referred to as
-the "owner" of the sequence.
+A client who has a passive grab with grab type TouchObserve will receive
+touch events as they occur on the device. Such a client will not become the
+owner of this sequence. The client continues to receive events until the
+touch sequence ceases on the device, even if the current owner of the
+sequence accepts the sequence.
 
-Clients may want to receive events only after they become the owner of a touch
-sequence. This prevents unnecessary process wakeups and provides for simpler
-handling of a stream of touch events. Such clients must select for touch begin,
-update, and end events. When the client becomes the owner of a touch sequence,
-a touch begin event will be sent. This event will represent the position and
-properties of the touch when it began on the touch device. The server may buffer
-copies of multiple touch update events while the touch sequence was owned by
-another client. After sending the touch begin event, any buffered touch update
-events will be sent. If the touch position or properties have changed since the
-touch began, at least one touch update or touch end event will be sent to denote
-the new position and properties. There is no guarantee that any more than one
-touch update or touch end event will be buffered. The event timestamp of the
-buffered events represent the time the event occurred.
 
-Other clients may want access to the stream of touch events from a touch
-sequence before they become the owner of the sequence. Clients must use caution
-when handling these events; any action taken must be undone if the touch
-sequence ends without the client becoming the owner. Such clients must select
-for touch begin, update, end, and ownership events. A touch begin event is sent
-to all such clients when a touch sequence has initiated. When touch position or
-properties are changed, the client will be sent touch update events. Once the
-client, including the initial owner, becomes the owner of the touch sequence, a
-touch ownership event will be sent. When the touch ends, the owner will receive
-a touch end event if it is a touch grabbing client and has accepted the touch
-sequence as outlined below or if it is receiving touch events through a
-selection. Otherwise, the owner will receive a touch update event with the
-pending end flag set. All other clients will receive a touch update event with
-the pending end flag set.
-
-Touch grabs are similar to standard input event grabs in that they take
-precedence over selections and are searched from the root window to the child
-window. When a touch grab is activated, the client will receive a touch
-ownership event. The owner must either “accept” or "reject" the touch sequence,
-though it may do so at any time, including after the touch sequence has ended.
-If the owner accepts the touch sequence, touch end events will be sent to all
-other clients listening to events from the touch sequence. If the owner rejects
-the touch sequence, a touch end event will be sent to the owner and further
-grabs will be checked for the touch sequence. If any touch client becomes the
-owner of the touch sequence, it will be sent a touch ownership event. Touch
-grabbing clients must register for touch ownership events through the grab and
-be able to handle events while they are not the owner of the touch sequence.
-
-A touch sequence is only considered to be meaningful in its entirety: clients
-may not capture part of a touch sequence, interpret only that part, and then
-pass ownership of the touch sequence on to another client. A special exception
-to this rule is made for clients who passively grab a touch with grab type
-TouchObserve, or for when a client rejects a touch with mode TouchObserve. Such
-clients are passed over for touch ownership, but will continue to receive touch
-update events for the touch sequence.
-
-A TouchEnd event will always be sent to a client when it will receive no more
-events from a particular touch, regardless of why (grab or selection removed,
-owner accepted, the client having rejected the touch, etc).
+FIXME:
+- can we have more than one TouchObserve on a device/window combination
+  then?
+- it's impossible to observe and still become the owner
 
+FIXME:
 Only one client may select, and only one client may grab, touch events for a
 physical device on a window. As an example, selecting for AllDevices will
-prevent any other client from selecting for touch events for any device on the
+protocollkrevent any other client from selecting for touch events for any device on the
 same window. When a slave device is attached to a master device, any selections
 on any windows for touch events for the slave device ID will be canceled.
 Clients selecting for individual slave devices are suggested to select for
 HierarchyChanged events to be notified when this occurs.
 
-4.4.2 Touch device modes
-^^^^^^^^^^^^^^^^^^^^^^^^
+5.2 Touch device modes
+~~~~~~~~~~~~~~~~~~~~~~
 
 Touch devices come in many different forms with varying capabilities. The
 following device modes are defined for this protocol:
@@ -382,8 +401,8 @@ A device is identified as only one of the device modes above at any time. For
 the purposes of this protocol document, indirect touch devices refers to
 DependentTouch, IndependentPointer, and SemiMultitouch devices.
 
-4.4.3 Touch event delivery
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+5.3 Touch event delivery
+~~~~~~~~~~~~~~~~~~~~~~~~
 
 Window sets for event propagation for direct device touches contain the windows
 from the root to the child in which the touch originated.
@@ -402,7 +421,7 @@ affected by new grabs or selections.
 No touches from an indirect device may begin while the device is floating, as
 it does not have an associated pointer position to focus events.
 
-4.4.4 Pointer event handling for indirect touch devices
+5.3.1 Pointer event handling for indirect touch devices
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Indirect touch devices are expected to generate pointer events. In contrast with
@@ -425,7 +444,7 @@ touches that have changed position or properties since the touch began. No event
 will be delivered for touches that began and ended while touch events were
 withheld.
 
-4.4.5 Pointer emulation for direct touch devices
+5.3.2 Pointer emulation for direct touch devices
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 In order to facilitate backwards compatibility with legacy clients, direct touch
@@ -474,27 +493,6 @@ selections, only the touch events will be delivered.
 Both the emulated pointer events and their associated touch events will have the
 PointerEmulated flag set.
 
-4.5. The ClientPointer principle
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Many core protocol and some extension requests are ambiguous when multiple
-master devices are available (e.g. QueryPointer does not specfy 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.
-QueryPointer), the ClientPointer or the keyboard paired with the ClientPointer
-is chosen to provide the data for this request.
-
-This ClientPointer may be explicitly assigned to a client with the
-SetClientPointer call. If no ClientPointer is set when a client issues an
-ambiguous request, the server choses one device as the ClientPointer. The
-method of chosing a ClientPointer from the available master pointers is
-implementation-specific.
-
-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.
-
 //                            ❧❧❧❧❧❧❧❧❧❧❧
 
 5. Data types

From c883261f2bad6196e5ff1b3c1397300775e55da7 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 18 Mar 2011 14:48:15 +1000
Subject: [PATCH 235/388] specs: Add a fixme for using raw events instead of
 GrabModeObserve

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 0a863ae..c3e8c07 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -355,6 +355,8 @@ FIXME:
 - can we have more than one TouchObserve on a device/window combination
   then?
 - it's impossible to observe and still become the owner
+- having GrabtypeTouchObserve seems rather broken. if all we want to do is
+  observe, then why not use RawEvents or something similar?
 
 FIXME:
 Only one client may select, and only one client may grab, touch events for a

From 9c2817fd761bbe6c6da4e2a5638d80fa53975c4b Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 18 Mar 2011 15:10:34 +1000
Subject: [PATCH 236/388] specs: Rewrite Touch events delivery section

And add a fixme

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 29 ++++++++++++++++-------------
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index c3e8c07..731baf2 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -406,22 +406,25 @@ DependentTouch, IndependentPointer, and SemiMultitouch devices.
 5.3 Touch event delivery
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-Window sets for event propagation for direct device touches contain the windows
-from the root to the child in which the touch originated.
+For direct touch devices, the window set for event propagation is the set of
+windows from the root window to the child in which the touch sequence
+begins.
 
-Indirect device window sets depend on whether other touches are active. For
-the first touch on an indirect device, the window set contains the windows from
-the root to the current window underneath the position of the device's pointer.
-For subsequent touches on the device, the window set is identical to the window
-set of the first touch. Once all touches have been released, the window set is
-reset and re-calculated on the first subsequent touch.
+For indirect 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. An indirect device may only have one window set at a time. Any
+future touch sequence will use the same window set. The window set is
+cleared when all touch sequences on the device end.
 
-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, nor is it
-affected by new grabs or selections.
+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.
+
+FIXME:
+    No touches from an indirect device may begin while the device is
+    floating, as it does not have an associated pointer position to focus
+    events. [incorrect, remove it? why would it matter]
 
-No touches from an indirect device may begin while the device is floating, as
-it does not have an associated pointer position to focus events.
 
 5.3.1 Pointer event handling for indirect touch devices
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

From 15e76dd365fce4e936a9f468496be3789495103b Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 18 Mar 2011 15:29:25 +1000
Subject: [PATCH 237/388] specs: rewrite pointer emulation for indirect devices

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 731baf2..39d75e3 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -429,14 +429,11 @@ FIXME:
 5.3.1 Pointer event handling for indirect touch devices
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Indirect touch devices are expected to generate pointer events. In contrast with
-direct touch devices, as stated below, the server will not generate pointer
-events on behalf of indirect touch devices. Further, pointer events from
-indirect touch devices are delivered independently of touch events.
-
-DependentTouch and SemiMultitouch devices may generate pointer events by mapping
-one touch sequence to the pointer. In these cases, events for both the pointer
-and its associated touch sequence will have the PointerEmulated flag set.
+Indirect touch devices are expected to generate pointer events and no
+pointer emulation is performed. However, the pointer event may be generate
+in the driver by mapping one touch sequence to the pointer. In these cases,
+events for both the pointer and its associated touch sequence will have the
+PointerEmulated flag set.
 
 When the cursor of an attached master pointer of an indirect device leaves the
 window of a touch grab or selection, or when a client activates a pointer grab

From ed840d79d3cac60b2fb17448afcc28828236e91b Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 18 Mar 2011 16:17:09 +1000
Subject: [PATCH 238/388] specs: rewrite pointer emulation section

plus a fixme

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 80 +++++++++++++++++++++++++++-------------------
 1 file changed, 47 insertions(+), 33 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 39d75e3..248e45e 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -449,51 +449,65 @@ withheld.
 5.3.2 Pointer emulation for direct touch devices
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-In order to facilitate backwards compatibility with legacy clients, direct touch
-devices will emulate pointer events. Pointer emulation events will only be
-delivered through the attached master device; no pointer events will be emulated
-for floating touch devices. Further, only one touch from any attached slave
-direct touch device may be emulated per master device at any time.
+Touch sequences from direct touch devices may emulation 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.
+
+FIXME:
+    Pointer emulation events will only be delivered through the attached
+    master device; no pointer events will be emulated for floating touch
+    devices.
+  why?
 
 Pointer events are emulated as follows:
 
-* Touch begin events generate a pointer motion event to the location of the
+- TouchBegin events generate a pointer motion event to the location of the
   touch, followed by a button press event for button 1.
-* Touch update events generate a pointer motion event to update the location
+- TouchUpdate events generate a pointer motion event to update the location
   of the touch.
-* Touch end events generate a pointer motion event to the location of the touch
+- TouchEnd events generate a pointer motion event to the location of the touch
   if the touch has moved, followed by a button release event for button 1.
 
-A touch sequence may only be owned by one client at a time. When pointer events
-are emulated from a touch sequence and delivered through a pointer grab, the
-grabbing client implicitly becomes the owner of the touch sequence.
+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 this touch sequence.
 
-A pointer grabbing client is considered to have accepted ownership of the touch
-sequence when the following occurs:
+The touch sequences is considered to have been accepted if
 
-* The emulated button press event is delivered through an asynchronous grab.
-* The emulated button press event is delivered through a synchronous grab and
-  further events are allowed through to the grabbing client.
-* The emulated button press event is delivered through a synchronous grab and
-  then the grab is deactivated without replaying the button press event.
+- the grab mode is asynchronous, or
+- the grab mode is synchronous and the device is thawed as a result of
+  AllowEvents with any mode but ReplayPointer or ReplayDevice, or
+- the grab mode is synchronous and the device remains frozen as a result of
+  AllowEvents with mode SyncPointer or SyncDevice
 
-Touch and pointer grabs are mutually exclusive. For a given window, any touch
-grab is activated first. If there is no touch grab or the touch grab is
-rejected, any pointer grab is activated. If there is a pointer grab and the
-grabbing client accepts ownership of the touch sequence as outlined above, the
-touch sequence is ended for all other clients listening for touch events.
-Otherwise, if there is no pointer grab or the grabbing client replays the
-pointer events without accepting the touch sequence, the next window in the
-window set is checked for grabs.
+Otherwise, if the button press is replayed by the client, the touch sequence
+is considered to be rejected.
 
-If the touch sequence is not accepted by any client through a grab, the touch
-and emulated pointer events may be delivered to a client selecting for them.
-Event propagation for the touch sequence ends at the first client selecting for
-touch or pointer events. If a window has both touch and pointer event
-selections, only the touch events will be delivered.
+Touch event delivery precedes pointer event delivery. A touch event event
+emulating pointer events is delivered
 
-Both the emulated pointer events and their associated touch events will have the
-PointerEmulated flag set.
+- 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 window in the window set as in the same order as
+  until a grab has been found,
+
+If no touch or pointer grab on any window was activated 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.
+
+This sequence is repeated from the current window if the current owner of
+the sequence rejects the sequence.
+
+FIXME
+    Both the emulated pointer events and their associated touch events will
+    have the PointerEmulated flag set.
+  huh? we never get both events anyway
 
 //                            ❧❧❧❧❧❧❧❧❧❧❧
 

From ef7518cc6260e05a00c496c9e0f3a13c8a785b85 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 23 Mar 2011 13:32:42 +1000
Subject: [PATCH 239/388] specs: move erroneous Errors: line to where it
 belongs

Signed-off-by: Peter Hutterer 
Reviewed-by: Julien Cristau 
---
 specs/XIproto.txt | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/specs/XIproto.txt b/specs/XIproto.txt
index 4b6b8f1..35ab1c9 100644
--- a/specs/XIproto.txt
+++ b/specs/XIproto.txt
@@ -857,10 +857,11 @@
 
                    GetDeviceDontPropagateList
                            window: WINDOW
-                           Errors: Window
                    =>
                            dont-propagate-list: LISTofEVENTCLASS
 
+   Errors: Window
+
    This function returns a list specifying the events that are not
    propagated to the ancestors of the specified window.
 
@@ -989,10 +990,11 @@
 
                    ChangeKeyboardDevice
                            device: DEVICE
-                           Errors: Device, Match
                    =>
                            status: Success, AlreadyGrabbed, Frozen
 
+   Errors: Device, Match
+
    To change the X pointer device, use the ChangePointerDevice
    request. The specified device must support input class
    Valuators (as reported in the ListInputDevices request) or the

From ab930a51047f48c7befd4316a9b116f37075697f Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 23 Mar 2011 13:27:02 +1000
Subject: [PATCH 240/388] 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 
Reviewed-by: Gaetan Nadon 
---
 specs/Makefile.am |    6 +-
 specs/XIproto.txt | 3364 +++++++++++++++++++++++----------------------
 2 files changed, 1704 insertions(+), 1666 deletions(-)

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 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 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.
+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.
+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.
+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.
 
-   In servers supporting only XI 1.x, this input extension does
-   not change the behavior or functionality of the core input
-   devices, core events, or core protocol requests, with the
-   exception of the core grab requests. These requests may affect
-   the synchronization of events from extension devices. See the
-   explanation in the section titled "Event Synchronization and
-   Core Grabs".
+In servers supporting only XI 1.x, this input extension does
+not change the behavior or functionality of the core input
+devices, core events, or core protocol requests, with the
+exception of the core grab requests. These requests may affect
+the synchronization of events from extension devices. See the
+explanation in the section titled "Event Synchronization and
+Core Grabs".
 
-   Selection of the physical devices to be initially used by the
-   server as the core devices is left implementation-dependent.
-   Requests are defined that allow client programs to change which
-   physical devices are used as the core devices.
+Selection of the physical devices to be initially used by the
+server as the core devices is left implementation-dependent.
+Requests are defined that allow client programs to change which
+physical devices are used as the core devices.
 
 1.3 Extension Input Devices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   The input extension v1.x controls access to input devices other
-   than the X keyboard and X pointer. It allows client programs to
-   select input from these devices independently from each other
-   and independently from the core devices.
+The input extension v1.x controls access to input devices other
+than the X keyboard and X pointer. It allows client programs to
+select input from these devices independently from each other
+and independently from the core devices.
 
-   A client that wishes to access a specific device must first
-   determine whether that device is connected to the X server.
-   This is done through the ListInputDevices request, which will
-   return a list of all devices that can be opened by the X
-   server. A client can then open one or more of these devices
-   using the OpenDevice request, specify what events they are
-   interested in receiving, and receive and process input events
-   from extension devices in the same way as events from the X
-   keyboard and X pointer. Input events from these devices are of
-   extension types ( DeviceKeyPress, DeviceKeyRelease,
-   DeviceButtonPress, DeviceButtonRelease, DeviceMotionNotify,
-   etc.) and contain a device identifier so that events of the
-   same type coming from different input devices can be
-   distinguished.
+A client that wishes to access a specific device must first
+determine whether that device is connected to the X server.
+This is done through the ListInputDevices request, which will
+return a list of all devices that can be opened by the X
+server. A client can then open one or more of these devices
+using the OpenDevice request, specify what events they are
+interested in receiving, and receive and process input events
+from extension devices in the same way as events from the X
+keyboard and X pointer. Input events from these devices are of
+extension types ( DeviceKeyPress, DeviceKeyRelease,
+DeviceButtonPress, DeviceButtonRelease, DeviceMotionNotify,
+etc.) and contain a device identifier so that events of the
+same type coming from different input devices can be
+distinguished.
 
-   Any kind of input device may be used as an extension input
-   device. Extension input devices may have 0 or more keys, 0 or
-   more buttons, and may report 0 or more axes of motion. Motion
-   may be reported as relative movements from a previous position
-   or as an absolute position. All valuators reporting motion
-   information for a given extension input device must report the
-   same kind of motion information (absolute or relative).
+Any kind of input device may be used as an extension input
+device. Extension input devices may have 0 or more keys, 0 or
+more buttons, and may report 0 or more axes of motion. Motion
+may be reported as relative movements from a previous position
+or as an absolute position. All valuators reporting motion
+information for a given extension input device must report the
+same kind of motion information (absolute or relative).
 
-   This extension is designed to accommodate new types of input
-   devices that may be added in the future. The protocol requests
-   that refer to specific characteristics of input devices
-   organize that information by input classes. Server implementors
-   may add new classes of input devices without changing the
-   protocol requests. Input classes are unique numbers registered
-   with the X Consortium. Each extension input device may support
-   multiple input classes.
+This extension is designed to accommodate new types of input
+devices that may be added in the future. The protocol requests
+that refer to specific characteristics of input devices
+organize that information by input classes. Server implementors
+may add new classes of input devices without changing the
+protocol requests. Input classes are unique numbers registered
+with the X Consortium. Each extension input device may support
+multiple input classes.
 
-   In XI 1.x, all extension input devices are treated like the
-   core X keyboard in determining their location and focus. The
-   server does not track the location of these devices on an
-   individual basis, and therefore does not echo a cursor to
-   indicate their current location. Instead, their location is
-   determined by the location of the core X pointer. Like the core
-   X keyboard, some may be explicitly focused. If they are not
-   explicitly focused, their focus is determined by the location
-   of the core X pointer.
+In XI 1.x, all extension input devices are treated like the
+core X keyboard in determining their location and focus. The
+server does not track the location of these devices on an
+individual basis, and therefore does not echo a cursor to
+indicate their current location. Instead, their location is
+determined by the location of the core X pointer. Like the core
+X keyboard, some may be explicitly focused. If they are not
+explicitly focused, their focus is determined by the location
+of the core X pointer.
 
-   Most input events reported by the server to a client are of
-   fixed size (32 bytes). In order to represent the change in
-   state of an input device the extension may need to generate a
-   sequence of input events. A client side library (such as Xlib)
-   will typically take these raw input events and format them into
-   a form more convenient to the client.
+Most input events reported by the server to a client are of
+fixed size (32 bytes). In order to represent the change in
+state of an input device the extension may need to generate a
+sequence of input events. A client side library (such as Xlib)
+will typically take these raw input events and format them into
+a form more convenient to the client.
 
 1.4 Event Classes
+-----------------
 
-   In the core protocol a client registers interest in receiving
-   certain input events directed to a window by modifying that
-   window's event-mask. Most of the bits in the event mask are
-   already used to specify interest in core X events. The input
-   extension specifies a different mechanism by which a client can
-   express interest in events generated by this extension.
+In the core protocol a client registers interest in receiving
+certain input events directed to a window by modifying that
+window's event-mask. Most of the bits in the event mask are
+already used to specify interest in core X events. The input
+extension specifies a different mechanism by which a client can
+express interest in events generated by this extension.
 
-   When a client opens a extension input device via the OpenDevice
-   request, an XDevice structure is returned. Macros are provided
-   that extract 32-bit numbers called event classes from that
-   structure, that a client can use to register interest in
-   extension events via the SelectExtensionEvent request. The
-   event class combines the desired event type and device id, and
-   may be thought of as the equivalent of core event masks.
+When a client opens a extension input device via the OpenDevice
+request, an XDevice structure is returned. Macros are provided
+that extract 32-bit numbers called event classes from that
+structure, that a client can use to register interest in
+extension events via the SelectExtensionEvent request. The
+event class combines the desired event type and device id, and
+may be thought of as the equivalent of core event masks.
 
 1.5 Input Classes
+~~~~~~~~~~~~~~~~~
 
-   Some of the input extension requests divide input devices into
-   classes based on their functionality. This is intended to allow
-   new classes of input devices to be defined at a later time
-   without changing the semantics of these requests. The following
-   input device classes are currently defined:
+Some of the input extension requests divide input devices into
+classes based on their functionality. This is intended to allow
+new classes of input devices to be defined at a later time
+without changing the semantics of these requests. The following
+input device classes are currently defined:
 
    KEY
           The device reports key events.
@@ -244,102 +252,105 @@
           DeviceStateNotify macros may be invoked passing the
           XDevice structure returned for this device.
 
-   Each extension input device may support multiple input classes.
-   Additional classes may be added in the future. Requests that
-   support multiple input classes, such as the ListInputDevices
-   function that lists all available input devices, organize the
-   data they return by input class. Client programs that use these
-   requests should not access data unless it matches a class
-   defined at the time those clients were compiled. In this way,
-   new classes can be added without forcing existing clients that
-   use these requests to be recompiled.
+Each extension input device may support multiple input classes.
+Additional classes may be added in the future. Requests that
+support multiple input classes, such as the ListInputDevices
+function that lists all available input devices, organize the
+data they return by input class. Client programs that use these
+requests should not access data unless it matches a class
+defined at the time those clients were compiled. In this way,
+new classes can be added without forcing existing clients that
+use these requests to be recompiled.
 
 2. Requests
+-----------
 
-   Extension input devices are accessed by client programs through
-   the use of new protocol requests. This section summarizes the
-   new requests defined by this extension. The syntax and type
-   definitions used below follow the notation used for the X11
-   core protocol.
+Extension input devices are accessed by client programs through
+the use of new protocol requests. This section summarizes the
+new requests defined by this extension. The syntax and type
+definitions used below follow the notation used for the X11
+core protocol.
 
 2.1 Getting the Extension Version
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   The GetExtensionVersion request returns version information
-   about the input extension.
+The GetExtensionVersion request returns version information
+about the input extension.
 
-                       GetExtensionVersion
-                               name: STRING
-                       =>
-                               present: BOOL
-                               protocol-major-version: CARD16
-                               protocol-minor-version: CARD16
+                    GetExtensionVersion
+                            name: STRING
+                    =>
+                            present: BOOL
+                            protocol-major-version: CARD16
+                            protocol-minor-version: CARD16
 
-   The protocol version numbers returned indicate the version of
-   the input extension supported by the target X server. The
-   version numbers can be compared to constants defined in the
-   header file XI.h. Each version is a superset of the previous
-   versions.
+The protocol version numbers returned indicate the version of
+the input extension supported by the target X server. The
+version numbers can be compared to constants defined in the
+header file XI.h. Each version is a superset of the previous
+versions.
 
-   The name must be the name of the Input Extension as defined
-   in the header file XI.h.
+The name must be the name of the Input Extension as defined
+in the header file XI.h.
 
 2.2 Listing Available Devices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   A client that wishes to access a specific device must first
-   determine whether that device is connected to the X server.
-   This is done through the ListInputDevices request, which will
-   return a list of all devices that can be opened by the X
-   server.
+A client that wishes to access a specific device must first
+determine whether that device is connected to the X server.
+This is done through the ListInputDevices request, which will
+return a list of all devices that can be opened by the X
+server.
 
-                   ListInputDevices
-                   =>
-                   input-devices: ListOfDeviceInfo
+                ListInputDevices
+                =>
+                input-devices: ListOfDeviceInfo
 
-   where
+where
 
-                   DEVICEINFO:
-                           [type: ATOM
-                            id: CARD8
-                            num_classes: CARD8
-                            use: {IsXKeyboard, IsXPointer, IsXExtensionPointer,
-                                  IsXExtensionKeyboard, IsExtensionDevice}
-                            info: LISTofINPUTINFO
-                            name: STRING8]
+                DEVICEINFO:
+                        [type: ATOM
+                         id: CARD8
+                         num_classes: CARD8
+                         use: {IsXKeyboard, IsXPointer, IsXExtensionPointer,
+                               IsXExtensionKeyboard, IsExtensionDevice}
+                         info: LISTofINPUTINFO
+                         name: STRING8]
 
-                   INPUTINFO: {KEYINFO, BUTTONINFO, VALUATORINFO}
-                   KEYINFO:
-                           [class: CARD8
-                            length: CARD8
-                            min-keycode: KEYCODE
-                            max-keycode: KEYCODE
-                            num-keys: CARD16]
-                   BUTTONINFO:
-                           [class: CARD8
-                            length: CARD8
-                            num-buttons: CARD16]
-                   VALUATORINFO:
-                           [class: CARD8
-                            length: CARD8
-                            num_axes: CARD8
-                            mode: SETofDEVICEMODE
-                            motion_buffer_size: CARD32
-                            axes: LISTofAXISINFO]
+                INPUTINFO: {KEYINFO, BUTTONINFO, VALUATORINFO}
+                KEYINFO:
+                        [class: CARD8
+                         length: CARD8
+                         min-keycode: KEYCODE
+                         max-keycode: KEYCODE
+                         num-keys: CARD16]
+                BUTTONINFO:
+                        [class: CARD8
+                         length: CARD8
+                         num-buttons: CARD16]
+                VALUATORINFO:
+                        [class: CARD8
+                         length: CARD8
+                         num_axes: CARD8
+                         mode: SETofDEVICEMODE
+                         motion_buffer_size: CARD32
+                         axes: LISTofAXISINFO]
 
-                   AXISINFO:
-                           [resolution: CARD32
-                            min-val: CARD32
-                            max-val: CARD32]
-                   DEVICEMODE: {Absolute, Relative}
+                AXISINFO:
+                        [resolution: CARD32
+                         min-val: CARD32
+                         max-val: CARD32]
+                DEVICEMODE: {Absolute, Relative}
 
    Errors: None
 
-   This request returns a list of all devices that can be opened
-   by the X server, including the core X keyboard and X pointer.
-   Some implementations may open all input devices as part of X
-   initialization, while others may not open an input device until
-   requested to do so by a client program.
+This request returns a list of all devices that can be opened
+by the X server, including the core X keyboard and X pointer.
+Some implementations may open all input devices as part of X
+initialization, while others may not open an input device until
+requested to do so by a client program.
 
-   The information returned for each device is as follows:
+The information returned for each device is as follows:
 
    type
           The type field is of type Atom and indicates the nature
@@ -422,8 +433,8 @@
                 that are contained in this input class. The length
                 includes the class and length fields.
 
-          The remaining information returned for input class
-          KEYCLASS is as follows:
+The remaining information returned for input class
+KEYCLASS is as follows:
 
         min_keycode
                 min_keycode is of type KEYCODE. It specifies the
@@ -439,15 +450,15 @@
                 num_keys is a cardinal value that specifies the
                 number of keys that the device has.
 
-          The remaining information returned for input class
-          BUTTONCLASS is as follows:
+The remaining information returned for input class
+BUTTONCLASS is as follows:
 
         num_buttons
                 num_buttons is a cardinal value that specifies the
                 number of buttons that the device has.
 
-          The remaining information returned for input class
-          VALUATORCLASS is as follows:
+The remaining information returned for input class
+VALUATORCLASS is as follows:
 
         mode
                 mode is a constant that has one of the following
@@ -465,8 +476,8 @@
                 The axes field contains a pointer to an AXISINFO
                 struture.
 
-          The information returned for each axis reported by the
-          device is:
+The information returned for each axis reported by the
+device is:
 
         resolution
                 The resolution is a cardinal value in
@@ -485,34 +496,35 @@
                 max_val field will contain 0.
 
 2.3 Enabling Devices
+~~~~~~~~~~~~~~~~~~~~
 
-   Client programs that wish to access an extension device must
-   request that the server open that device. This is done via the
-   OpenDevice request.
+Client programs that wish to access an extension device must
+request that the server open that device. This is done via the
+OpenDevice request.
 
-                   OpenDevice
-                           id: CARD8
-                   =>
-                   DEVICE:
-                           [device_id: XID
-                            num_classes: INT32
-                            classes: LISTofINPUTCLASSINFO]
-                   INPUTCLASSINFO:
-                            [input_class: CARD8
-                            event_type_base: CARD8]
+                OpenDevice
+                        id: CARD8
+                =>
+                DEVICE:
+                        [device_id: XID
+                         num_classes: INT32
+                         classes: LISTofINPUTCLASSINFO]
+                INPUTCLASSINFO:
+                         [input_class: CARD8
+                         event_type_base: CARD8]
 
    Errors: Device
 
-   This request returns the event classes to be used by the client
-   to indicate which events the client program wishes to receive.
-   Each input class may report several event classes. For example,
-   input class Keys reports DeviceKeyPress and DeviceKeyRelease
-   event classes. Input classes are unique numbers registered with
-   the X Consortium. Input class Other exists to report event
-   classes that are not specific to any one input class, such as
-   DeviceMappingNotify, ChangeDeviceNotify, and DeviceStateNotify.
+This request returns the event classes to be used by the client
+to indicate which events the client program wishes to receive.
+Each input class may report several event classes. For example,
+input class Keys reports DeviceKeyPress and DeviceKeyRelease
+event classes. Input classes are unique numbers registered with
+the X Consortium. Input class Other exists to report event
+classes that are not specific to any one input class, such as
+DeviceMappingNotify, ChangeDeviceNotify, and DeviceStateNotify.
 
-   The information returned for each device is as follows:
+The information returned for each device is as follows:
 
    device_id
           The device_id is a number that uniquely identifies the
@@ -538,594 +550,606 @@
           classes. This is described in the section of this
           document entitled "Selecting Extension Device Events".
 
-   The information in the InputClassInfo reflects the state of
-   this device at the time the request was processed.
+The information in the InputClassInfo reflects the state of
+this device at the time the request was processed.
 
-   Before it exits, the client program should explicitly request
-   that the server close the device. This is done via the
-   CloseDevice request.
+Before it exits, the client program should explicitly request
+that the server close the device. This is done via the
+CloseDevice request.
 
-   A client may open the same extension device more than once.
-   Requests after the first successful one return an additional
-   XDevice structure with the same information as the first, but
-   otherwise have no effect. A single CloseDevice request will
-   terminate that client's access to the device.
+A client may open the same extension device more than once.
+Requests after the first successful one return an additional
+XDevice structure with the same information as the first, but
+otherwise have no effect. A single CloseDevice request will
+terminate that client's access to the device.
 
-   Closing a device releases any active or passive grabs the
-   requesting client has established. If the device is frozen only
-   by an active grab of the requesting client, the queued events
-   are released when the client terminates.
+Closing a device releases any active or passive grabs the
+requesting client has established. If the device is frozen only
+by an active grab of the requesting client, the queued events
+are released when the client terminates.
 
-   If a client program terminates without closing a device, the
-   server will automatically close that device on behalf of the
-   client. This does not affect any other clients that may be
-   accessing that device.
+If a client program terminates without closing a device, the
+server will automatically close that device on behalf of the
+client. This does not affect any other clients that may be
+accessing that device.
 
-                       CloseDevice:
-                               device: DEVICE
+                    CloseDevice:
+                            device: DEVICE
 
    Errors: Device
 
 2.4 Changing The Mode Of A Device
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   Some devices are capable of reporting either relative or
-   absolute motion data. To change the mode of a device from
-   relative to absolute, use the SetDeviceMode request. The valid
-   values are Absolute or Relative.
+Some devices are capable of reporting either relative or
+absolute motion data. To change the mode of a device from
+relative to absolute, use the SetDeviceMode request. The valid
+values are Absolute or Relative.
 
-   This request will fail and return DeviceBusy if another client
-   already has the device open with a different mode. It will fail
-   and return AlreadyGrabbed if another client has the device
-   grabbed. The request will fail with a BadMatch error if the
-   device has no valuators and reports no axes of motion. The
-   request will fail with a BadMode error if the requested mode
-   is not supported by the device.
+This request will fail and return DeviceBusy if another client
+already has the device open with a different mode. It will fail
+and return AlreadyGrabbed if another client has the device
+grabbed. The request will fail with a BadMatch error if the
+device has no valuators and reports no axes of motion. The
+request will fail with a BadMode error if the requested mode
+is not supported by the device.
 
-                       SetDeviceMode
-                               device:DEVICE
-                               mode: {Absolute, Relative}
-                       =>
-                               status: {Success, DeviceBusy, AlreadyGrabbed}
+                    SetDeviceMode
+                            device:DEVICE
+                            mode: {Absolute, Relative}
+                    =>
+                            status: {Success, DeviceBusy, AlreadyGrabbed}
 
    Errors: Device, Match, Mode
 
 2.5 Initializing Valuators on an Input Device
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   Some devices that report absolute positional data can be
-   initialized to a starting value. Devices that are capable of
-   reporting relative motion or absolute positional data may
-   require that their valuators be initialized to a starting value
-   after the mode of the device is changed to Absolute. To
-   initialize the valuators on such a device, use the
-   SetDeviceValuators request.
+Some devices that report absolute positional data can be
+initialized to a starting value. Devices that are capable of
+reporting relative motion or absolute positional data may
+require that their valuators be initialized to a starting value
+after the mode of the device is changed to Absolute. To
+initialize the valuators on such a device, use the
+SetDeviceValuators request.
 
-                   SetDeviceValuators
-                           device: DEVICE
-                           first_valuator: CARD8
-                           num_valuators: CARD8
-                           valuators: LISTOFINT32
-                   =>
-                           status: {Success, AlreadyGrabbed}
+                SetDeviceValuators
+                        device: DEVICE
+                        first_valuator: CARD8
+                        num_valuators: CARD8
+                        valuators: LISTOFINT32
+                =>
+                        status: {Success, AlreadyGrabbed}
 
    Errors: Length, Device, Match, Value
 
-   This request initializes the specified valuators on the
-   specified extension input device. Valuators are numbered
-   beginning with zero. Only the valuators in the range specified
-   by first_valuator and num_valuators are set. If the number of
-   valuators supported by the device is less than the expression
-   first_valuator + num_valuators, a Value error will result.
+This request initializes the specified valuators on the
+specified extension input device. Valuators are numbered
+beginning with zero. Only the valuators in the range specified
+by first_valuator and num_valuators are set. If the number of
+valuators supported by the device is less than the expression
+first_valuator + num_valuators, a Value error will result.
 
-   If the request succeeds, Success is returned. If the specifed
-   device is grabbed by some other client, the request will fail
-   and a status of AlreadyGrabbed will be returned.
+If the request succeeds, Success is returned. If the specifed
+device is grabbed by some other client, the request will fail
+and a status of AlreadyGrabbed will be returned.
 
 2.6 Getting Input Device Controls
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-                   GetDeviceControl
-                           device: DEVICE
-                           control: XID
-                   =>
-                   controlState: {DeviceState}
+                GetDeviceControl
+                        device: DEVICE
+                        control: XID
+                =>
+                controlState: {DeviceState}
 
-   where
+where
 
-                   DeviceState: DeviceResolutionState
+                DeviceState: DeviceResolutionState
 
    Errors: Length, Device, Match, Value
 
-   This request returns the current state of the specified device
-   control. The device control must be supported by the target
-   server and device or an error will result.
+This request returns the current state of the specified device
+control. The device control must be supported by the target
+server and device or an error will result.
 
-   If the request is successful, a pointer to a generic
-   DeviceState structure will be returned. The information
-   returned varies according to the specified control and is
-   mapped by a structure appropriate for that control.
+If the request is successful, a pointer to a generic
+DeviceState structure will be returned. The information
+returned varies according to the specified control and is
+mapped by a structure appropriate for that control.
 
-   GetDeviceControl will fail with a BadValue error if the server
-   does not support the specified control. It will fail with a
-   BadMatch error if the device does not support the specified
-   control.
+GetDeviceControl will fail with a BadValue error if the server
+does not support the specified control. It will fail with a
+BadMatch error if the device does not support the specified
+control.
 
-   Supported device controls and the information returned for them
-   include:
+Supported device controls and the information returned for them
+include:
 
-                   DEVICE_RESOLUTION:
-                       [control: CARD16
-                       length: CARD16
-                       num_valuators: CARD8
-                       resolutions: LISTofCARD32
-                       min_resolutions: LISTofCARD32
-                       max_resolutions: LISTofCARD32]
+                DEVICE_RESOLUTION:
+                    [control: CARD16
+                    length: CARD16
+                    num_valuators: CARD8
+                    resolutions: LISTofCARD32
+                    min_resolutions: LISTofCARD32
+                    max_resolutions: LISTofCARD32]
 
-   This device control returns a list of valuators and the range
-   of valid resolutions allowed for each. Valuators are numbered
-   beginning with 0. Resolutions for all valuators on the device
-   are returned. For each valuator i on the device, resolutions[i]
-   returns the current setting of the resolution,
-   min_resolutions[i] returns the minimum valid setting, and
-   max_resolutions[i] returns the maximum valid setting.
+This device control returns a list of valuators and the range
+of valid resolutions allowed for each. Valuators are numbered
+beginning with 0. Resolutions for all valuators on the device
+are returned. For each valuator i on the device, resolutions[i]
+returns the current setting of the resolution,
+min_resolutions[i] returns the minimum valid setting, and
+max_resolutions[i] returns the maximum valid setting.
 
-   When this control is specified, XGetDeviceControl will fail
-   with a BadMatch error if the specified device has no valuators.
+When this control is specified, XGetDeviceControl will fail
+with a BadMatch error if the specified device has no valuators.
 
-                   ChangeDeviceControl:
-                           device: DEVICE
-                           XID: controlId
-                           control: DeviceControl
+                ChangeDeviceControl:
+                        device: DEVICE
+                        XID: controlId
+                        control: DeviceControl
 
-   where
+where
 
-                   DeviceControl: DeviceResolutionControl
-                   =>
-                           status: {Success, DeviceBusy, AlreadyGrabbed}
+                DeviceControl: DeviceResolutionControl
+                =>
+                        status: {Success, DeviceBusy, AlreadyGrabbed}
 
    Errors: Length, Device, Match, Value
 
-   ChangeDeviceControl changes the specifed device control
-   according to the values specified in the DeviceControl
-   structure. The device control must be supported by the target
-   server and device or an error will result.
+ChangeDeviceControl changes the specifed device control
+according to the values specified in the DeviceControl
+structure. The device control must be supported by the target
+server and device or an error will result.
 
-   The information passed with this request varies according to
-   the specified control and is mapped by a structure appropriate
-   for that control.
+The information passed with this request varies according to
+the specified control and is mapped by a structure appropriate
+for that control.
 
-   ChangeDeviceControl will fail with a BadValue error if the
-   server does not support the specified control. It will fail
-   with a BadMatch error if the server supports the specified
-   control, but the requested device does not. The request will
-   fail and return a status of DeviceBusy if another client
-   already has the device open with a device control state that
-   conflicts with the one specified in the request. It will fail
-   with a status of AlreadyGrabbed if some other client has
-   grabbed the specified device. If the request succeeds, Success
-   is returned. If it fails, the device control is left unchanged.
+ChangeDeviceControl will fail with a BadValue error if the
+server does not support the specified control. It will fail
+with a BadMatch error if the server supports the specified
+control, but the requested device does not. The request will
+fail and return a status of DeviceBusy if another client
+already has the device open with a device control state that
+conflicts with the one specified in the request. It will fail
+with a status of AlreadyGrabbed if some other client has
+grabbed the specified device. If the request succeeds, Success
+is returned. If it fails, the device control is left unchanged.
 
-   Supported device controls and the information specified for
-   them include:
+Supported device controls and the information specified for
+them include:
 
-                   DEVICE_RESOLUTION:
-                           [control: CARD16
-                            length: CARD16
-                            first_valuator: CARD8
-                            num_valuators: CARD8
-                            resolutions: LISTofCARD32]
+                DEVICE_RESOLUTION:
+                        [control: CARD16
+                         length: CARD16
+                         first_valuator: CARD8
+                         num_valuators: CARD8
+                         resolutions: LISTofCARD32]
 
-   This device control changes the resolution of the specified
-   valuators on the specified extension input device. Valuators
-   are numbered beginning with zero. Only the valuators in the
-   range specified by first_valuator and num_valuators are set. A
-   value of -1 in the resolutions list indicates that the
-   resolution for this valuator is not to be changed.
-   num_valuators specifies the number of valuators in the
-   resolutions list.
+This device control changes the resolution of the specified
+valuators on the specified extension input device. Valuators
+are numbered beginning with zero. Only the valuators in the
+range specified by first_valuator and num_valuators are set. A
+value of -1 in the resolutions list indicates that the
+resolution for this valuator is not to be changed.
+num_valuators specifies the number of valuators in the
+resolutions list.
 
-   When this control is specified, XChangeDeviceControl will fail
-   with a BadMatch error if the specified device has no valuators.
-   If a resolution is specified that is not within the range of
-   valid values (as returned by XGetDeviceControl) the request
-   will fail with a BadValue error. If the number of valuators
-   supported by the device is less than the expression
-   first_valuator + num_valuators, a BadValue error will result.
+When this control is specified, XChangeDeviceControl will fail
+with a BadMatch error if the specified device has no valuators.
+If a resolution is specified that is not within the range of
+valid values (as returned by XGetDeviceControl) the request
+will fail with a BadValue error. If the number of valuators
+supported by the device is less than the expression
+first_valuator + num_valuators, a BadValue error will result.
 
-   If the request fails for any reason, none of the valuator
-   resolutions will be changed.
+If the request fails for any reason, none of the valuator
+resolutions will be changed.
 
-   ChangeDeviceControl causes the server to send a DevicePresence
-   event to interested clients.
+ChangeDeviceControl causes the server to send a DevicePresence
+event to interested clients.
 
 2.7 Selecting Extension Device Events
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   Extension input events are selected using the
-   SelectExtensionEvent request.
+Extension input events are selected using the
+SelectExtensionEvent request.
 
-                   SelectExtensionEvent
-                           interest: LISTofEVENTCLASS
-                           window: WINDOW
+                SelectExtensionEvent
+                        interest: LISTofEVENTCLASS
+                        window: WINDOW
 
    Errors: Window, Class, Access
 
-   This request specifies to the server the events within the
-   specified window which are of interest to the client. As with
-   the core XSelectInput function, multiple clients can select
-   input on the same window.
+This request specifies to the server the events within the
+specified window which are of interest to the client. As with
+the core XSelectInput function, multiple clients can select
+input on the same window.
 
-   XSelectExtensionEvent requires a list of event classes. An
-   event class is a 32-bit number that combines an event type and
-   device id, and is used to indicate which event a client wishes
-   to receive and from which device it wishes to receive it.
-   Macros are provided to obtain event classes from the data
-   returned by the XOpenDevice request. The names of these macros
-   correspond to the desired events, i.e. the DeviceKeyPress is
-   used to obtain the event class for DeviceKeyPress events. The
-   syntax of the macro invocation is:
-                    DeviceKeyPress (device, event_type, event_class);
-                        device: DEVICE
-                        event_type: INT
-                        event_class: INT
+XSelectExtensionEvent requires a list of event classes. An
+event class is a 32-bit number that combines an event type and
+device id, and is used to indicate which event a client wishes
+to receive and from which device it wishes to receive it.
+Macros are provided to obtain event classes from the data
+returned by the XOpenDevice request. The names of these macros
+correspond to the desired events, i.e. the DeviceKeyPress is
+used to obtain the event class for DeviceKeyPress events. The
+syntax of the macro invocation is:
 
-   The value returned in event_type is the value that will be
-   contained in the event type field of the XDeviceKeyPressEvent
-   when it is received by the client. The value returned in
-   event_class is the value that should be passed in making an
-   XSelectExtensionEvent request to receive DeviceKeyPress events.
+                 DeviceKeyPress (device, event_type, event_class);
+                     device: DEVICE
+                     event_type: INT
+                     event_class: INT
 
-   For DeviceButtonPress events, the client may specify whether or
-   not an implicit passive grab should be done when the button is
-   pressed. If the client wants to guarantee that it will receive
-   a DeviceButtonRelease event for each DeviceButtonPress event it
-   receives, it should specify the DeviceButtonPressGrab event
-   class as well as the DeviceButtonPress event class. This
-   restricts the client in that only one client at a time may
-   request DeviceButtonPress events from the same device and
-   window if any client specifies this class.
+The value returned in event_type is the value that will be
+contained in the event type field of the XDeviceKeyPressEvent
+when it is received by the client. The value returned in
+event_class is the value that should be passed in making an
+XSelectExtensionEvent request to receive DeviceKeyPress events.
 
-   If any client has specified the DeviceButtonPressGrab class,
-   any requests by any other client that specify the same device
-   and window and specify DeviceButtonPress or
-   DeviceButtonPressGrab will cause an Access error to be
-   generated.
+For DeviceButtonPress events, the client may specify whether or
+not an implicit passive grab should be done when the button is
+pressed. If the client wants to guarantee that it will receive
+a DeviceButtonRelease event for each DeviceButtonPress event it
+receives, it should specify the DeviceButtonPressGrab event
+class as well as the DeviceButtonPress event class. This
+restricts the client in that only one client at a time may
+request DeviceButtonPress events from the same device and
+window if any client specifies this class.
 
-   If only the DeviceButtonPress class is specified, no implicit
-   passive grab will be done when a button is pressed on the
-   device. Multiple clients may use this class to specify the same
-   device and window combination.
+If any client has specified the DeviceButtonPressGrab class,
+any requests by any other client that specify the same device
+and window and specify DeviceButtonPress or
+DeviceButtonPressGrab will cause an Access error to be
+generated.
 
-   A client may also specify the DeviceOwnerGrabButton class. If
-   it has specified both the DeviceButtonPressGrab and the
-   DeviceOwnerGrabButton classes, implicit passive grabs will
-   activate with owner_events set to True. If only the
-   DeviceButtonPressGrab class is specified, implicit passive
-   grabs will activate with owner_events set to False.
+If only the DeviceButtonPress class is specified, no implicit
+passive grab will be done when a button is pressed on the
+device. Multiple clients may use this class to specify the same
+device and window combination.
 
-   The client may select DeviceMotion events only when a button is
-   down. It does this by specifying the event classes
-   Button1Motion through Button5Motion, or ButtonMotion. An input
-   device will only support as many button motion classes as it
-   has buttons.
+A client may also specify the DeviceOwnerGrabButton class. If
+it has specified both the DeviceButtonPressGrab and the
+DeviceOwnerGrabButton classes, implicit passive grabs will
+activate with owner_events set to True. If only the
+DeviceButtonPressGrab class is specified, implicit passive
+grabs will activate with owner_events set to False.
+
+The client may select DeviceMotion events only when a button is
+down. It does this by specifying the event classes
+Button1Motion through Button5Motion, or ButtonMotion. An input
+device will only support as many button motion classes as it
+has buttons.
 
 2.8 Determining Selected Events
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   To determine which extension events are currently selected from
-   a given window, use GetSelectedExtensionEvents.
+To determine which extension events are currently selected from
+a given window, use GetSelectedExtensionEvents.
 
-                   GetSelectedExtensionEvents
-                           window: WINDOW
-                   =>
-                           this-client: LISTofEVENTCLASS
-                           all-clients: LISTofEVENTCLASS
+                GetSelectedExtensionEvents
+                        window: WINDOW
+                =>
+                        this-client: LISTofEVENTCLASS
+                        all-clients: LISTofEVENTCLASS
 
    Errors: Window
 
-   This request returns two lists specifying the events selected
-   on the specified window. One list gives the extension events
-   selected by this client from the specified window. The other
-   list gives the extension events selected by all clients from
-   the specified window. This information is equivalent to that
-   returned by your-event-mask and all-event-masks in a
-   GetWindowAttributes request.
+This request returns two lists specifying the events selected
+on the specified window. One list gives the extension events
+selected by this client from the specified window. The other
+list gives the extension events selected by all clients from
+the specified window. This information is equivalent to that
+returned by your-event-mask and all-event-masks in a
+GetWindowAttributes request.
 
 2.9 Controlling Event Propagation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   Extension events propagate up the window hierarchy in the same
-   manner as core events. If a window is not interested in an
-   extension event, it usually propagates to the closest ancestor
-   that is interested, unless the dont_propagate list prohibits
-   it. Grabs of extension devices may alter the set of windows
-   that receive a particular extension event.
+Extension events propagate up the window hierarchy in the same
+manner as core events. If a window is not interested in an
+extension event, it usually propagates to the closest ancestor
+that is interested, unless the dont_propagate list prohibits
+it. Grabs of extension devices may alter the set of windows
+that receive a particular extension event.
 
-   Client programs may control extension event propagation through
-   the use of the following two requests.
+Client programs may control extension event propagation through
+the use of the following two requests.
 
-   XChangeDeviceDontPropagateList adds an event to or deletes an
-   event from the do_not_propagate list of extension events for
-   the specified window. This list is maintained for the life of
-   the window, and is not altered if the client terminates.
+XChangeDeviceDontPropagateList adds an event to or deletes an
+event from the do_not_propagate list of extension events for
+the specified window. This list is maintained for the life of
+the window, and is not altered if the client terminates.
 
-                   ChangeDeviceDontPropagateList
-                           window: WINDOW
-                           eventclass: LISTofEVENTCLASS
-                           mode: {AddToList, DeleteFromList}
+                ChangeDeviceDontPropagateList
+                        window: WINDOW
+                        eventclass: LISTofEVENTCLASS
+                        mode: {AddToList, DeleteFromList}
 
    Errors: Window, Class, Mode
 
-   This function modifies the list specifying the events that are
-   not propagated to the ancestors of the specified window. You
-   may use the modes AddToList or DeleteFromList.
+This function modifies the list specifying the events that are
+not propagated to the ancestors of the specified window. You
+may use the modes AddToList or DeleteFromList.
 
-                   GetDeviceDontPropagateList
-                           window: WINDOW
-                   =>
-                           dont-propagate-list: LISTofEVENTCLASS
+                GetDeviceDontPropagateList
+                        window: WINDOW
+                =>
+                        dont-propagate-list: LISTofEVENTCLASS
 
    Errors: Window
 
-   This function returns a list specifying the events that are not
-   propagated to the ancestors of the specified window.
+This function returns a list specifying the events that are not
+propagated to the ancestors of the specified window.
 
 2.10 Sending Extension Events
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   One client program may send an event to another via the
-   XSendExtensionEvent function.
+One client program may send an event to another via the
+XSendExtensionEvent function.
 
-   The event in the XEvent structure must be one of the events
-   defined by the input extension, so that the X server can
-   correctly byte swap the contents as necessary. The contents of
-   the event are otherwise unaltered and unchecked by the X server
-   except to force send_event to True in the forwarded event and
-   to set the sequence number in the event correctly.
+The event in the XEvent structure must be one of the events
+defined by the input extension, so that the X server can
+correctly byte swap the contents as necessary. The contents of
+the event are otherwise unaltered and unchecked by the X server
+except to force send_event to True in the forwarded event and
+to set the sequence number in the event correctly.
 
-   XSendExtensionEvent returns zero if the conversion-to-wire
-   protocol failed, otherwise it returns nonzero.
+XSendExtensionEvent returns zero if the conversion-to-wire
+protocol failed, otherwise it returns nonzero.
 
-                   SendExtensionEvent
-                           device: DEVICE
-                           destination: WINDOW
-                           propagate: BOOL
-                           eventclass: LISTofEVENTCLASS
-                           event: XEVENT
+                SendExtensionEvent
+                        device: DEVICE
+                        destination: WINDOW
+                        propagate: BOOL
+                        eventclass: LISTofEVENTCLASS
+                        event: XEVENT
 
    Errors: Device, Value, Class, Window
 
 2.11 Getting Motion History
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-                   GetDeviceMotionEvents
-                           device: DEVICE
-                           start, stop: TIMESTAMP or CurrentTime
-                   =>
-                           nevents_return: CARD32
-                           mode_return: {Absolute, Relative}
-                           axis_count_return: CARD8
-                           events: LISTofDEVICETIMECOORD
+                GetDeviceMotionEvents
+                        device: DEVICE
+                        start, stop: TIMESTAMP or CurrentTime
+                =>
+                        nevents_return: CARD32
+                        mode_return: {Absolute, Relative}
+                        axis_count_return: CARD8
+                        events: LISTofDEVICETIMECOORD
 
-   where
+where
 
-                   DEVICETIMECOORD:
-                           [data: LISTofINT32
-                            time: TIMESTAMP]
+                DEVICETIMECOORD:
+                        [data: LISTofINT32
+                         time: TIMESTAMP]
 
    Errors: Device, Match
 
-   This request returns all positions in the device's motion
-   history buffer that fall between the specified start and stop
-   times inclusive. If the start time is in the future, or is
-   later than the stop time, no positions are returned.
+This request returns all positions in the device's motion
+history buffer that fall between the specified start and stop
+times inclusive. If the start time is in the future, or is
+later than the stop time, no positions are returned.
 
-   The data field of the DEVICETIMECOORD structure is a sequence
-   of data items. Each item is of type INT32, and there is one
-   data item per axis of motion reported by the device. The number
-   of axes reported by the device is returned in the axis_count
-   variable.
+The data field of the DEVICETIMECOORD structure is a sequence
+of data items. Each item is of type INT32, and there is one
+data item per axis of motion reported by the device. The number
+of axes reported by the device is returned in the axis_count
+variable.
 
-   The value of the data items depends on the mode of the device,
-   which is returned in the mode variable. If the mode is
-   Absolute, the data items are the raw values generated by the
-   device. These may be scaled by the client program using the
-   maximum values that the device can generate for each axis of
-   motion that it reports. The maximum and minimum values for each
-   axis are reported by the ListInputDevices request.
+The value of the data items depends on the mode of the device,
+which is returned in the mode variable. If the mode is
+Absolute, the data items are the raw values generated by the
+device. These may be scaled by the client program using the
+maximum values that the device can generate for each axis of
+motion that it reports. The maximum and minimum values for each
+axis are reported by the ListInputDevices request.
 
-   If the mode is Relative, the data items are the relative values
-   generated by the device. The client program must choose an
-   initial position for the device and maintain a current position
-   by accumulating these relative values.
+If the mode is Relative, the data items are the relative values
+generated by the device. The client program must choose an
+initial position for the device and maintain a current position
+by accumulating these relative values.
 
 2.12 Changing The Core Devices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   These requests are provided to change which physical device is
-   used as the X pointer or X keyboard. These requests are
-   deprecated in servers supporting XI 1.4 and above, and will
-   always return a a BadDevice error.
+These requests are provided to change which physical device is
+used as the X pointer or X keyboard. These requests are
+deprecated in servers supporting XI 1.4 and above, and will
+always return a a BadDevice error.
 
-   Using these requests may change the characteristics of the core
-   devices. The new pointer device may have a different number of
-   buttons than the old one did, or the new keyboard device may
-   have a different number of keys or report a different range of
-   keycodes. Client programs may be running that depend on those
-   characteristics. For example, a client program could allocate
-   an array based on the number of buttons on the pointer device,
-   and then use the button numbers received in button events as
-   indicies into that array. Changing the core devices could cause
-   such client programs to behave improperly or abnormally
-   terminate.
+Using these requests may change the characteristics of the core
+devices. The new pointer device may have a different number of
+buttons than the old one did, or the new keyboard device may
+have a different number of keys or report a different range of
+keycodes. Client programs may be running that depend on those
+characteristics. For example, a client program could allocate
+an array based on the number of buttons on the pointer device,
+and then use the button numbers received in button events as
+indicies into that array. Changing the core devices could cause
+such client programs to behave improperly or abnormally
+terminate.
 
-   These requests change the X keyboard or X pointer device and
-   generate an ChangeDeviceNotify event and a MappingNotify event.
-   The ChangeDeviceNotify event is sent only to those clients that
-   have expressed an interest in receiving that event via the
-   XSelectExtensionEvent request. The specified device becomes the
-   new X keyboard or X pointer device. The location of the core
-   device does not change as a result of this request.
+These requests change the X keyboard or X pointer device and
+generate an ChangeDeviceNotify event and a MappingNotify event.
+The ChangeDeviceNotify event is sent only to those clients that
+have expressed an interest in receiving that event via the
+XSelectExtensionEvent request. The specified device becomes the
+new X keyboard or X pointer device. The location of the core
+device does not change as a result of this request.
 
-   These requests fail and return AlreadyGrabbed if either the
-   specified device or the core device it would replace are
-   grabbed by some other client. They fail and return GrabFrozen
-   if either device is frozen by the active grab of another
-   client.
+These requests fail and return AlreadyGrabbed if either the
+specified device or the core device it would replace are
+grabbed by some other client. They fail and return GrabFrozen
+if either device is frozen by the active grab of another
+client.
 
-   These requests fail with a BadDevice error if the specified
-   device is invalid, or has not previously been opened via
-   OpenDevice. To change the X keyboard device, use the
-   ChangeKeyboardDevice request. The specified device must support
-   input class Keys (as reported in the ListInputDevices request)
-   or the request will fail with a BadMatch error. Once the device
-   has successfully replaced one of the core devices, it is
-   treated as a core device until it is in turn replaced by
-   another ChangeDevice request, or until the server terminates.
-   The termination of the client that changed the device will not
-   cause it to change back. Attempts to use the CloseDevice
-   request to close the new core device will fail with a BadDevice
-   error.
+These requests fail with a BadDevice error if the specified
+device is invalid, or has not previously been opened via
+OpenDevice. To change the X keyboard device, use the
+ChangeKeyboardDevice request. The specified device must support
+input class Keys (as reported in the ListInputDevices request)
+or the request will fail with a BadMatch error. Once the device
+has successfully replaced one of the core devices, it is
+treated as a core device until it is in turn replaced by
+another ChangeDevice request, or until the server terminates.
+The termination of the client that changed the device will not
+cause it to change back. Attempts to use the CloseDevice
+request to close the new core device will fail with a BadDevice
+error.
 
-   The focus state of the new keyboard is the same as the focus
-   state of the old X keyboard. If the new keyboard was not
-   initialized with a FocusRec, one is added by the
-   ChangeKeyboardDevice request. The X keyboard is assumed to have
-   a KbdFeedbackClassRec. If the device was initialized without a
-   KbdFeedbackClassRec, one will be added by this request. The
-   KbdFeedbackClassRec will specify a null routine as the control
-   procedure and the bell procedure.
+The focus state of the new keyboard is the same as the focus
+state of the old X keyboard. If the new keyboard was not
+initialized with a FocusRec, one is added by the
+ChangeKeyboardDevice request. The X keyboard is assumed to have
+a KbdFeedbackClassRec. If the device was initialized without a
+KbdFeedbackClassRec, one will be added by this request. The
+KbdFeedbackClassRec will specify a null routine as the control
+procedure and the bell procedure.
 
-                   ChangeKeyboardDevice
-                           device: DEVICE
-                   =>
-                           status: Success, AlreadyGrabbed, Frozen
+                ChangeKeyboardDevice
+                        device: DEVICE
+                =>
+                        status: Success, AlreadyGrabbed, Frozen
 
    Errors: Device, Match
 
-   To change the X pointer device, use the ChangePointerDevice
-   request. The specified device must support input class
-   Valuators (as reported in the ListInputDevices request) or the
-   request will fail with a BadMatch error. The valuators to be
-   used as the x- and y-axes of the pointer device must be
-   specified. Data from other valuators on the device will be
-   ignored.
+To change the X pointer device, use the ChangePointerDevice
+request. The specified device must support input class
+Valuators (as reported in the ListInputDevices request) or the
+request will fail with a BadMatch error. The valuators to be
+used as the x- and y-axes of the pointer device must be
+specified. Data from other valuators on the device will be
+ignored.
 
-   The X pointer device does not contain a FocusRec. If the new
-   pointer was initialized with a FocusRec, it is freed by the
-   ChangePointerDevice request. The X pointer is assumed to have a
-   ButtonClassRec and a PtrFeedbackClassRec. If the device was
-   initialized without a ButtonClassRec or a PtrFeedbackClassRec,
-   one will be added by this request. The ButtonClassRec added
-   will have no buttons, and the PtrFeedbackClassRec will specify
-   a null routine as the control procedure.
+The X pointer device does not contain a FocusRec. If the new
+pointer was initialized with a FocusRec, it is freed by the
+ChangePointerDevice request. The X pointer is assumed to have a
+ButtonClassRec and a PtrFeedbackClassRec. If the device was
+initialized without a ButtonClassRec or a PtrFeedbackClassRec,
+one will be added by this request. The ButtonClassRec added
+will have no buttons, and the PtrFeedbackClassRec will specify
+a null routine as the control procedure.
 
-   If the specified device reports absolute positional
-   information, and the server implementation does not allow such
-   a device to be used as the X pointer, the request will fail
-   with a BadDevice error.
+If the specified device reports absolute positional
+information, and the server implementation does not allow such
+a device to be used as the X pointer, the request will fail
+with a BadDevice error.
 
-   Once the device has successfully replaced one of the core
-   devices, it is treated as a core device until it is in turn
-   replaced by another ChangeDevice request, or until the server
-   terminates. The termination of the client that changed the
-   device will not cause it to change back. Attempts to use the
-   CloseDevice request to close the new core device will fail with
-   a BadDevice error.
+Once the device has successfully replaced one of the core
+devices, it is treated as a core device until it is in turn
+replaced by another ChangeDevice request, or until the server
+terminates. The termination of the client that changed the
+device will not cause it to change back. Attempts to use the
+CloseDevice request to close the new core device will fail with
+a BadDevice error.
 
-                   ChangePointerDevice
-                           device: DEVICE
-                           xaxis: CARD8
-                           yaxis: CARD8
-                   =>
-                           status: Success, AlreadyGrabbed, Frozen
+                ChangePointerDevice
+                        device: DEVICE
+                        xaxis: CARD8
+                        yaxis: CARD8
+                =>
+                     status: Success, AlreadyGrabbed, Frozen
 
    Errors: Device, Match
 
 2.12 Event Synchronization And Core Grabs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   Implementation of the input extension requires an extension of
-   the meaning of event synchronization for the core grab
-   requests. This is necessary in order to allow window managers
-   to freeze all input devices with a single request.
+Implementation of the input extension requires an extension of
+the meaning of event synchronization for the core grab
+requests. This is necessary in order to allow window managers
+to freeze all input devices with a single request.
 
-   The core grab requests require a pointer_mode and keyboard_mode
-   argument. The meaning of these modes is changed by the input
-   extension. For the XGrabPointer and XGrabButton requests,
-   pointer_mode controls synchronization of the pointer device,
-   and keyboard_mode controls the synchronization of all other
-   input devices. For the XGrabKeyboard and XGrabKey requests,
-   pointer_mode controls the synchronization of all input devices
-   except the X keyboard, while keyboard_mode controls the
-   synchronization of the keyboard. When using one of the core
-   grab requests, the synchronization of extension devices is
-   controlled by the mode specified for the device not being
-   grabbed.
+The core grab requests require a pointer_mode and keyboard_mode
+argument. The meaning of these modes is changed by the input
+extension. For the XGrabPointer and XGrabButton requests,
+pointer_mode controls synchronization of the pointer device,
+and keyboard_mode controls the synchronization of all other
+input devices. For the XGrabKeyboard and XGrabKey requests,
+pointer_mode controls the synchronization of all input devices
+except the X keyboard, while keyboard_mode controls the
+synchronization of the keyboard. When using one of the core
+grab requests, the synchronization of extension devices is
+controlled by the mode specified for the device not being
+grabbed.
 
 2.13 Extension Active Grabs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   Active grabs of extension devices are supported via the
-   GrabDevice request in the same way that core devices are
-   grabbed using the core GrabKeyboard request, except that a
-   Device is passed as a function parameter. A list of events that
-   the client wishes to receive is also passed. The UngrabDevice
-   request allows a previous active grab for an extension device
-   to be released.
+Active grabs of extension devices are supported via the
+GrabDevice request in the same way that core devices are
+grabbed using the core GrabKeyboard request, except that a
+Device is passed as a function parameter. A list of events that
+the client wishes to receive is also passed. The UngrabDevice
+request allows a previous active grab for an extension device
+to be released.
 
-   To grab an extension device, use the GrabDevice request. The
-   device must have previously been opened using the OpenDevice
-   request.
+To grab an extension device, use the GrabDevice request. The
+device must have previously been opened using the OpenDevice
+request.
 
-                   GrabDevice
-                           device: DEVICE
-                           grab-window: WINDOW
-                           owner-events: BOOL
-                           event-list: LISTofEVENTCLASS
-                           this-device-mode: {Synchronous, Asynchronous}
-                           other-device-mode: {Synchronous, Asynchronous}
-                           time:TIMESTAMP or CurrentTime
-                   =>
-                           status: Success, AlreadyGrabbed, Frozen,
-                                   InvalidTime, NotViewable
+                GrabDevice
+                        device: DEVICE
+                        grab-window: WINDOW
+                        owner-events: BOOL
+                        event-list: LISTofEVENTCLASS
+                        this-device-mode: {Synchronous, Asynchronous}
+                        other-device-mode: {Synchronous, Asynchronous}
+                        time:TIMESTAMP or CurrentTime
+                =>
+                        status: Success, AlreadyGrabbed, Frozen,
+                                InvalidTime, NotViewable
 
    Errors: Device, Window, Value
 
-   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 overrides any previous
-   active grab by this client for this 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 overrides any previous
+active grab by this client for this device.
 
-   The event-list parameter is a pointer to a list of event
-   classes. These are used to indicate which events the client
-   wishes to receive while the device is grabbed. Only event
-   classes obtained from the grabbed device are valid.
+The event-list parameter is a pointer to a list of event
+classes. These are used to indicate which events the client
+wishes to receive while the device is grabbed. Only event
+classes obtained from the grabbed device are valid.
 
-   If owner-events is False, input events generated from this
-   device are reported with respect to grab-window, and are only
-   reported if selected by being included in the event-list. If
-   owner-events is True, then if a generated event would normally
-   be reported to this client, it is reported normally, otherwise
-   the event is reported with respect to the grab-window, and is
-   only reported if selected by being included in the event-list.
-   For either value of owner-events, unreported events are
-   discarded.
+If owner-events is False, input events generated from this
+device are reported with respect to grab-window, and are only
+reported if selected by being included in the event-list. If
+owner-events is True, then if a generated event would normally
+be reported to this client, it is reported normally, otherwise
+the event is reported with respect to the grab-window, and is
+only reported if selected by being included in the event-list.
+For either value of owner-events, unreported events are
+discarded.
 
-   If this-device-mode is Asynchronous, device event processing
-   continues normally. If the device is currently frozen by this
-   client, then processing of device events is resumed. If
-   this-device-mode is Synchronous, the state of the grabbed
-   device (as seen by means of the protocol) appears to freeze,
-   and no further device events are generated by the server until
-   the grabbing client issues a releasing AllowDeviceEvents
-   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.
+If this-device-mode is Asynchronous, device event processing
+continues normally. If the device is currently frozen by this
+client, then processing of device events is resumed. If
+this-device-mode is Synchronous, the state of the grabbed
+device (as seen by means of the protocol) appears to freeze,
+and no further device events are generated by the server until
+the grabbing client issues a releasing AllowDeviceEvents
+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.
 
-   If other-device-mode is Asynchronous, event processing is
-   unaffected by activation of the grab. If other-device-mode is
-   Synchronous, the state of all input devices except the grabbed
-   one (as seen by means of the protocol) appears to freeze, and
-   no further events are generated by the server until the
-   grabbing client issues a releasing AllowDeviceEvents request or
-   until the device grab is released. Actual events are not lost
-   while the devices are frozen; they are simply queued for later
-   processing.
+If other-device-mode is Asynchronous, event processing is
+unaffected by activation of the grab. If other-device-mode is
+Synchronous, the state of all input devices except the grabbed
+one (as seen by means of the protocol) appears to freeze, and
+no further events are generated by the server until the
+grabbing client issues a releasing AllowDeviceEvents request or
+until the device grab is released. Actual events are not lost
+while the devices are frozen; they are simply queued for later
+processing.
 
-   This request generates DeviceFocusIn and DeviceFocusOut events.
+This request generates DeviceFocusIn and DeviceFocusOut events.
 
-   This request fails and returns:
+This request fails and returns:
 
    AlreadyGrabbed
           If the device is actively grabbed by some other client.
@@ -1144,59 +1168,61 @@
           If the device is frozen by an active grab of another
           client.
 
-   If a grabbed device is closed by a client while an active grab
-   by that client is in effect, that active grab will be released.
-   Any passive grabs established by that client will be released.
-   If the device is frozen only by an active grab of the
-   requesting client, it is thawed.
+If a grabbed device is closed by a client while an active grab
+by that client is in effect, that active grab will be released.
+Any passive grabs established by that client will be released.
+If the device is frozen only by an active grab of the
+requesting client, it is thawed.
 
-   To release a grab of an extension device, use UngrabDevice.
+To release a grab of an extension device, use UngrabDevice.
 
-                   UngrabDevice
-                           device: DEVICE
-                           time: TIMESTAMP or CurrentTime
+               UngrabDevice
+                       device: DEVICE
+                       time: TIMESTAMP or CurrentTime
 
    Errors: Device
 
-   This request releases the device if this client has it actively
-   grabbed (from either GrabDevice or GrabDeviceKey) and releases
-   any queued events. If any devices were frozen by the grab,
-   UngrabDevice thaws them. The request has no effect if the
-   specified time is earlier than the last-device-grab time or is
-   later than the current server time.
+This request releases the device if this client has it actively
+grabbed (from either GrabDevice or GrabDeviceKey) and releases
+any queued events. If any devices were frozen by the grab,
+UngrabDevice thaws them. The request has no effect if the
+specified time is earlier than the last-device-grab time or is
+later than the current server time.
 
-   This request generates DeviceFocusIn and DeviceFocusOut events.
+This request generates DeviceFocusIn and DeviceFocusOut events.
 
-   An UngrabDevice is performed automatically if the event window
-   for an active device grab becomes not viewable.
+An UngrabDevice is performed automatically if the event window
+for an active device grab becomes not viewable.
 
 2.14 Passively Grabbing A Key
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   Passive grabs of buttons and keys on extension devices are
-   supported via the GrabDeviceButton and GrabDeviceKey requests.
-   These passive grabs are released via the UngrabDeviceKey and
-   UngrabDeviceButton requests.
+Passive grabs of buttons and keys on extension devices are
+supported via the GrabDeviceButton and GrabDeviceKey requests.
+These passive grabs are released via the UngrabDeviceKey and
+UngrabDeviceButton requests.
 
-   To passively grab a single key on an extension device, use
-   GrabDeviceKey. That device must have previously been opened
-   using the OpenDevice request.
+To passively grab a single key on an extension device, use
+GrabDeviceKey. That device must have previously been opened
+using the OpenDevice request.
 
-                   GrabDeviceKey
-                           device: DEVICE
-                           keycode: KEYCODE or AnyKey
-                           modifiers: SETofKEYMASK or AnyModifier
-                           modifier-device: DEVICE or NULL
-                           grab-window: WINDOW
-                           owner-events: BOOL
-                           event-list: LISTofEVENTCLASS
-                           this-device-mode: {Synchronous, Asynchronous}
-                           other-device-mode: {Synchronous, Asynchronous}
+            GrabDeviceKey
+                    device: DEVICE
+                    keycode: KEYCODE or AnyKey
+                    modifiers: SETofKEYMASK or AnyModifier
+                    modifier-device: DEVICE or NULL
+                    grab-window: WINDOW
+                    owner-events: BOOL
+                    event-list: LISTofEVENTCLASS
+                    this-device-mode: {Synchronous, Asynchronous}
+                    other-device-mode: {Synchronous, Asynchronous}
 
    Errors: Device, Match, Access, Window, Value
 
-   This request is analogous to the core GrabKey request. It
-   establishes a passive grab on a device. Consequently, in the
-   future:
+This request is analogous to the core GrabKey request. It
+establishes a passive grab on a device. Consequently, in the
+future:
+
      * IF the device is not grabbed and the specified key, which
        itself can be a modifier key, is logically pressed when the
        specified modifier keys logically are down on the specified
@@ -1212,202 +1238,197 @@
        was pressed (as transmitted in the DeviceKeyPress event),
        and the DeviceKeyPress event is reported.
 
-   The interpretation of the remaining arguments is as for
-   GrabDevice. The active grab is terminated automatically when
-   logical state of the device has the specified key released
-   (independent of the logical state of the modifier keys).
+The interpretation of the remaining arguments is as for
+GrabDevice. The active grab is terminated automatically when
+logical state of the device has the specified key released
+(independent of the logical state of the modifier keys).
 
-   Note that the logical state of a device (as seen by means of
-   the X protocol) may lag the physical state if device event
-   processing is frozen.
+Note that the logical state of a device (as seen by means of
+the X protocol) may lag the physical state if device event
+processing is frozen.
 
-   A modifier of AnyModifier is equivalent to issuing the request
-   for all possible modifier combinations (including the
-   combination of no modifiers). It is not required that all
-   modifiers specified have currently assigned keycodes. A key of
-   AnyKey is equivalent to issuing the request for all possible
-   keycodes. Otherwise, the key must be in the range specified by
-   min-keycode and max-keycode in the ListInputDevices request. If
-   it is not within that range, GrabDeviceKey generates a Value
-   error.
+A modifier of AnyModifier is equivalent to issuing the request
+for all possible modifier combinations (including the
+combination of no modifiers). It is not required that all
+modifiers specified have currently assigned keycodes. A key of
+AnyKey is equivalent to issuing the request for all possible
+keycodes. Otherwise, the key must be in the range specified by
+min-keycode and max-keycode in the ListInputDevices request. If
+it is not within that range, GrabDeviceKey generates a Value
+error.
 
-   NULL may be passed for the modifier_device. If the
-   modifier_device is NULL, the core X keyboard is used as the
-   modifier_device.
+NULL may be passed for the modifier_device. If the
+modifier_device is NULL, the core X keyboard is used as the
+modifier_device.
 
-   An Access error is generated if some other client has issued a
-   GrabDeviceKey with the same device and key combination on the
-   same window. When using AnyModifier or AnyKey, the request
-   fails completely and the X server generates a Access error and
-   no grabs are established if there is a conflicting grab for any
-   combination.
+An Access error is generated if some other client has issued a
+GrabDeviceKey with the same device and key combination on the
+same window. When using AnyModifier or AnyKey, the request
+fails completely and the X server generates a Access error and
+no grabs are established if there is a conflicting grab for any
+combination.
 
-   This request cannot be used to grab a key on the X keyboard
-   device. The core GrabKey request should be used for that
-   purpose.
+This request cannot be used to grab a key on the X keyboard
+device. The core GrabKey request should be used for that
+purpose.
 
-   To release a passive grab of a single key on an extension
-   device, use UngrabDeviceKey.
+To release a passive grab of a single key on an extension
+device, use UngrabDeviceKey.
 
-                   UngrabDeviceKey
-                           device: DEVICE
-                           keycode: KEYCODE or AnyKey
-                           modifiers: SETofKEYMASK or AnyModifier
-                           modifier-device: DEVICE or NULL
-                           grab-window: WINDOW
+           UngrabDeviceKey
+                   device: DEVICE
+                   keycode: KEYCODE or AnyKey
+                   modifiers: SETofKEYMASK or AnyModifier
+                   modifier-device: DEVICE or NULL
+                   grab-window: WINDOW
 
    Errors: Device, Match, Window, Value, Alloc
 
-   This request is analogous to the core UngrabKey request. It
-   releases the key combination on the specified window if it was
-   grabbed by this client. A modifier of AnyModifier is equivalent
-   to issuing the request for all possible modifier combinations
-   (including the combination of no modifiers). A key of AnyKey is
-   equivalent to issuing the request for all possible keycodes.
-   This request has no effect on an active grab.
+This request is analogous to the core UngrabKey request. It
+releases the key combination on the specified window if it was
+grabbed by this client. A modifier of AnyModifier is equivalent
+to issuing the request for all possible modifier combinations
+(including the combination of no modifiers). A key of AnyKey is
+equivalent to issuing the request for all possible keycodes.
+This request has no effect on an active grab.
 
-   NULL may be passed for the modifier_device. If the
-   modifier_device is NULL, the core X keyboard is used as the
-   modifier_device.
+NULL may be passed for the modifier_device. If the
+modifier_device is NULL, the core X keyboard is used as the
+modifier_device.
 
 2.15 Passively Grabbing A Button
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   To establish a passive grab for a single button on an extension
-   device, use GrabDeviceButton.
+To establish a passive grab for a single button on an extension
+device, use GrabDeviceButton.
 
-                   GrabDeviceButton
-                           device: DEVICE
-                           button: BUTTON or AnyButton
-                           modifiers: SETofKEYMASK or AnyModifier
-                           modifier-device: DEVICE or NULL
-                           grab-window: WINDOW
-                           owner-events: BOOL
-                           event-list: LISTofEVENTCLASS
-                           this-device-mode: {Synchronous, Asynchr
-   onous}
-                           other-device-mode: {Synchronous, Asynch
-   ronous}
+                GrabDeviceButton
+                        device: DEVICE
+                        button: BUTTON or AnyButton
+                        modifiers: SETofKEYMASK or AnyModifier
+                        modifier-device: DEVICE or NULL
+                        grab-window: WINDOW
+                        owner-events: BOOL
+                        event-list: LISTofEVENTCLASS
+                        this-device-mode: {Synchronous, Asynchronous}
+                        other-device-mode: {Synchronous, Asynchronous}
 
    Errors: Device, Match, Window, Access, Value
 
-   This request is analogous to the core GrabButton request. It
-   establishes an explicit passive grab for a button on an
-   extension input device. Since the server does not track
-   extension devices, no cursor is specified with this request.
-   For the same reason, there is no confine-to parameter. The
-   device must have previously been opened using the OpenDevice
-   request.
+This request is analogous to the core GrabButton request. It
+establishes an explicit passive grab for a button on an
+extension input device. Since the server does not track
+extension devices, no cursor is specified with this request.
+For the same reason, there is no confine-to parameter. The
+device must have previously been opened using the OpenDevice
+request.
 
-   The GrabDeviceButton request establishes a passive grab on a
-   device. Consequently, in the future,
+The GrabDeviceButton request establishes a passive grab on a
+device. Consequently, in the future,
 
-   •
-          IF the device is not grabbed and the specified button is
-          logically pressed when the specified modifier keys
-          logically are down (and no other buttons or modifier
-          keys are down),
+   * IF the device is not grabbed and the specified button is
+     logically pressed when the specified modifier keys
+     logically are down (and no other buttons or modifier
+     keys are down),
 
-   •
-          AND the grab window contains the device,
+   * AND the grab window contains the device,
 
-   •
-          AND a passive grab on the same device and button/ key
-          combination does not exist on any ancestor of the grab
-          window,
+   * AND a passive grab on the same device and button/ key
+     combination does not exist on any ancestor of the grab
+     window,
 
-   •
-          THEN the device is actively grabbed, as for GrabDevice,
-          the last-grab time is set to the time at which the
-          button was pressed (as transmitted in the
-          DeviceButtonPress event), and the DeviceButtonPress
-          event is reported.
+   * THEN the device is actively grabbed, as for GrabDevice,
+     the last-grab time is set to the time at which the
+     button was pressed (as transmitted in the
+     DeviceButtonPress event), and the DeviceButtonPress
+     event is reported.
 
-   The interpretation of the remaining arguments is as for
-   GrabDevice. The active grab is terminated automatically when
-   logical state of the device has all buttons released
-   (independent of the logical state of the modifier keys).
+The interpretation of the remaining arguments is as for
+GrabDevice. The active grab is terminated automatically when
+logical state of the device has all buttons released
+(independent of the logical state of the modifier keys).
 
-   Note that the logical state of a device (as seen by means of
-   the X protocol) may lag the physical state if device event
-   processing is frozen.
+Note that the logical state of a device (as seen by means of
+the X protocol) may lag the physical state if device event
+processing is frozen.
 
-   A modifier of AnyModifier is equivalent to issuing the request
-   for all possible modifier combinations (including the
-   combination of no modifiers). It is not required that all
-   modifiers specified have currently assigned keycodes. A button
-   of AnyButton is equivalent to issuing the request for all
-   possible buttons. It is not required that the specified button
-   be assigned to a physical button.
+A modifier of AnyModifier is equivalent to issuing the request
+for all possible modifier combinations (including the
+combination of no modifiers). It is not required that all
+modifiers specified have currently assigned keycodes. A button
+of AnyButton is equivalent to issuing the request for all
+possible buttons. It is not required that the specified button
+be assigned to a physical button.
 
-   NULL may be passed for the modifier_device. If the
-   modifier_device is NULL, the core X keyboard is used as the
-   modifier_device.
+NULL may be passed for the modifier_device. If the
+modifier_device is NULL, the core X keyboard is used as the
+modifier_device.
 
-   An Access error is generated if some other client has issued a
-   GrabDeviceButton with the same device and button combination on
-   the same window. When using AnyModifier or AnyButton, the
-   request fails completely and the X server generates a Access
-   error and no grabs are established if there is a conflicting
-   grab for any combination. The request has no effect on an
-   active grab.
+An Access error is generated if some other client has issued a
+GrabDeviceButton with the same device and button combination on
+the same window. When using AnyModifier or AnyButton, the
+request fails completely and the X server generates a Access
+error and no grabs are established if there is a conflicting
+grab for any combination. The request has no effect on an
+active grab.
 
-   This request cannot be used to grab a button on the X pointer
-   device. The core GrabButton request should be used for that
-   purpose.
+This request cannot be used to grab a button on the X pointer
+device. The core GrabButton request should be used for that
+purpose.
 
-   To release a passive grab of a button on an extension device,
-   use UngrabDeviceButton.
+To release a passive grab of a button on an extension device,
+use UngrabDeviceButton.
 
-                   UngrabDeviceButton
-                           device: DEVICE
-                           button: BUTTON or AnyButton
-                           modifiers: SETofKEYMASK or AnyModifier
-                           modifier-device: DEVICE or NULL
-                           grab-window: WINDOW
+                UngrabDeviceButton
+                        device: DEVICE
+                        button: BUTTON or AnyButton
+                        modifiers: SETofKEYMASK or AnyModifier
+                        modifier-device: DEVICE or NULL
+                        grab-window: WINDOW
 
    Errors: Device, Match, Window, Value, Alloc
 
-   This request is analogous to the core UngrabButton request. It
-   releases the passive button/key combination on the specified
-   window if it was grabbed by the client. A modifiers of
-   AnyModifier is equivalent to issuing the request for all
-   possible modifier combinations (including the combination of no
-   modifiers). A button of AnyButton is equivalent to issuing the
-   request for all possible buttons. This request has no effect on
-   an active grab. The device must have previously been opened
-   using the OpenDevice request otherwise a Device error will be
-   generated.
+This request is analogous to the core UngrabButton request. It
+releases the passive button/key combination on the specified
+window if it was grabbed by the client. A modifiers of
+AnyModifier is equivalent to issuing the request for all
+possible modifier combinations (including the combination of no
+modifiers). A button of AnyButton is equivalent to issuing the
+request for all possible buttons. This request has no effect on
+an active grab. The device must have previously been opened
+using the OpenDevice request otherwise a Device error will be
+generated.
 
-   NULL may be passed for the modifier_device. If the
-   modifier_device is NULL, the core X keyboard is used as the
-   modifier_device.
+NULL may be passed for the modifier_device. If the
+modifier_device is NULL, the core X keyboard is used as the
+modifier_device.
 
-   This request cannot be used to ungrab a button on the X pointer
-   device. The core UngrabButton request should be used for that
-   purpose.
+This request cannot be used to ungrab a button on the X pointer
+device. The core UngrabButton request should be used for that
+purpose.
 
 2.16 Thawing A Device
+~~~~~~~~~~~~~~~~~~~~~
 
-   To allow further events to be processed when a device has been
-   frozen, use AllowDeviceEvents.
+To allow further events to be processed when a device has been
+frozen, use AllowDeviceEvents.
 
-                   AllowDeviceEvents
-                           device: DEVICE
-                           event-mode: {AsyncThisDevice, SyncThisD
-   evice, AsyncOtherDevices,
-                           ReplayThisdevice, AsyncAll, or SyncAll}
-                           time:TIMESTAMP or CurrentTime
+                AllowDeviceEvents
+                        device: DEVICE
+                        event-mode: {AsyncThisDevice, SyncThisDevice, AsyncOtherDevices,
+                        ReplayThisdevice, AsyncAll, or SyncAll}
+                        time:TIMESTAMP or CurrentTime
 
    Errors: Device, Value
 
-   The AllowDeviceEvents request releases some queued events if
-   the client has caused a device to freeze. 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 AllowDeviceEvents request releases some queued events if
+the client has caused a device to freeze. 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 following describes the processing that occurs depending on
-   what constant you pass to the event-mode argument:
+The following describes the processing that occurs depending on
+what constant you pass to the event-mode argument:
 
    * If the specified device is frozen by the client, event
      processing for that device continues as usual. If the
@@ -1469,66 +1490,67 @@
      AsyncAll has no effect unless all devices are frozen by
      the client.
 
-     AsyncThisDevice, SyncThisDevice, and ReplayThisDevice
-     have no effect on the processing of events from the
-     remaining devices. AsyncOtherDevices has no effect on
-     the processing of events from the specified device. When
-     the event_mode is SyncAll or AsyncAll, the device
-     parameter is ignored.
+AsyncThisDevice, SyncThisDevice, and ReplayThisDevice
+have no effect on the processing of events from the
+remaining devices. AsyncOtherDevices has no effect on
+the processing of events from the specified device. When
+the event_mode is SyncAll or AsyncAll, the device
+parameter is ignored.
 
-     It is possible for several grabs of different devices
-     (by the same or different clients) to be active
-     simultaneously. If a device is frozen on behalf of any
-     grab, no event processing is performed for the device.
-     It is possible for a single device to be frozen because
-     of several grabs. In this case, the freeze must be
-     released on behalf of each grab before events can again
-     be processed.
+It is possible for several grabs of different devices
+(by the same or different clients) to be active
+simultaneously. If a device is frozen on behalf of any
+grab, no event processing is performed for the device.
+It is possible for a single device to be frozen because
+of several grabs. In this case, the freeze must be
+released on behalf of each grab before events can again
+be processed.
 
 2.17 Controlling Device Focus
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   The current focus window for an extension input device can be
-   determined using the GetDeviceFocus request. Extension devices
-   are focused using the SetDeviceFocus request in the same way
-   that the keyboard is focused using the SetInputFocus request,
-   except that a device is specified as part of the request. One
-   additional focus state, FollowKeyboard, is provided for
-   extension devices.
+The current focus window for an extension input device can be
+determined using the GetDeviceFocus request. Extension devices
+are focused using the SetDeviceFocus request in the same way
+that the keyboard is focused using the SetInputFocus request,
+except that a device is specified as part of the request. One
+additional focus state, FollowKeyboard, is provided for
+extension devices.
 
-   To get the current focus state, revert state, and focus time of
-   an extension device, use GetDeviceFocus.
+To get the current focus state, revert state, and focus time of
+an extension device, use GetDeviceFocus.
 
-                   GetDeviceFocus
-                           device: DEVICE
-                   =>
-                           focus: WINDOW, PointerRoot, FollowKeyboard, or None
-                           revert-to: Parent, PointerRoot, FollowKeyboard, or None
-                           focus-time: TIMESTAMP
+                GetDeviceFocus
+                        device: DEVICE
+                =>
+                        focus: WINDOW, PointerRoot, FollowKeyboard, or None
+                        revert-to: Parent, PointerRoot, FollowKeyboard, or None
+                        focus-time: TIMESTAMP
 
    Errors: Device, Match
 
-   This request returns the current focus state, revert-to state,
-   and last-focus-time of an extension device.
+This request returns the current focus state, revert-to state,
+and last-focus-time of an extension device.
 
-   To set the focus of an extension device, use SetDeviceFocus.
+To set the focus of an extension device, use SetDeviceFocus.
 
-                   SetDeviceFocus
-                           device: DEVICE
-                           focus: WINDOW, PointerRoot, FollowKeyboard, or None
-                           revert-to: Parent, PointerRoot, FollowKeyboard, or None
-                           focus-time: TIMESTAMP
+                SetDeviceFocus
+                        device: DEVICE
+                        focus: WINDOW, PointerRoot, FollowKeyboard, or None
+                        revert-to: Parent, PointerRoot, FollowKeyboard, or None
+                        focus-time: TIMESTAMP
 
    Errors: Device, Window, Value, Match
 
-   This request changes the focus for an extension input device
-   and the last-focus-change-time. The request has no effect if
-   the specified time is earlier than the 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, with
-   CurrentTime replaced by the current server time.
+This request changes the focus for an extension input device
+and the last-focus-change-time. The request has no effect if
+the specified time is earlier than the 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, with
+CurrentTime replaced by the current server time.
 
-   The action taken by the server when this request is requested
-   depends on the value of the focus argument:
+The action taken by the server when this request is requested
+depends on the value of the focus argument:
 
    * If the focus argument is None, all input events from
      this device will be discarded until a new focus window
@@ -1549,7 +1571,6 @@
    * If you assign FollowKeyboard to the focus argument, the
      focus window is dynamically taken to be the same as the
      focus of the X keyboard at each input event.
-
      The specified focus window must be viewable at the time
      of the request (else a Match error). If the focus window
      later becomes not viewable, the X server evaluates the
@@ -1564,973 +1585,992 @@
      RevertToFollowKeyboard, or RevertToNone to the revert-to
      argument, the focus reverts to that value.
 
-   When the focus reverts, the X server generates DeviceFocusIn
-   and DeviceFocusOut events, but the last-focus-change time is
-   not affected.
+When the focus reverts, the X server generates DeviceFocusIn
+and DeviceFocusOut events, but the last-focus-change time is
+not affected.
 
-   This request causes the X server to generate DeviceFocusIn and
-   DeviceFocusOut events.
+This request causes the X server to generate DeviceFocusIn and
+DeviceFocusOut events.
 
 2.18 Controlling Device Feedback
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   To get the settings of feedbacks on an extension device, use
-   GetFeedbackControl. This request provides functionality
-   equivalent to the core GetKeyboardControl and GetPointerControl
-   functions. It also provides a way to control displays
-   associated with an input device that are capable of displaying
-   an integer or string.
+To get the settings of feedbacks on an extension device, use
+GetFeedbackControl. This request provides functionality
+equivalent to the core GetKeyboardControl and GetPointerControl
+functions. It also provides a way to control displays
+associated with an input device that are capable of displaying
+an integer or string.
 
-                   GetFeedbackControl
-                           device: DEVICE
-                   =>
-                           num_feedbacks_return: CARD16
-                           return_value: LISTofFEEDBACKSTATE
+                GetFeedbackControl
+                        device: DEVICE
+                =>
+                        num_feedbacks_return: CARD16
+                        return_value: LISTofFEEDBACKSTATE
 
-   where
+where
 
-                       FEEDBACKSTATE: {KbdFeedbackState, PtrFeedbackState,
-                                       IntegerFeedbackState, StringFeedbackState,
-                                       BellFeedbackState, LedFeedbackState}
+                    FEEDBACKSTATE: {KbdFeedbackState, PtrFeedbackState,
+                                    IntegerFeedbackState, StringFeedbackState,
+                                    BellFeedbackState, LedFeedbackState}
 
-   Feedbacks are reported by class. Those feedbacks that are
-   reported for the core keyboard device are in class KbdFeedback,
-   and are returned in the KbdFeedbackState structure. The members
-   of that structure are as follows:
+Feedbacks are reported by class. Those feedbacks that are
+reported for the core keyboard device are in class KbdFeedback,
+and are returned in the KbdFeedbackState structure. The members
+of that structure are as follows:
 
-                   CLASS Kbd:
-                           [class: CARD8
-                            length: CARD16
-                            feedback id: CARD8
-                            key_click_percent: CARD8
-                            bell_percent: CARD8
-                            bell_pitch: CARD16
-                            bell_duration: CARD16
-                            led_value: BITMASK
-                            global_auto_repeat: {AutoRepeatModeOn, AutoRepeatModeOff}
-                            auto_repeats: LISTofCARD8]
+                CLASS Kbd:
+                        [class: CARD8
+                         length: CARD16
+                         feedback id: CARD8
+                         key_click_percent: CARD8
+                         bell_percent: CARD8
+                         bell_pitch: CARD16
+                         bell_duration: CARD16
+                         led_value: BITMASK
+                         global_auto_repeat: {AutoRepeatModeOn, AutoRepeatModeOff}
+                         auto_repeats: LISTofCARD8]
 
-   Those feedbacks that are equivalent to those reported for the
-   core pointer are in feedback class PtrFeedback and are reported
-   in the PtrFeedbackState structure. The members of that
-   structure are:
+Those feedbacks that are equivalent to those reported for the
+core pointer are in feedback class PtrFeedback and are reported
+in the PtrFeedbackState structure. The members of that
+structure are:
 
-                   CLASS Ptr:
-                           [class: CARD8
-                            length: CARD16
-                            feedback id: CARD8
-                            accelNumerator: CARD16
-                            accelDenominator: CARD16
-                            threshold: CARD16]
+                CLASS Ptr:
+                        [class: CARD8
+                         length: CARD16
+                         feedback id: CARD8
+                         accelNumerator: CARD16
+                         accelDenominator: CARD16
+                         threshold: CARD16]
 
-   Some input devices provide a means of displaying an integer.
-   Those devices will support feedback class IntegerFeedback,
-   which is reported in the IntegerFeedbackState structure. The
-   members of that structure are:
+Some input devices provide a means of displaying an integer.
+Those devices will support feedback class IntegerFeedback,
+which is reported in the IntegerFeedbackState structure. The
+members of that structure are:
 
-                     CLASS Integer:
-                           [class: CARD8
-                            length: CARD16
-                            feedback id: CARD8
-                            resolution: CARD32
-                            min-val: INT32
-                            max-val: INT32]
+                  CLASS Integer:
+                        [class: CARD8
+                         length: CARD16
+                         feedback id: CARD8
+                         resolution: CARD32
+                         min-val: INT32
+                         max-val: INT32]
 
-   Some input devices provide a means of displaying a string.
-   Those devices will support feedback class StringFeedback, which
-   is reported in the StringFeedbackState structure. The members
-   of that structure are:
+Some input devices provide a means of displaying a string.
+Those devices will support feedback class StringFeedback, which
+is reported in the StringFeedbackState structure. The members
+of that structure are:
 
-                     CLASS String:
-                           [class: CARD8
-                            length: CARD16
-                            feedback id: CARD8
-                            max_symbols: CARD16
-                            num_keysyms_supported: CARD16
-                            keysyms_supported: LISTofKEYSYM]
+                  CLASS String:
+                        [class: CARD8
+                         length: CARD16
+                         feedback id: CARD8
+                         max_symbols: CARD16
+                         num_keysyms_supported: CARD16
+                         keysyms_supported: LISTofKEYSYM]
 
-   Some input devices contain a bell. Those devices will support
-   feedback class BellFeedback, which is reported in the
-   BellFeedbackState structure. The members of that structure are:
+Some input devices contain a bell. Those devices will support
+feedback class BellFeedback, which is reported in the
+BellFeedbackState structure. The members of that structure are:
 
-                     CLASS Bell:
-                           [class: CARD8
-                            length: CARD16
-                            feedback id: CARD8
-                            percent: CARD8
-                            pitch: CARD16
-                            duration: CARD16]
+                  CLASS Bell:
+                        [class: CARD8
+                         length: CARD16
+                         feedback id: CARD8
+                         percent: CARD8
+                         pitch: CARD16
+                         duration: CARD16]
 
-   The percent sets the base volume for the bell between 0 (off)
-   and 100 (loud) inclusive, if possible. Setting to -1 restores
-   the default. Other negative values generate a Value error.
+The percent sets the base volume for the bell between 0 (off)
+and 100 (loud) inclusive, if possible. Setting to -1 restores
+the default. Other negative values generate a Value error.
 
-   The pitch sets the pitch (specified in Hz) of the bell, if
-   possible. Setting to -1 restores the default. Other negative
-   values generate a Value error.
+The pitch sets the pitch (specified in Hz) of the bell, if
+possible. Setting to -1 restores the default. Other negative
+values generate a Value error.
 
-   The duration sets the duration (specified in milliseconds) of
-   the bell, if possible. Setting to -1 restores the default.
-   Other negative values generate a Value error.
+The duration sets the duration (specified in milliseconds) of
+the bell, if possible. Setting to -1 restores the default.
+Other negative values generate a Value error.
 
-   A bell generator connected with the console but not directly on
-   the device is treated as if it were part of the device. Some
-   input devices contain LEDs. Those devices will support feedback
-   class Led, which is reported in the LedFeedbackState structure.
-   The members of that structure are:
+A bell generator connected with the console but not directly on
+the device is treated as if it were part of the device. Some
+input devices contain LEDs. Those devices will support feedback
+class Led, which is reported in the LedFeedbackState structure.
+The members of that structure are:
 
-                     CLASS Led:
-                           [class: CARD8
-                            length: CARD16
-                            feedback id: CARD8
-                            led_mask: BITMASK
-                            led_value: BITMASK]
+                  CLASS Led:
+                        [class: CARD8
+                         length: CARD16
+                         feedback id: CARD8
+                         led_mask: BITMASK
+                         led_value: BITMASK]
 
-   Each bit in led_mask indicates that the corresponding led is
-   supported by the feedback. At most 32 LEDs per feedback are
-   supported. No standard interpretation of LEDs is defined.
+Each bit in led_mask indicates that the corresponding led is
+supported by the feedback. At most 32 LEDs per feedback are
+supported. No standard interpretation of LEDs is defined.
 
-   This function will fail with a BadMatch error if the device
-   specified in the request does not support feedbacks.
+This function will fail with a BadMatch error if the device
+specified in the request does not support feedbacks.
 
    Errors: Device, Match
 
-   To change the settings of a feedback on an extension device,
-   use ChangeFeedbackControl.
+To change the settings of a feedback on an extension device,
+use ChangeFeedbackControl.
 
-                   ChangeFeedbackControl
-                           device: DEVICE
-                           feedbackid: CARD8
-                           value-mask: BITMASK
-                           value: FEEDBACKCONTROL
-                           FEEDBACKCONTROL: {KBDFEEDBACKCONTROL,
-                                             PTRFEEDBACKCONTROL,
-                                             INTEGERFEEDBACKCONTROL,
-                                             STRINGFEEDBACKCONTROL,
-                                             BELLFEEDBACKCONTROL,
-                                             LEDFEEDBACKCONTROL}
+                ChangeFeedbackControl
+                        device: DEVICE
+                        feedbackid: CARD8
+                        value-mask: BITMASK
+                        value: FEEDBACKCONTROL
+                        FEEDBACKCONTROL: {KBDFEEDBACKCONTROL,
+                                          PTRFEEDBACKCONTROL,
+                                          INTEGERFEEDBACKCONTROL,
+                                          STRINGFEEDBACKCONTROL,
+                                          BELLFEEDBACKCONTROL,
+                                          LEDFEEDBACKCONTROL}
 
    Errors: Device, Match, Value
 
-   Feedback controls are grouped by class. Those feedbacks that
-   are equivalent to those supported by the core keyboard are
-   controlled by feedback class KbdFeedbackClass using the
-   KbdFeedbackControl structure. The members of that structure
-   are:
+Feedback controls are grouped by class. Those feedbacks that
+are equivalent to those supported by the core keyboard are
+controlled by feedback class KbdFeedbackClass using the
+KbdFeedbackControl structure. The members of that structure
+are:
 
-                   KBDFEEDBACKCTL
-                           [class: CARD8
-                            length: CARD16
-                            feedback id: CARD8
-                            key_click_percent: INT8
-                            bell_percent: INT8
-                            bell_pitch: INT16
-                            bell_duration: INT16
-                            led_mask: INT32
-                            led_value: INT32
-                            key: KEYCODE
-                            auto_repeat_mode: {AutoRepeatModeOn, AutoRepeatModeOff,
-                                               AutoRepeatModeDefault}]
+                KBDFEEDBACKCTL
+                        [class: CARD8
+                         length: CARD16
+                         feedback id: CARD8
+                         key_click_percent: INT8
+                         bell_percent: INT8
+                         bell_pitch: INT16
+                         bell_duration: INT16
+                         led_mask: INT32
+                         led_value: INT32
+                         key: KEYCODE
+                         auto_repeat_mode: {AutoRepeatModeOn, AutoRepeatModeOff,
+                                            AutoRepeatModeDefault}]
 
-   The key_click_percent sets the volume for key clicks between 0
-   (off) and 100 (loud) inclusive, if possible. Setting to -1
-   restores the default. Other negative values generate a Value
-   error.
+The key_click_percent sets the volume for key clicks between 0
+(off) and 100 (loud) inclusive, if possible. Setting to -1
+restores the default. Other negative values generate a Value
+error.
 
-   If both auto_repeat_mode and key are specified, then the
-   auto_repeat_mode of that key is changed, if possible. If only
-   auto_repeat_mode is specified, then the global auto-repeat mode
-   for the entire keyboard is changed, if possible, without
-   affecting the per-key settings. It is a Match error if a key is
-   specified without an auto_repeat_mode.
+If both auto_repeat_mode and key are specified, then the
+auto_repeat_mode of that key is changed, if possible. If only
+auto_repeat_mode is specified, then the global auto-repeat mode
+for the entire keyboard is changed, if possible, without
+affecting the per-key settings. It is a Match error if a key is
+specified without an auto_repeat_mode.
 
-   The order in which controls are verified and altered is
-   server-dependent. If an error is generated, a subset of the
-   controls may have been altered.
+The order in which controls are verified and altered is
+server-dependent. If an error is generated, a subset of the
+controls may have been altered.
 
-   Those feedback controls equivalent to those of the core pointer
-   are controlled by feedback class PtrFeedbackClass using the
-   PtrFeedbackControl structure. The members of that structure are
-   as follows:
+Those feedback controls equivalent to those of the core pointer
+are controlled by feedback class PtrFeedbackClass using the
+PtrFeedbackControl structure. The members of that structure are
+as follows:
 
-                   PTRFEEDBACKCTL:
-                           [class: CARD8
-                            length: CARD16
-                            feedback id: CARD8
-                            accelNumerator: INT16
-                            accelDenominator: INT16
-                            threshold: INT16]
+                PTRFEEDBACKCTL:
+                        [class: CARD8
+                         length: CARD16
+                         feedback id: CARD8
+                         accelNumerator: INT16
+                         accelDenominator: INT16
+                         threshold: INT16]
 
-   The acceleration, expressed as a fraction, is a multiplier for
-   movement. For example, specifying 3/1 means the device moves
-   three times as fast as normal. The fraction may be rounded
-   arbitrarily by the X server. Acceleration only takes effect if
-   the device moves more than threshold pixels at once and only
-   applies to the amount beyond the value in the threshold
-   argument. Setting a value to -1 restores the default. The
-   values of the do-accel and do-threshold arguments must be
-   nonzero for the device values to be set. Otherwise, the
-   parameters will be unchanged. Negative values generate a Value
-   error, as does a zero value for the accel-denominator argument.
+The acceleration, expressed as a fraction, is a multiplier for
+movement. For example, specifying 3/1 means the device moves
+three times as fast as normal. The fraction may be rounded
+arbitrarily by the X server. Acceleration only takes effect if
+the device moves more than threshold pixels at once and only
+applies to the amount beyond the value in the threshold
+argument. Setting a value to -1 restores the default. The
+values of the do-accel and do-threshold arguments must be
+nonzero for the device values to be set. Otherwise, the
+parameters will be unchanged. Negative values generate a Value
+error, as does a zero value for the accel-denominator argument.
 
-   Some devices are capable of displaying an integer. This is done
-   using feedback class IntegerFeedbackClass using the
-   IntegerFeedbackControl structure. The members of that structure
-   are as follows:
+Some devices are capable of displaying an integer. This is done
+using feedback class IntegerFeedbackClass using the
+IntegerFeedbackControl structure. The members of that structure
+are as follows:
 
-                   INTEGERCTL:
-                           [class: CARD8
-                            length: CARD16
-                            feedback id: CARD8
-                            int_to_display: INT32]
+                INTEGERCTL:
+                        [class: CARD8
+                         length: CARD16
+                         feedback id: CARD8
+                         int_to_display: INT32]
 
-   Some devices are capable of displaying a string. This is done
-   using feedback class StringFeedbackClass using the
-   StringFeedbackCtl structure. The members of that structure are
-   as follows:
+Some devices are capable of displaying a string. This is done
+using feedback class StringFeedbackClass using the
+StringFeedbackCtl structure. The members of that structure are
+as follows:
 
-                   STRINGCTL:
-                           [class: CARD8
-                            length: CARD16
-                            feedback id: CARD8
-                            syms_to_display: LISTofKEYSYMS]
+                STRINGCTL:
+                        [class: CARD8
+                         length: CARD16
+                         feedback id: CARD8
+                         syms_to_display: LISTofKEYSYMS]
 
-   Some devices contain a bell. This is done using feedback class
-   BellFeedbackClass using the BellFeedbackControl structure. The
-   members of that structure are as follows:
+Some devices contain a bell. This is done using feedback class
+BellFeedbackClass using the BellFeedbackControl structure. The
+members of that structure are as follows:
 
-                   BELLCTL:
-                           [class: CARD8
-                            length: CARD16
-                            feedback id: CARD8
-                            percent: INT8
-                            pitch: INT16
-                            duration: INT16]
+                BELLCTL:
+                        [class: CARD8
+                         length: CARD16
+                         feedback id: CARD8
+                         percent: INT8
+                         pitch: INT16
+                         duration: INT16]
 
-   Some devices contain leds. These can be turned on and off using
-   the LedFeedbackControl structure. The members of that structure
-   are as follows:
+Some devices contain leds. These can be turned on and off using
+the LedFeedbackControl structure. The members of that structure
+are as follows:
 
-                   LEDCTL:
-                           [class: CARD8
-                            length: CARD16
-                            feedback id: CARD8
-                            led_mask: BITMASK
-                            led_value: BITMASK]
+                LEDCTL:
+                        [class: CARD8
+                         length: CARD16
+                         feedback id: CARD8
+                         led_mask: BITMASK
+                         led_value: BITMASK]
 
    Errors: Device, Match, Value
 
 2.20 Ringing a Bell on an Input Device
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   To ring a bell on an extension input device, use DeviceBell.
+To ring a bell on an extension input device, use DeviceBell.
 
-                   DeviceBell:
-                           device: DEVICE
-                           feedbackclass: CARD8
-                           feedbackid: CARD8
-                           percent: INT8
+                DeviceBell:
+                        device: DEVICE
+                        feedbackclass: CARD8
+                        feedbackid: CARD8
+                        percent: INT8
 
    Errors: Device, Value
 
-   This request is analogous to the core Bell request. It rings
-   the specified bell on the specified input device feedback,
-   using the specified volume. The specified volume is relative to
-   the base volume for the feedback. If the value for the percent
-   argument is not in the range -100 to 100 inclusive, a Value
-   error results. The volume at which the bell rings when the
-   percent argument is nonnegative is:
+This request is analogous to the core Bell request. It rings
+the specified bell on the specified input device feedback,
+using the specified volume. The specified volume is relative to
+the base volume for the feedback. If the value for the percent
+argument is not in the range -100 to 100 inclusive, a Value
+error results. The volume at which the bell rings when the
+percent argument is nonnegative is:
 
-                   base - [(base * percent) / 100] + percent
+                base - [(base * percent) / 100] + percent
 
-   The volume at which the bell rings when the percent argument is
-   negative is:
+The volume at which the bell rings when the percent argument is
+negative is:
 
-                   base + [(base * percent) / 100]
+                base + [(base * percent) / 100]
 
-   To change the base volume of the bell, use
-   ChangeFeedbackControl request.
+To change the base volume of the bell, use
+ChangeFeedbackControl request.
 
 Controlling Device Encoding
 
-   To get the keyboard mapping of an extension device that has
-   keys, use GetDeviceKeyMapping.
+To get the keyboard mapping of an extension device that has
+keys, use GetDeviceKeyMapping.
 
-                   GetDeviceKeyMapping
-                           device: DEVICE
-                           first-keycode: KEYCODE
-                           count: CARD8
-                   =>
-                           keysyms-per-keycode: CARD8
-                           keysyms: LISTofKEYSYM
+                GetDeviceKeyMapping
+                        device: DEVICE
+                        first-keycode: KEYCODE
+                        count: CARD8
+                =>
+                        keysyms-per-keycode: CARD8
+                        keysyms: LISTofKEYSYM
 
    Errors: Device, Match, Value
 
-   This request returns the symbols for the specified number of
-   keycodes for the specified extension device, starting with the
-   specified keycode. The first-keycode must be greater than or
-   equal to min-keycode as returned in the connection setup (else
-   a Value error), and
+This request returns the symbols for the specified number of
+keycodes for the specified extension device, starting with the
+specified keycode. The first-keycode must be greater than or
+equal to min-keycode as returned in the connection setup (else
+a Value error), and
 
-                   first-keycode + count - 1
+                first-keycode + count - 1
 
-   must be less than or equal to max-keycode as returned in the
-   connection setup (else a Value error). The number of elements
-   in the keysyms list is
+must be less than or equal to max-keycode as returned in the
+connection setup (else a Value error). The number of elements
+in the keysyms list is
 
-                   count * keysyms-per-keycode
+                count * keysyms-per-keycode
 
-   and KEYSYM number N (counting from zero) for keycode K has an
-   index (counting from zero) of
+and KEYSYM number N (counting from zero) for keycode K has an
+index (counting from zero) of
 
-                   (K - first-keycode) * keysyms-per-keycode + N
+                (K - first-keycode) * keysyms-per-keycode + N
 
-   in keysyms. The keysyms-per-keycode value is chosen arbitrarily
-   by the server to be large enough to report all requested
-   symbols. A special KEYSYM value of NoSymbol is used to fill in
-   unused elements for individual keycodes.
+in keysyms. The keysyms-per-keycode value is chosen arbitrarily
+by the server to be large enough to report all requested
+symbols. A special KEYSYM value of NoSymbol is used to fill in
+unused elements for individual keycodes.
 
-   If the specified device has not first been opened by this
-   client via OpenDevice, or if that device does not support input
-   class Keys, this request will fail with a Device error.
+If the specified device has not first been opened by this
+client via OpenDevice, or if that device does not support input
+class Keys, this request will fail with a Device error.
 
-   To change the keyboard mapping of an extension device that has
-   keys, use ChangeDeviceKeyMapping.
+To change the keyboard mapping of an extension device that has
+keys, use ChangeDeviceKeyMapping.
 
-                   ChangeDeviceKeyMapping
-                           device: DEVICE
-                           first-keycode: KEYCODE
-                           keysyms-per-keycode: CARD8
-                           keysyms: LISTofKEYSYM
-                           num_codes: CARD8
+                ChangeDeviceKeyMapping
+                        device: DEVICE
+                        first-keycode: KEYCODE
+                        keysyms-per-keycode: CARD8
+                        keysyms: LISTofKEYSYM
+                        num_codes: CARD8
 
    Errors: Device, Match, Value, Alloc
 
-   This request is analogous to the core ChangeKeyMapping request.
-   It defines the symbols for the specified number of keycodes for
-   the specified extension device. If the specified device has not
-   first been opened by this client via OpenDevice, or if that
-   device does not support input class Keys, this request will
-   fail with a Device error.
+This request is analogous to the core ChangeKeyMapping request.
+It defines the symbols for the specified number of keycodes for
+the specified extension device. If the specified device has not
+first been opened by this client via OpenDevice, or if that
+device does not support input class Keys, this request will
+fail with a Device error.
 
-   The number of elements in the keysyms list must be a multiple
-   of keysyms_per_keycode. Otherwise, ChangeDeviceKeyMapping
-   generates a Length error. The specified first_keycode must be
-   greater than or equal to the min_keycode value returned by the
-   ListInputDevices request, or this request will fail with a
-   Value error. In addition, if the following expression is not
-   less than the max_keycode value returned by the
-   ListInputDevices request, the request will fail with a Value
-   error:
+The number of elements in the keysyms list must be a multiple
+of keysyms_per_keycode. Otherwise, ChangeDeviceKeyMapping
+generates a Length error. The specified first_keycode must be
+greater than or equal to the min_keycode value returned by the
+ListInputDevices request, or this request will fail with a
+Value error. In addition, if the following expression is not
+less than the max_keycode value returned by the
+ListInputDevices request, the request will fail with a Value
+error:
 
-                   first_keycode + (num_codes / keysyms_per_keycode) - 1
+                first_keycode + (num_codes / keysyms_per_keycode) - 1
 
-   To obtain the keycodes that are used as modifiers on an
-   extension device that has keys, use GetDeviceModifierMapping.
+To obtain the keycodes that are used as modifiers on an
+extension device that has keys, use GetDeviceModifierMapping.
 
-                   GetDeviceModifierMapping
-                           device: DEVICE
-                   =>
-                           keycodes-per-modifier: CARD8
-                           keycodes: LISTofKEYCODE
+                GetDeviceModifierMapping
+                        device: DEVICE
+                =>
+                        keycodes-per-modifier: CARD8
+                        keycodes: LISTofKEYCODE
 
    Errors: Device, Match
 
-   This request is analogous to the core GetModifierMapping
-   request. This request returns the keycodes of the keys being
-   used as modifiers. The number of keycodes in the list is
-   8*keycodes-per-modifier. The keycodes are divided into eight
-   sets, with each set containing keycodes-per-modifier elements.
-   The sets are assigned in order to the modifiers Shift, Lock,
-   Control, Mod1, Mod2, Mod3, Mod4, and Mod5. The
-   keycodes-per-modifier value is chosen arbitrarily by the
-   server; zeroes are used to fill in unused elements within each
-   set. If only zero values are given in a set, the use of the
-   corresponding modifier has been disabled. The order of keycodes
-   within each set is chosen arbitrarily by the server.
+This request is analogous to the core GetModifierMapping
+request. This request returns the keycodes of the keys being
+used as modifiers. The number of keycodes in the list is
+8*keycodes-per-modifier. The keycodes are divided into eight
+sets, with each set containing keycodes-per-modifier elements.
+The sets are assigned in order to the modifiers Shift, Lock,
+Control, Mod1, Mod2, Mod3, Mod4, and Mod5. The
+keycodes-per-modifier value is chosen arbitrarily by the
+server; zeroes are used to fill in unused elements within each
+set. If only zero values are given in a set, the use of the
+corresponding modifier has been disabled. The order of keycodes
+within each set is chosen arbitrarily by the server.
 
-   To set which keycodes that are to be used as modifiers for an
-   extension device, use SetDeviceModifierMapping.
+To set which keycodes that are to be used as modifiers for an
+extension device, use SetDeviceModifierMapping.
 
-                   SetDeviceModifierMapping
-                           device: DEVICE
-                           keycodes-per-modifier: CARD8
-                           keycodes: LISTofKEYCODE
-                   =>
-                           status: {Success, Busy, Failed}
+                SetDeviceModifierMapping
+                        device: DEVICE
+                        keycodes-per-modifier: CARD8
+                        keycodes: LISTofKEYCODE
+                =>
+                        status: {Success, Busy, Failed}
 
    Errors: Device, Match, Value, Alloc
 
-   This request is analogous to the core SetModifierMapping
-   request. This request specifies the keycodes (if any) of the
-   keys to be used as modifiers. The number of keycodes in the
-   list must be 8*keycodes-per-modifier (else a Length error). The
-   keycodes are divided into eight sets, with the sets, with each
-   set containing keycodes-per-modifier elements. The sets are
-   assigned in order to the modifiers Shift, Lock, Control, Mod1,
-   Mod2, Mod3, Mod4, and Mod5. Only non-zero keycode values are
-   used within each set; zero values are ignored. All of the
-   non-zero keycodes must be in the range specified by min-keycode
-   and max-keycode in the ListInputDevices request (else a Value
-   error). The order of keycodes within a set does not matter. If
-   no non-zero values are specified in a set, the use of the
-   corresponding modifier is disabled, and the modifier bit will
-   always be zero. Otherwise, the modifier bit will be one
-   whenever at least one of the keys in the corresponding set is
-   in the down position.
+This request is analogous to the core SetModifierMapping
+request. This request specifies the keycodes (if any) of the
+keys to be used as modifiers. The number of keycodes in the
+list must be 8*keycodes-per-modifier (else a Length error). The
+keycodes are divided into eight sets, with the sets, with each
+set containing keycodes-per-modifier elements. The sets are
+assigned in order to the modifiers Shift, Lock, Control, Mod1,
+Mod2, Mod3, Mod4, and Mod5. Only non-zero keycode values are
+used within each set; zero values are ignored. All of the
+non-zero keycodes must be in the range specified by min-keycode
+and max-keycode in the ListInputDevices request (else a Value
+error). The order of keycodes within a set does not matter. If
+no non-zero values are specified in a set, the use of the
+corresponding modifier is disabled, and the modifier bit will
+always be zero. Otherwise, the modifier bit will be one
+whenever at least one of the keys in the corresponding set is
+in the down position.
 
-   A server can impose restrictions on how modifiers can be
-   changed (for example, if certain keys do not generate up
-   transitions in hardware or if multiple keys per modifier are
-   not supported). If some such restriction is violated, the status
-   reply is MappingFailed, and none of the modifiers are changed.
+A server can impose restrictions on how modifiers can be
+changed (for example, if certain keys do not generate up
+transitions in hardware or if multiple keys per modifier are
+not supported). If some such restriction is violated, the status
+reply is MappingFailed, and none of the modifiers are changed.
 
-   If the new keycodes specified for a modifier differ from those
-   currently defined and any (current or new) keys for that
-   modifier are in the logically down state, the status reply is
-   MappingBusy, and none of the modifiers are changed.
+If the new keycodes specified for a modifier differ from those
+currently defined and any (current or new) keys for that
+modifier are in the logically down state, the status reply is
+MappingBusy, and none of the modifiers are changed.
 
-   This request generates a DeviceMappingNotify event on a Success
-   status. The DeviceMappingNotify event will be sent only to
-   those clients that have expressed an interest in receiving that
-   event via the XSelectExtensionEvent request.
+This request generates a DeviceMappingNotify event on a Success
+status. The DeviceMappingNotify event will be sent only to
+those clients that have expressed an interest in receiving that
+event via the XSelectExtensionEvent request.
 
 2.20 Controlling Button Mapping
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   These requests are analogous to the core GetPointerMapping and
-   ChangePointerMapping requests. They allow a client to determine
-   the current mapping of buttons on an extension device, and to
-   change that mapping.
+These requests are analogous to the core GetPointerMapping and
+ChangePointerMapping requests. They allow a client to determine
+the current mapping of buttons on an extension device, and to
+change that mapping.
 
-   To get the current button mapping for an extension device, use
-   GetDeviceButtonMapping.
+To get the current button mapping for an extension device, use
+GetDeviceButtonMapping.
 
-                   GetDeviceButtonMapping
-                           device: DEVICE
-                           nmap: CARD8
-                   =>
-                           map_return: LISTofCARD8
+                GetDeviceButtonMapping
+                        device: DEVICE
+                        nmap: CARD8
+                =>
+                        map_return: LISTofCARD8
 
    Errors: Device, Match
 
-   The GetDeviceButtonMapping function returns the current mapping
-   of the buttons on the specified device. Elements of the list
-   are indexed starting from one. The length of the list indicates
-   the number of physical buttons. The nominal mapping is the
-   identity mapping map[i]=i.
+The GetDeviceButtonMapping function returns the current mapping
+of the buttons on the specified device. Elements of the list
+are indexed starting from one. The length of the list indicates
+the number of physical buttons. The nominal mapping is the
+identity mapping map[i]=i.
 
-   nmap indicates the number of elements in the map_return array.
-   Only the first nmap entries will be copied by the library into
-   the map_return array.
+nmap indicates the number of elements in the map_return array.
+Only the first nmap entries will be copied by the library into
+the map_return array.
 
-   To set the button mapping for an extension device, use
-   SetDeviceButtonMapping.
+To set the button mapping for an extension device, use
+SetDeviceButtonMapping.
 
-                   SetDeviceButtonMapping
-                           device: DEVICE
-                           map: LISTofCARD8
-                           nmap: CARD8
-                   =>
-                           status: CARD8
+                SetDeviceButtonMapping
+                        device: DEVICE
+                        map: LISTofCARD8
+                        nmap: CARD8
+                =>
+                        status: CARD8
 
    Errors: Device, Match, Value
 
-   The SetDeviceButtonMapping function sets the mapping of the
-   specified device and causes the X server to generate a
-   DeviceMappingNotify event on a status of MappingSuccess.
-   Elements of the list are indexed starting from one. The length
-   of the list, specified in nmap, must be the same as
-   GetDeviceButtonMapping would return. Otherwise,
-   SetDeviceButtonMapping generates a Value error. A zero element
-   disables a button, and elements are not restricted in value by
-   the number of physical buttons. If any of the buttons to be
-   altered are in the down state, the status reply is MappingBusy
-   and the mapping is not changed.
+The SetDeviceButtonMapping function sets the mapping of the
+specified device and causes the X server to generate a
+DeviceMappingNotify event on a status of MappingSuccess.
+Elements of the list are indexed starting from one. The length
+of the list, specified in nmap, must be the same as
+GetDeviceButtonMapping would return. Otherwise,
+SetDeviceButtonMapping generates a Value error. A zero element
+disables a button, and elements are not restricted in value by
+the number of physical buttons. If any of the buttons to be
+altered are in the down state, the status reply is MappingBusy
+and the mapping is not changed.
 
-   In servers supporting XI 1.x, no two elements can have the same
-   nonzero value. Otherwise, this function generates a Value
-   error.
+In servers supporting XI 1.x, no two elements can have the same
+nonzero value. Otherwise, this function generates a Value
+error.
 
 2.21 Obtaining The State Of A Device
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   To obtain vectors that describe the state of the keys, buttons
-   and valuators of an extension device, use QueryDeviceState.
+To obtain vectors that describe the state of the keys, buttons
+and valuators of an extension device, use QueryDeviceState.
 
-                   QueryDeviceState
-                           device: DEVICE
-                   =>
-                           device-id: CARD8
-                           data: LISTofINPUTCLASS
+                QueryDeviceState
+                        device: DEVICE
+                =>
+                        device-id: CARD8
+                        data: LISTofINPUTCLASS
 
-   where
+where
 
-                   INPUTCLASS: {VALUATOR, BUTTON, KEY}
-                   CLASS VALUATOR:
-                               [class: CARD8
-                                num_valuators: CARD8
-                                mode: CARD8
-                                #x01 device mode (0 = Relative, 1 = Absolute)
-                                #x02 proximity state (0 = InProximity, 1 = OutOfProximity)
-                                valuators: LISTofINT32]
-                   CLASS BUTTON:
-                               [class: CARD8
-                                num_buttons: CARD8
-                                buttons: LISTofCARD8]
-                   CLASS KEY:
-                               [class: CARD8
-                                num_keys: CARD8
-                                keys: LISTofCARD8]
+                INPUTCLASS: {VALUATOR, BUTTON, KEY}
+                CLASS VALUATOR:
+                            [class: CARD8
+                             num_valuators: CARD8
+                             mode: CARD8
+                             #x01 device mode (0 = Relative, 1 = Absolute)
+                             #x02 proximity state (0 = InProximity, 1 = OutOfProximity)
+                             valuators: LISTofINT32]
+                CLASS BUTTON:
+                            [class: CARD8
+                             num_buttons: CARD8
+                             buttons: LISTofCARD8]
+                CLASS KEY:
+                            [class: CARD8
+                             num_keys: CARD8
+                             keys: LISTofCARD8]
 
    Errors: Device
 
-   The QueryDeviceState request returns the current logical state
-   of the buttons, keys, and valuators on the specified input
-   device. The buttons and keys arrays, byte N (from 0) contains
-   the bits for key or button 8N to 8N+7 with the least
-   significant bit in the byte representing key or button 8N.
+The QueryDeviceState request returns the current logical state
+of the buttons, keys, and valuators on the specified input
+device. The buttons and keys arrays, byte N (from 0) contains
+the bits for key or button 8N to 8N+7 with the least
+significant bit in the byte representing key or button 8N.
 
-   If the device has valuators, a bit in the mode field indicates
-   whether the device is reporting Absolute or Relative data. If
-   it is reporting Absolute data, the valuators array will contain
-   the current value of the valuators. If it is reporting Relative
-   data, the valuators array will contain undefined data.
+If the device has valuators, a bit in the mode field indicates
+whether the device is reporting Absolute or Relative data. If
+it is reporting Absolute data, the valuators array will contain
+the current value of the valuators. If it is reporting Relative
+data, the valuators array will contain undefined data.
 
-   If the device reports proximity information, a bit in the mode
-   field indicates whether the device is InProximity or
-   OutOfProximity.
+If the device reports proximity information, a bit in the mode
+field indicates whether the device is InProximity or
+OutOfProximity.
 
 2.22 Listing Device Properties
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   Introduced with XI 1.5
+Introduced with XI 1.5
 
-               ListDeviceProperties
-                        deviceid: CARD8
-               =>
-                        nAtoms: CARD16
-                        Atoms: LISTofATOM
+            ListDeviceProperties
+                     deviceid: CARD8
+            =>
+                     nAtoms: CARD16
+                     Atoms: LISTofATOM
 
    Errors: Device
 
-   Each device can store an arbitrary number of properties. These
-   properties can be allocated by either the client or the driver.
-   The client can change device properties and the server
-   guarantees that the device driver is notified about a change of
-   the device's properties.
+Each device can store an arbitrary number of properties. These
+properties can be allocated by either the client or the driver.
+The client can change device properties and the server
+guarantees that the device driver is notified about a change of
+the device's properties.
 
-   ListDeviceProperties returns all properties of a device. The
-   client is expected to retrieve details about the properties it
-   is interested in separately.
+ListDeviceProperties returns all properties of a device. The
+client is expected to retrieve details about the properties it
+is interested in separately.
 
 2.23 Getting a Device Property
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   Introduced with XI 1.5
+Introduced with XI 1.5
 
-               GetDeviceProperty:
-                        property: ATOM
-                        type: ATOM
-                        longOffset: CARD32
-                        longLength: CARD32
-                        deviceid: CARD8
-                        delete: BOOL
-               =>
-                        propertyType: ATOM
-                        bytesAfter: CARD32
-                        nItems: CARD32
-                        format: CARD8
-                        deviceid: CARD8
-                        data: [LISTofCARD8]
+            GetDeviceProperty:
+                     property: ATOM
+                     type: ATOM
+                     longOffset: CARD32
+                     longLength: CARD32
+                     deviceid: CARD8
+                     delete: BOOL
+            =>
+                     propertyType: ATOM
+                     bytesAfter: CARD32
+                     nItems: CARD32
+                     format: CARD8
+                     deviceid: CARD8
+                     data: [LISTofCARD8]
 
    Errors: Atom, Device, Value, Access
 
-   Retrieve the value for a property. If the property does not
-   exist, propertyType is None and all other fields are undefined.
+Retrieve the value for a property. If the property does not
+exist, propertyType is None and all other fields are undefined.
 
-   If type is not AnyPropertyType and does not match the
-   property's actual type, the propertyType, bytesAfter, and
-   format are returned but not the actual data.
+If type is not AnyPropertyType and does not match the
+property's actual type, the propertyType, bytesAfter, and
+format are returned but not the actual data.
 
-   longOffset and longLength specify the offset and length
-   respectively in 32-bit multiples of the data to retrieve.
+longOffset and longLength specify the offset and length
+respectively in 32-bit multiples of the data to retrieve.
 
-   If delete is True, the property is deleted after querying its
-   data. If the property cannot be deleted, a BadAccess error is
-   returned.
+If delete is True, the property is deleted after querying its
+data. If the property cannot be deleted, a BadAccess error is
+returned.
 
-   propertyType returns the atom identifier that defines the
-   actual type of the property.
+propertyType returns the atom identifier that defines the
+actual type of the property.
 
-   If bytesAfter is non-zero, it specifies the number of data
-   4-byte units after the retrieved chunk of data.
+If bytesAfter is non-zero, it specifies the number of data
+4-byte units after the retrieved chunk of data.
 
-   format specifies whether the data should be viewed as a list of
-   8-bit, 16-bit, or 32-bit quantities. Possible values are 8, 16,
-   and 32. This information allows the X server to correctly
-   perform byte-swap operations as necessary.
+format specifies whether the data should be viewed as a list of
+8-bit, 16-bit, or 32-bit quantities. Possible values are 8, 16,
+and 32. This information allows the X server to correctly
+perform byte-swap operations as necessary.
 
-   nItem specifies the number of 8-bit, 16-bit, or 32-bit items
-   returned after the request.
+nItem specifies the number of 8-bit, 16-bit, or 32-bit items
+returned after the request.
 
 2.24 Changing a Device Property
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   Introduced with XI 1.5
+Introduced with XI 1.5
 
-               ChangeDeviceProperty:
-                        property: ATOM
-                        type: ATOM
-                        deviceid: CARD8
-                        format: CARD8
-                        mode: CARD8
-                        nUnits: CARD32
+            ChangeDeviceProperty:
+                     property: ATOM
+                     type: ATOM
+                     deviceid: CARD8
+                     format: CARD8
+                     mode: CARD8
+                     nUnits: CARD32
 
    Errors: Atom, Device, Value, Match, Access
 
-   Changes the value of a specified property.
+Changes the value of a specified property.
 
-   The type specifies the atom identifier that defines the type of
-   the property. If mode is not PropModeReplace, the type must
-   match the current type of the property or a BadMatch error is
-   returned.
+The type specifies the atom identifier that defines the type of
+the property. If mode is not PropModeReplace, the type must
+match the current type of the property or a BadMatch error is
+returned.
 
-   format specifies whether the data should be viewed as a list of
-   8-bit, 16-bit, or 32-bit quantities. Possible values are 8, 16,
-   and 32. This information allows the X server to correctly
-   perform byte-swap operations as necessary.
+format specifies whether the data should be viewed as a list of
+8-bit, 16-bit, or 32-bit quantities. Possible values are 8, 16,
+and 32. This information allows the X server to correctly
+perform byte-swap operations as necessary.
 
-   If mode is PropModeReplace, a preexising value for this
-   property is replaced with the new value. If mode is
-   PropModePrepend or PropModeAppend, the value is prepended or
-   appended, respectively, to the current value of the property.
+If mode is PropModeReplace, a preexising value for this
+property is replaced with the new value. If mode is
+PropModePrepend or PropModeAppend, the value is prepended or
+appended, respectively, to the current value of the property.
 
-   nUnits specifies the number of 8-bit, 16-bit, or 32-bit items
-   supplied after the reply.
+nUnits specifies the number of 8-bit, 16-bit, or 32-bit items
+supplied after the reply.
 
-   Changing a device property results in a
-   DevicePropertyNotifyEvent being sent to all clients.
+Changing a device property results in a
+DevicePropertyNotifyEvent being sent to all clients.
 
 2.25 Deleting a Device Property
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   Introduced with XI 1.5
+Introduced with XI 1.5
 
-               DeleteDeviceProperty:
-                        property: ATOM
-                        deviceid: CARD8
+            DeleteDeviceProperty:
+                     property: ATOM
+                     deviceid: CARD8
 
    Errors: Atom, Device, Match, Access.
 
-   Deletes the specified property. If the property cannot be
-   deleted by the client, a BadAccess error is returned.
+Deletes the specified property. If the property cannot be
+deleted by the client, a BadAccess error is returned.
 
 3. Events
+---------
 
-   The input extension creates input events analogous to the core
-   input events. These extension input events are generated by
-   manipulating one of the extension input devices.
+The input extension creates input events analogous to the core
+input events. These extension input events are generated by
+manipulating one of the extension input devices.
 
 3.1 Button, Key, and Motion Events
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-               DeviceKeyPress
-               DeviceKeyRelease
-               DeviceButtonPress,
-               DeviceButtonRelease
-               DeviceMotionNotify
-                       device: CARD8
-                       root, event: WINDOW
-                       child: Window or None
-                       same-screen: BOOL
-                       root-x, root-y, event-x, event-y: INT16
-                       detail: 
-                       state: SETofKEYBUTMASK
-                       time: TIMESTAMP
+            DeviceKeyPress
+            DeviceKeyRelease
+            DeviceButtonPress,
+            DeviceButtonRelease
+            DeviceMotionNotify
+                    device: CARD8
+                    root, event: WINDOW
+                    child: Window or None
+                    same-screen: BOOL
+                    root-x, root-y, event-x, event-y: INT16
+                    detail: 
+                    state: SETofKEYBUTMASK
+                    time: TIMESTAMP
 
-   These events are generated when a key, button, or valuator
-   logically changes state. The generation of these logical
-   changes may lag the physical changes, if device event
-   processing is frozen. Note that DeviceKeyPress and
-   DeviceKeyRelease are generated for all keys, even those mapped
-   to modifier bits. The “source” of the event is the window the
-   pointer is in. The window with respect to which the event is
-   normally reported is found by looking up the hierarchy
-   (starting with the source window) for the first window on which
-   any client has selected interest in the event. The actual
-   window used for reporting can be modified by active grabs and
-   by the focus window.The window the event is reported with
-   respect to is called the “event” window.
+These events are generated when a key, button, or valuator
+logically changes state. The generation of these logical
+changes may lag the physical changes, if device event
+processing is frozen. Note that DeviceKeyPress and
+DeviceKeyRelease are generated for all keys, even those mapped
+to modifier bits. The “source” of the event is the window the
+pointer is in. The window with respect to which the event is
+normally reported is found by looking up the hierarchy
+(starting with the source window) for the first window on which
+any client has selected interest in the event. The actual
+window used for reporting can be modified by active grabs and
+by the focus window.The window the event is reported with
+respect to is called the “event” window.
 
-   The root is the root window of the “source” window, and root-x
-   and root-y are the pointer coordinates relative to root's
-   origin at the time of the event. Event is the “event” window.
-   If the event window is on the same screen as root, then event-x
-   and event-y are the pointer coordinates relative to the event
-   window's origin. Otherwise, event-x and event-y are zero. If
-   the source window is an inferior of the event window, then
-   child is set to the child of the event window that is an
-   ancestor of (or is) the source window. Otherwise, it is set to
-   None.
+The root is the root window of the “source” window, and root-x
+and root-y are the pointer coordinates relative to root's
+origin at the time of the event. Event is the “event” window.
+If the event window is on the same screen as root, then event-x
+and event-y are the pointer coordinates relative to the event
+window's origin. Otherwise, event-x and event-y are zero. If
+the source window is an inferior of the event window, then
+child is set to the child of the event window that is an
+ancestor of (or is) the source window. Otherwise, it is set to
+None.
 
-   The state component gives the logical state of the buttons on
-   the X pointer and modifier keys on the core X keyboard just
-   before the event.
+The state component gives the logical state of the buttons on
+the X pointer and modifier keys on the core X keyboard just
+before the event.
 
-   The detail component type varies with the event type:
-   Event               Component
-   DeviceKeyPress      KEYCODE
-   DeviceKeyRelease    KEYCODE
-   DeviceButtonPress   BUTTON
-   DeviceButtonRelease BUTTON
-   DeviceMotionNotify  { Normal , Hint }
+The detail component type varies with the event type:
+Event               Component
+DeviceKeyPress      KEYCODE
+DeviceKeyRelease    KEYCODE
+DeviceButtonPress   BUTTON
+DeviceButtonRelease BUTTON
+DeviceMotionNotify  { Normal , Hint }
 
-   The granularity of motion events is not guaranteed, but a
-   client selecting for motion events is guaranteed to get at
-   least one event when a valuator changes. If DeviceMotionHint is
-   selected, the server is free to send only one
-   DeviceMotionNotify event (with detail Hint) to the client for
-   the event window, until either a key or button changes state,
-   the pointer leaves the event window, or the client issues a
-   QueryDeviceState or GetDeviceMotionEvents request.
+The granularity of motion events is not guaranteed, but a
+client selecting for motion events is guaranteed to get at
+least one event when a valuator changes. If DeviceMotionHint is
+selected, the server is free to send only one
+DeviceMotionNotify event (with detail Hint) to the client for
+the event window, until either a key or button changes state,
+the pointer leaves the event window, or the client issues a
+QueryDeviceState or GetDeviceMotionEvents request.
 
 3.2 DeviceValuator Event
+~~~~~~~~~~~~~~~~~~~~~~~~
 
-                   DeviceValuator
-                           device: CARD8
-                           device_state: SETofKEYBUTMASK
-                           num_valuators: CARD8
-                           first_valuator: CARD8
-                           valuators: LISTofINT32
+                DeviceValuator
+                        device: CARD8
+                        device_state: SETofKEYBUTMASK
+                        num_valuators: CARD8
+                        first_valuator: CARD8
+                        valuators: LISTofINT32
 
-   DeviceValuator events are generated to contain valuator
-   information for which there is insufficient space in DeviceKey,
-   DeviceButton, DeviceMotion, and Proximity wire events. For
-   events of these types, a second event of type DeviceValuator
-   follows immediately. The library combines these events into a
-   single event that a client can receive via XNextEvent.
-   DeviceValuator events are not selected for by clients, they
-   only exist to contain information that will not fit into some
-   event selected by clients.
+DeviceValuator events are generated to contain valuator
+information for which there is insufficient space in DeviceKey,
+DeviceButton, DeviceMotion, and Proximity wire events. For
+events of these types, a second event of type DeviceValuator
+follows immediately. The library combines these events into a
+single event that a client can receive via XNextEvent.
+DeviceValuator events are not selected for by clients, they
+only exist to contain information that will not fit into some
+event selected by clients.
 
-   The device_state component gives the state of the buttons and
-   modifiers on the device generating the event.
+The device_state component gives the state of the buttons and
+modifiers on the device generating the event.
 
-   Extension motion devices may report motion data for a variable
-   number of axes. The valuators array contains the values of all
-   axes reported by the device. If more than 6 axes are reported,
-   more than one DeviceValuator event will be sent by the server,
-   and more than one DeviceKey, DeviceButton, DeviceMotion, or
-   Proximity event will be reported by the library. Clients should
-   examine the corresponding fields of the event reported by the
-   library to determine the total number of axes reported, and the
-   first axis reported in the current event. Axes are numbered
-   beginning with zero.
+Extension motion devices may report motion data for a variable
+number of axes. The valuators array contains the values of all
+axes reported by the device. If more than 6 axes are reported,
+more than one DeviceValuator event will be sent by the server,
+and more than one DeviceKey, DeviceButton, DeviceMotion, or
+Proximity event will be reported by the library. Clients should
+examine the corresponding fields of the event reported by the
+library to determine the total number of axes reported, and the
+first axis reported in the current event. Axes are numbered
+beginning with zero.
 
-   For Button, Key and Motion events on a device reporting
-   absolute motion data the current value of the device's
-   valuators is reported. For devices that report relative data,
-   Button and Key events may be followed by a DeviceValuator event
-   that contains 0s in the num_valuators field. In this case, only
-   the device_state component will have meaning.
+For Button, Key and Motion events on a device reporting
+absolute motion data the current value of the device's
+valuators is reported. For devices that report relative data,
+Button and Key events may be followed by a DeviceValuator event
+that contains 0s in the num_valuators field. In this case, only
+the device_state component will have meaning.
 
 3.3 Device Focus Events
+~~~~~~~~~~~~~~~~~~~~~~~
 
-                   DeviceFocusIn
-                   DeviceFocusOut
-                           device: CARD8
-                           time: TIMESTAMP
-                           event: WINDOW
-                           mode: { Normal, WhileGrabbed, Grab, Ungrab}
-                           detail: { Ancestor, Virtual, Inferior, Nonlinear,
-                                     NonlinearVirtual, Pointer, PointerRoot, None}
+                DeviceFocusIn
+                DeviceFocusOut
+                        device: CARD8
+                        time: TIMESTAMP
+                        event: WINDOW
+                        mode: { Normal, WhileGrabbed, Grab, Ungrab}
+                        detail: { Ancestor, Virtual, Inferior, Nonlinear,
+                                  NonlinearVirtual, Pointer, PointerRoot, None}
 
-   These events are generated when the input focus changes and are
-   reported to clients selecting DeviceFocusChange for the
-   specified device and window. Events generated by SetDeviceFocus
-   when the device is not grabbed have mode Normal. Events
-   generated by SetDeviceFocus when the device is grabbed have
-   mode WhileGrabbed. Events generated when a device grab activates
-   have mode Grab, and events generated when a device grab
-   deactivates have mode Ungrab.
+These events are generated when the input focus changes and are
+reported to clients selecting DeviceFocusChange for the
+specified device and window. Events generated by SetDeviceFocus
+when the device is not grabbed have mode Normal. Events
+generated by SetDeviceFocus when the device is grabbed have
+mode WhileGrabbed. Events generated when a device grab activates
+have mode Grab, and events generated when a device grab
+deactivates have mode Ungrab.
 
-   All DeviceFocusOut events caused by a window unmap are
-   generated after any UnmapNotify event, but the ordering of
-   DeviceFocusOut with respect to generated EnterNotify,
-   LeaveNotify, VisibilityNotify and Expose events is not
-   constrained.
+All DeviceFocusOut events caused by a window unmap are
+generated after any UnmapNotify event, but the ordering of
+DeviceFocusOut with respect to generated EnterNotify,
+LeaveNotify, VisibilityNotify and Expose events is not
+constrained.
 
-   DeviceFocusIn and DeviceFocusOut events are generated for focus
-   changes of extension devices in the same manner as focus events
-   for the core devices are generated.
+DeviceFocusIn and DeviceFocusOut events are generated for focus
+changes of extension devices in the same manner as focus events
+for the core devices are generated.
 
 3.4 Device State Notify Event
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-                   DeviceStateNotify
-                   time: TIMESTAMP
-                   device: CARD8
-                   num_keys: CARD8
-                   num_buttons: CARD8
-                   num_valuators: CARD8
-                   classes_reported: CARD8 {SetOfDeviceMode | SetOfInputClass}
-                       SetOfDeviceMode:
-                           #x80 ProximityState 0 = InProxmity, 1 = OutOfProximity
-                           #x40 Device Mode (0 = Relative, 1 = Absolute)
-                       SetOfInputClass: #x04 reporting valuators
-                           #x02 reporting buttons
-                           #x01 reporting keys
-                   buttons: LISTofCARD8
-                   keys: LISTofCARD8
-                   valuators: LISTofCARD32
+                DeviceStateNotify
+                time: TIMESTAMP
+                device: CARD8
+                num_keys: CARD8
+                num_buttons: CARD8
+                num_valuators: CARD8
+                classes_reported: CARD8 {SetOfDeviceMode | SetOfInputClass}
+                    SetOfDeviceMode:
+                        #x80 ProximityState 0 = InProxmity, 1 = OutOfProximity
+                        #x40 Device Mode (0 = Relative, 1 = Absolute)
+                    SetOfInputClass: #x04 reporting valuators
+                        #x02 reporting buttons
+                        #x01 reporting keys
+                buttons: LISTofCARD8
+                keys: LISTofCARD8
+                valuators: LISTofCARD32
 
-   This event reports the state of the device just as in the
-   QueryDeviceState request. This event is reported to clients
-   selecting DeviceStateNotify for the device and window and is
-   generated immediately after every EnterNotify and
-   DeviceFocusIn. If the device has no more than 32 buttons, no
-   more than 32 keys, and no more than 3 valuators, This event can
-   report the state of the device. If the device has more than 32
-   buttons, the event will be immediately followed by a
-   DeviceButtonStateNotify event. If the device has more than 32
-   keys, the event will be followed by a DeviceKeyStateNotify
-   event. If the device has more than 3 valuators, the event will
-   be followed by one or more DeviceValuator events.
+This event reports the state of the device just as in the
+QueryDeviceState request. This event is reported to clients
+selecting DeviceStateNotify for the device and window and is
+generated immediately after every EnterNotify and
+DeviceFocusIn. If the device has no more than 32 buttons, no
+more than 32 keys, and no more than 3 valuators, This event can
+report the state of the device. If the device has more than 32
+buttons, the event will be immediately followed by a
+DeviceButtonStateNotify event. If the device has more than 32
+keys, the event will be followed by a DeviceKeyStateNotify
+event. If the device has more than 3 valuators, the event will
+be followed by one or more DeviceValuator events.
 
 3.5 Device KeyState and ButtonState Notify Events
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-                   DeviceKeyStateNotify
-                           device: CARD8
-                           keys: LISTofCARD8
-                   DeviceButtonStateNotify
-                           device: CARD8
-                           buttons: LISTofCARD8
+                DeviceKeyStateNotify
+                        device: CARD8
+                        keys: LISTofCARD8
+                DeviceButtonStateNotify
+                        device: CARD8
+                        buttons: LISTofCARD8
 
-   These events contain information about the state of keys and
-   buttons on a device that will not fit into the
-   DeviceStateNotify wire event. These events are not selected by
-   clients, rather they may immediately follow a DeviceStateNotify
-   wire event and be combined with it into a single
-   DeviceStateNotify client event that a client may receive via
-   XNextEvent.
+These events contain information about the state of keys and
+buttons on a device that will not fit into the
+DeviceStateNotify wire event. These events are not selected by
+clients, rather they may immediately follow a DeviceStateNotify
+wire event and be combined with it into a single
+DeviceStateNotify client event that a client may receive via
+XNextEvent.
 
 3.6 DeviceMappingNotify Event
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-                   DeviceMappingNotify
-                           time: TIMESTAMP
-                           device: CARD8
-                           request: CARD8
-                           first_keycode: CARD8
-                           count: CARD8
+                DeviceMappingNotify
+                        time: TIMESTAMP
+                        device: CARD8
+                        request: CARD8
+                        first_keycode: CARD8
+                        count: CARD8
 
-   This event reports a change in the mapping of keys, modifiers,
-   or buttons on an extension device. This event is reported to
-   clients selecting DeviceMappingNotify for the device and window
-   and is generated after every client SetDeviceButtonMapping,
-   ChangeDeviceKeyMapping, or ChangeDeviceModifierMapping request.
+This event reports a change in the mapping of keys, modifiers,
+or buttons on an extension device. This event is reported to
+clients selecting DeviceMappingNotify for the device and window
+and is generated after every client SetDeviceButtonMapping,
+ChangeDeviceKeyMapping, or ChangeDeviceModifierMapping request.
 
 3.7 ChangeDeviceNotify Event
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-                   ChangeDeviceNotify
-                           device: CARD8
-                           time: TIMESTAMP
-                           request: CARD8
+                ChangeDeviceNotify
+                        device: CARD8
+                        time: TIMESTAMP
+                        request: CARD8
 
-   This event reports a change in the physical device being used
-   as the core X keyboard or X pointer device. ChangeDeviceNotify
-   events are reported to clients selecting ChangeDeviceNotify for
-   the device and window and is generated after every client
-   ChangeKeyboardDevice or ChangePointerDevice request.
+This event reports a change in the physical device being used
+as the core X keyboard or X pointer device. ChangeDeviceNotify
+events are reported to clients selecting ChangeDeviceNotify for
+the device and window and is generated after every client
+ChangeKeyboardDevice or ChangePointerDevice request.
 
 3.7 Proximity Events
+~~~~~~~~~~~~~~~~~~~~
 
-                   ProximityIn
-                   ProximityOut
-                           device: CARD8
-                           root, event: WINDOW
-                           child: Window or None
-                           same-screen: BOOL
-                           root-x, root-y, event-x, event-y: INT16
-                           state: SETofKEYBUTMASK
-                           time: TIMESTAMP
-                           device-state: SETofKEYBUTMASK
-                           axis-count: CARD8
-                           first-axis: CARD8
-                           axis-data: LISTofINT32
+                ProximityIn
+                ProximityOut
+                        device: CARD8
+                        root, event: WINDOW
+                        child: Window or None
+                        same-screen: BOOL
+                        root-x, root-y, event-x, event-y: INT16
+                        state: SETofKEYBUTMASK
+                        time: TIMESTAMP
+                        device-state: SETofKEYBUTMASK
+                        axis-count: CARD8
+                        first-axis: CARD8
+                        axis-data: LISTofINT32
 
-   These events are generated by some devices (such as graphics
-   tablets or touchscreens) to indicate that a stylus has moved
-   into or out of contact with a positional sensing surface.
+These events are generated by some devices (such as graphics
+tablets or touchscreens) to indicate that a stylus has moved
+into or out of contact with a positional sensing surface.
 
-   The “source” of the event is the window the pointer is in. The
-   window with respect to which the event is normally reported is
-   found by looking up the hierarchy (starting with the source
-   window) for the first window on which any client has selected
-   interest in the event. The actual window used for reporting can
-   be modified by active grabs and by the focus window.The window
-   the event is reported with respect to is called the “event”
-   window.
+The “source” of the event is the window the pointer is in. The
+window with respect to which the event is normally reported is
+found by looking up the hierarchy (starting with the source
+window) for the first window on which any client has selected
+interest in the event. The actual window used for reporting can
+be modified by active grabs and by the focus window.The window
+the event is reported with respect to is called the “event”
+window.
 
-   The root is the root window of the “source” window, and root-x
-   and root-y are the pointer coordinates relative to root's
-   origin at the time of the event. Event is the “event” window.
-   If the event window is on the same screen as root, then event-x
-   and event-y are the pointer coordinates relative to the event
-   window's origin. Otherwise, event-x and event-y are zero. If
-   the source window is an inferior of the event window, then
-   child is set to the child of the event window that is an
-   ancestor of (or is) the source window. Otherwise, it is set to
-   None. The state component gives the logical state of the
-   buttons on the core X pointer and modifier keys on the core X
-   keyboard just before the event. The device-state component
-   gives the state of the buttons and modifiers on the device
-   generating the event.
+The root is the root window of the “source” window, and root-x
+and root-y are the pointer coordinates relative to root's
+origin at the time of the event. Event is the “event” window.
+If the event window is on the same screen as root, then event-x
+and event-y are the pointer coordinates relative to the event
+window's origin. Otherwise, event-x and event-y are zero. If
+the source window is an inferior of the event window, then
+child is set to the child of the event window that is an
+ancestor of (or is) the source window. Otherwise, it is set to
+None. The state component gives the logical state of the
+buttons on the core X pointer and modifier keys on the core X
+keyboard just before the event. The device-state component
+gives the state of the buttons and modifiers on the device
+generating the event.
 
 3.8 DevicePresenceEvents
+~~~~~~~~~~~~~~~~~~~~~~~~
 
-   Introduced with XI 1.4.
+Introduced with XI 1.4.
 
-                   DevicePresence
-                           time: TIMESTAMP
-                           devchange: BYTE
-                               #x00: DeviceAdded
-                               #x01: DeviceRemoved
-                               #x02: DeviceEnabled
-                               #x03: DeviceDisabled
-                               #x04: DeviceUnrecoverable
-                               #x05: DeviceControlChanged
-                           deviceid: BYTE
-                           control: CARD16
+                DevicePresence
+                        time: TIMESTAMP
+                        devchange: BYTE
+                            #x00: DeviceAdded
+                            #x01: DeviceRemoved
+                            #x02: DeviceEnabled
+                            #x03: DeviceDisabled
+                            #x04: DeviceUnrecoverable
+                            #x05: DeviceControlChanged
+                        deviceid: BYTE
+                        control: CARD16
 
-   DevicePresence events are sent when the server adds or removes,
-   or enables or disables an input device. The client is expected
-   to query the server for the list of input devices using the
-   ListInputDevices request to obtain the updated list of input
-   devices. DevicePresence events are also sent when a control on
-   the device has been changed.
+DevicePresence events are sent when the server adds or removes,
+or enables or disables an input device. The client is expected
+to query the server for the list of input devices using the
+ListInputDevices request to obtain the updated list of input
+devices. DevicePresence events are also sent when a control on
+the device has been changed.
 
-   The devchange field specifies the type of operation. In case of
-   DeviceAdded, a new device has been added to the server, but
-   this device does not yet send events. If devchange is set to
-   DeviceEnabled, the device is enabled and will generate events.
-   If the field is DeviceDisabled or DeviceRemoved, the given
-   device is disabled and stops sending events or was removed from
-   the server, respectively. If the field is DeviceUnrecoverable,
-   an IO-error has occured on the device and the device is
-   forcibly disabled and removed by the server. If devchange is
-   DeviceControlChanged, control specifies the type of control
-   that has been changed.
+The devchange field specifies the type of operation. In case of
+DeviceAdded, a new device has been added to the server, but
+this device does not yet send events. If devchange is set to
+DeviceEnabled, the device is enabled and will generate events.
+If the field is DeviceDisabled or DeviceRemoved, the given
+device is disabled and stops sending events or was removed from
+the server, respectively. If the field is DeviceUnrecoverable,
+an IO-error has occured on the device and the device is
+forcibly disabled and removed by the server. If devchange is
+DeviceControlChanged, control specifies the type of control
+that has been changed.
 
 3.9 DevicePropertyNotifyEvent
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-   Introduced with XI 1.5.
+Introduced with XI 1.5.
 
-                   DevicePropertyNotifyEvent
-                           deviceid: CARD8
-                           state: CARD8
-                           time: TIMESTAMP
-                           atom: ATOM
+                DevicePropertyNotifyEvent
+                        deviceid: CARD8
+                        state: CARD8
+                        time: TIMESTAMP
+                        atom: ATOM
 
-   A DevicePropertyNotifyEvent is sent to all clients when a
-   property on the device is created, deleted, or changes value.
+A DevicePropertyNotifyEvent is sent to all clients when a
+property on the device is created, deleted, or changes value.
 
-   The deviceid specifies the device which's property has been
-   modified.
+The deviceid specifies the device which's property has been
+modified.
 
-   The atom specifies the named identifier of the property that
-   has been altered.
+The atom specifies the named identifier of the property that
+has been altered.
 
-   If state is PropertyNewValue, the given property has a new
-   value or has been newly created. If state is PropertyDeleted,
-   the given property has been deleted.
+If state is PropertyNewValue, the given property has a new
+value or has been newly created. If state is PropertyDeleted,
+the given property has been deleted.

From b1149ab782619eaeadf70affd94239184e082d03 Mon Sep 17 00:00:00 2001
From: Alexandre Julliard 
Date: Tue, 12 Apr 2011 22:39:25 +0200
Subject: [PATCH 241/388] 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 
Signed-off-by: Peter Hutterer 
---
 XI2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

From ca39f67c2aa5b255f2b85d7c649edff8295eed5e Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 8 Apr 2011 13:27:47 +1000
Subject: [PATCH 242/388] Put a #warning and #error in to avoid unsuspecting XI
 2.1 users.

The #warning directive is intentionally outside the define to disable the
error. Early adopters of the protocol can't see this warning often enough.

Signed-off-by: Peter Hutterer 
---
 XI2.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/XI2.h b/XI2.h
index 5ef8983..99e9d0d 100644
--- a/XI2.h
+++ b/XI2.h
@@ -25,6 +25,12 @@
 #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
+
 #define XI_2_Major                              2
 #define XI_2_Minor                              0
 #define XI_2_1_Minor                            1

From e19eaef83db9181787a13fa95d642971c33d559b Mon Sep 17 00:00:00 2001
From: Daniel Stone 
Date: Mon, 11 Apr 2011 10:09:57 +1000
Subject: [PATCH 243/388] Require configure flag to build this proto version.

Signed-off-by: Peter Hutterer 
---
 configure.ac | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/configure.ac b/configure.ac
index c755917..d3e2bc2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -11,6 +11,14 @@ XORG_DEFAULT_OPTIONS
 XORG_ENABLE_SPECS
 XORG_WITH_ASCIIDOC(8.4.5)
 
+AC_ARG_ENABLE(unstable-protocol,
+              AS_HELP_STRING([--enable-unstable-protocol],
+                             [Enables compilation of yet-to-be-finalised protocol (default: disabled)]),
+              [UNSTABLE_PROTO=$enableval], [UNSTABLE_PROTO=no])
+if ! test "x$UNSTABLE_PROTO" = xyes; then
+    AC_MSG_ERROR([This branch contains protocol elements which have not yet been finalised.  When this branch is updated, you will probably need to recompile both the server, libXi, and input-using clients, and may experience crashes or undefined behaviour if you do not.])
+fi
+
 AC_OUTPUT([Makefile
            specs/Makefile
            inputproto.pc])

From b46a3bafd95f1bb507e4851aaa6967cf20c4eb8e Mon Sep 17 00:00:00 2001
From: Daniel Stone 
Date: Fri, 22 Apr 2011 14:27:06 +0100
Subject: [PATCH 244/388] Formatting fixups and minor rewording

No semantic changes.

Signed-off-by: Daniel Stone 
---
 specs/XI2proto.txt | 278 ++++++++++++++++++++++++---------------------
 1 file changed, 146 insertions(+), 132 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 248e45e..26c1d12 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1,25 +1,24 @@
 The X Input Extension
 =====================
+:toc:
+:numbered:
 
-                                Version 2.0
-                                Version 2.1
+Authors:
 
-                              Peter Hutterer
-                         peter.hutterer@redhat.com
-                               Red Hat, Inc.
+- Peter Hutterer (Red Hat) 
+- Daniel Stone (Collabora Ltd.) 
+- Chase Douglas (Canonical, Ltd.) 
 
-                               Daniel Stone
-                           daniel@fooishbar.org
-                              Collabora, Ltd.
+[[history]]
+History 
+-------
 
-                              Chase Douglas
-                        chase.douglas@canonical.com
-                              Canonical, Ltd.
+- v2.1, ?? 2011: Multitouch support added
+- v2.0, October 2009: Initial release of XI2 protocol
 
-
-
-1. Introduction
----------------
+[[intro-xi20]]
+Introduction
+------------
 
 The X Input Extension version 2.0 (XI2) is the second major release of the X
 Input Extension.
@@ -43,89 +42,54 @@ 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).
 
-1.1 X Input Extension version 2.1 (XI 2.1)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[intro-xi21]]
+X Input Extension version 2.1 (XI 2.1)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 XI 2.1 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 multiple independent input points per physical device.
-Furthermore, as such devices are often direct input devices (e.g. touchscreens,
-able to focus without a pointer), the virtual abstraction of master devices is
-not always necessary.
+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.1 aim to:
 
 - support a dynamic number of simultaneous touch points,
 - support devices that are both multi-touch and traditional pointer devices,
-- while supporting pre-XI2.1 clients through emulation of XInput and core
+- allow touchpoints to be either grouped together or handled separately,
+- while supporting pre-XI2.1 clients through emulation of XI2.0/XI1.x and core
   pointer events.
 
 XI 2.1 caters for two modes of touch input devices:
 
-- direct multi-touch input devices such as touch screens. These devices
-  provide independent touchpoints that can occur anywhere on the screen and
-  are usually the result of direct touch interaction.
-- indirect touch input devices such as multi-touch trackpads. These devices
-  provide independent touchpoints that may need to be interpreted
-  relative to the current position of the pointer on that same device. Such
-  interactions are usually the result of a gesture performed on the device.
+- '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.
+- 'indirect' 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.
 
-A device may change its touch mode at runtime. Clients are informed which
-type of touch device they are dealing with. See XIQueryDevice for more
-information.
+Touch events are only available to clients supporting version 2.1 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.1 touch events to support older clients; see the
+<> section.
 
-Touch device support is only available to clients supporting version 2.1 or
-later of the X Input Extension. Clients must use the XIQueryVersion request to
-announce support of this version.
 
-XI 2.1 requires devices to track touch points over time. Devices that cannot
-do so in hardware must employ software trackers to be usable with XI 2.1.
-
-//                            ❧❧❧❧❧❧❧❧❧❧❧
-
-2. 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 }
-
-//                            ❧❧❧❧❧❧❧❧❧❧❧
-
-3. Interoperability between version 1.x and 2.0
------------------------------------------------
+[[interop-xi1]]
+Interoperability between version 1.x and 2.0
+--------------------------------------------
 
 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.
@@ -139,8 +103,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.
@@ -148,24 +113,26 @@ 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.
 
-//                            ❧❧❧❧❧❧❧❧❧❧❧
 
-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
@@ -177,8 +144,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
@@ -196,8 +164,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,
 
@@ -216,8 +185,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 specfy which pointer).
@@ -237,8 +207,9 @@ 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.
 
-5 Touch device support
-----------------------
+[[multitouch]]
+Touch device support
+--------------------
 
 Touch event processing differs from normal event processing in a few ways,
 most notably in that touch events are processed partially out-of-band from
@@ -246,8 +217,9 @@ pointer and keyboard events (see section 4.4.5) and in that
 touch events may be sent to multiple clients simultaneously (see sections
 5.1.1 and 5.1.2).
 
-5.1 Touch event sequences
-~~~~~~~~~~~~~~~~~~~~~~~~~
+[[multitouch-lifecycle]]
+Touch event sequences
+~~~~~~~~~~~~~~~~~~~~~
 
 Touch input follows a three-stage cycle:
 
@@ -299,8 +271,9 @@ If the touch sequence ends while the client is the owner of the touch
 sequence, the client receives a TouchEnd event. The client must accept or
 reject the sequence nonetheless.
 
-5.1.1 Ownership of touch sequences
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+[[multitouch-ownership]]
+Ownership of touch sequences
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Clients may opt for touch events to be delivered before they become the
 owner of the touch sequence. In this case, the logical state state of the
@@ -336,8 +309,9 @@ the current owner rejects the sequence, the client may become
 the owner of the touch sequence and receive a TouchOwnership event and a
 TouchEndEvent.
 
-5.1.2 Observing touch sequences
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+[[multitouch-observer]]
+Observing touch sequences
+^^^^^^^^^^^^^^^^^^^^^^^^^
 A client that is the current owner of the sequence and rejects the sequence
 with TouchObserve will not be sent a TouchEnd event immediately. Instead,
 this client continues to receive touch events as they occur on the device.
@@ -367,8 +341,9 @@ on any windows for touch events for the slave device ID will be canceled.
 Clients selecting for individual slave devices are suggested to select for
 HierarchyChanged events to be notified when this occurs.
 
-5.2 Touch device modes
-~~~~~~~~~~~~~~~~~~~~~~
+[[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:
@@ -399,12 +374,14 @@ SemiMultitouch:
     Although DirectTouch and IndependentPointer devices may also be
     SemiMultitouch devices, such devices are not allowed through this protocol.
 
-A device is identified as only one of the device modes above at any time. For
-the purposes of this protocol document, indirect touch devices refers to
-DependentTouch, IndependentPointer, and SemiMultitouch devices.
+A device is identified as only one of the device modes above at any time, and
+the touch mode may change at any time. For the purposes of this protocol
+document, indirect touch devices refers to DependentTouch, IndependentPointer,
+and SemiMultitouch devices.
 
-5.3 Touch event delivery
-~~~~~~~~~~~~~~~~~~~~~~~~
+[[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 child in which the touch sequence
@@ -426,8 +403,9 @@ FIXME:
     events. [incorrect, remove it? why would it matter]
 
 
-5.3.1 Pointer event handling for indirect touch devices
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+[[multitouch-emulation-indirect]]
+Pointer event handling for indirect touch devices
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Indirect touch devices are expected to generate pointer events and no
 pointer emulation is performed. However, the pointer event may be generate
@@ -446,8 +424,9 @@ touches that have changed position or properties since the touch began. No event
 will be delivered for touches that began and ended while touch events were
 withheld.
 
-5.3.2 Pointer emulation for direct touch devices
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+[[multitouch-emulation-direct]]
+Pointer emulation for direct touch devices
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Touch sequences from direct touch devices may emulation pointer events. Only
 one touch sequence from a device may emulate pointer events at a time. Which
@@ -509,10 +488,44 @@ FIXME
     have the PointerEmulated flag set.
   huh? we never get both events anyway
 
-//                            ❧❧❧❧❧❧❧❧❧❧❧
 
-5. Data types
--------------
+[[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).
@@ -552,20 +565,20 @@ FIXME
             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
@@ -575,8 +588,9 @@ 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
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
     ┌───
         XIQueryVersion
@@ -776,7 +790,7 @@ client. If no min and max information is available, both must be 0.
     sourceid
         The device this class originates from.
     mode
-        The device type of the touch device.
+        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
@@ -1804,8 +1818,9 @@ also occur if an invalid value is given for event_mode.  Any flags not
 understood by the server will be ignored.
 
 
-8. Events:
-----------
+[[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
@@ -2250,10 +2265,11 @@ is now the owner of the touch sequence specified by touchid.
         A bitmask of flags for this event.
 
 
-//                            ❧❧❧❧❧❧❧❧❧❧❧
-
-Appendix A: XI 2.1 Use-cases
-----------------------------
+// FIXME: why do we get '11. Appendix A:' rather than just 'Appendix A:'?!
+[[xi21-usecases]]
+[appendix]
+XI 2.1 Use-cases
+----------------
 
 All use-cases that include the receiving and processing of touch events
 require the client to announce XI 2.1 support in the XIQueryVersion request.
@@ -2328,5 +2344,3 @@ 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.
-
-//                            ❧❧❧❧❧❧❧❧❧❧❧

From 3a89a5a3003309f810c9273fac8cf5943238df28 Mon Sep 17 00:00:00 2001
From: Daniel Stone 
Date: Fri, 22 Apr 2011 15:31:52 +0100
Subject: [PATCH 245/388] Doc note: No seriously, this is WIP

Signed-off-by: Daniel Stone 
---
 specs/XI2proto.txt | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 26c1d12..bc20811 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -3,6 +3,20 @@ The X Input Extension
 :toc:
 :numbered:
 
+.This is a work in progress!
+*****************************************************************************
+While XI 2.0 is final and widely deployed, XI 2.1 is still a work in progress;
+the protocol is not final and is subject to change at any time. While testing
+and feedback is strongly encouraged and very much welcome, please be aware that
+any part of the XI 2.1 additions may change from underneath you. We strongly
+recommend against deploying it in production for this reason.
+
+Developing against XI 2.1 requires passing the --enable-unstable-protocol
+argument when building inputproto, and additionally defining
+XINPUT2_1_USE_UNSTABLE_PROTOCOL when building your applications. I'm sure you
+get the point by now, so I promise not to mention it again.
+*****************************************************************************
+
 Authors:
 
 - Peter Hutterer (Red Hat) 

From a500bc990ba61bf32637114d1840db7147a0deaa Mon Sep 17 00:00:00 2001
From: Daniel Stone 
Date: Fri, 22 Apr 2011 15:42:09 +0100
Subject: [PATCH 246/388] Add inline references, fix usecase bulleting

Replace 'see section x.y.z' with better inline links; fix nested
bulleting of XI 2.1 usecases.

Signed-off-by: Daniel Stone 
---
 specs/XI2proto.txt | 149 ++++++++++++++++++++++-----------------------
 1 file changed, 72 insertions(+), 77 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index bc20811..58c5d44 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -131,10 +131,10 @@ respectively.
 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 (see the
+<> section). 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.
 
 
 [[hierachy]]
@@ -225,11 +225,11 @@ ClientPointer to a different master pointer.
 Touch device support
 --------------------
 
-Touch event processing differs from normal event processing in a few ways,
-most notably in that touch events are processed partially out-of-band from
-pointer and keyboard events (see section 4.4.5) and in that
-touch events may be sent to multiple clients simultaneously (see sections
-5.1.1 and 5.1.2).
+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; the
+<> section has more details.
 
 [[multitouch-lifecycle]]
 Touch event sequences
@@ -1065,8 +1065,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
+<>.
 
     num_changes
         The number of changes to apply to the current hierarchy.
@@ -1487,8 +1487,9 @@ on the specified input device.
             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.
-            Must be Asynchronous for GrabtypeTouchBegin and
-            GrabtypeTouchObserve (see section 4.4).
+            Must be Asynchronous for
+            <> and
+            <>.
         mask_len
             Length of mask in 4 byte units.
         mask
@@ -1549,7 +1550,7 @@ device is actively grabbed if:
           does not exist on an ancestor of grab_window.
 
 Or if grab_type is GrabtypeTouchBegin or GrabtypeTouchObserve, a
-touch grab (see section 4.4) begins if:
+touch grab begins if:
 
 - a touch begins in grab_window or one of its ancestors, and
 - the specified modifier keys are down
@@ -2288,73 +2289,67 @@ XI 2.1 Use-cases
 All use-cases that include the receiving and processing of touch events
 require the client to announce XI 2.1 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 a touch 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 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 a touch 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 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 a touch 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 XIAllowTouchEvents with the XITouchAccept flag set;
-      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.
-    - When the touch physically ceases, a TouchEnd event is sent to C.
+** 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 a touch 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 XIAllowTouchEvents with the XITouchAccept flag set; 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.
+** 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
+* 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 be 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.
+** 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 be 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 and a TouchAxisClass for
-      each axis available on 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.
+*  Driver DRV provides touch support from tracked device D:
+** DRV initializes a TouchClass for the device and a TouchAxisClass for each
+   axis available on 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.

From 416f077d8747d3d96dd5a71600e1e394226c3dc1 Mon Sep 17 00:00:00 2001
From: Daniel Stone 
Date: Fri, 22 Apr 2011 16:14:54 +0100
Subject: [PATCH 247/388] Add FIXME sidebars, remove single-grab stipulation

Add very visible FIXME sections to more clearly mark what's broken; also
remove the stipulation that only one grab may be active at a time.

Signed-off-by: Daniel Stone 
---
 specs/XI2proto.txt | 54 ++++++++++++++++++++++++++--------------------
 1 file changed, 31 insertions(+), 23 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 58c5d44..e66b614 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -339,21 +339,16 @@ touch sequence ceases on the device, even if the current owner of the
 sequence accepts the sequence.
 
 
-FIXME:
+
+**************************************************************************
+[red yellow-background]*FIXME*
+
 - can we have more than one TouchObserve on a device/window combination
   then?
 - it's impossible to observe and still become the owner
 - having GrabtypeTouchObserve seems rather broken. if all we want to do is
   observe, then why not use RawEvents or something similar?
-
-FIXME:
-Only one client may select, and only one client may grab, touch events for a
-physical device on a window. As an example, selecting for AllDevices will
-protocollkrevent any other client from selecting for touch events for any device on the
-same window. When a slave device is attached to a master device, any selections
-on any windows for touch events for the slave device ID will be canceled.
-Clients selecting for individual slave devices are suggested to select for
-HierarchyChanged events to be notified when this occurs.
+**************************************************************************
 
 [[multitouch-device-modes]]
 Touch device modes
@@ -411,10 +406,15 @@ 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.
 
-FIXME:
-    No touches from an indirect device may begin while the device is
-    floating, as it does not have an associated pointer position to focus
-    events. [incorrect, remove it? why would it matter]
+**************************************************************************
+[red yellow-background]*FIXME*
+
+No touches from an indirect device may begin while the device is
+floating, as it does not have an associated pointer position to focus
+events.
+
+incorrect, remove it? why would it matter?
+**************************************************************************
 
 
 [[multitouch-emulation-indirect]]
@@ -446,11 +446,15 @@ Touch sequences from direct touch devices may emulation 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.
 
-FIXME:
-    Pointer emulation events will only be delivered through the attached
-    master device; no pointer events will be emulated for floating touch
-    devices.
-  why?
+**************************************************************************
+[red yellow-background]*FIXME*
+
+Pointer emulation events will only be delivered through the attached
+master device; no pointer events will be emulated for floating touch
+devices.
+
+why?
+**************************************************************************
 
 Pointer events are emulated as follows:
 
@@ -497,10 +501,14 @@ in the window set has been reached, the event is delivered
 This sequence is repeated from the current window if the current owner of
 the sequence rejects the sequence.
 
-FIXME
-    Both the emulated pointer events and their associated touch events will
-    have the PointerEmulated flag set.
-  huh? we never get both events anyway
+**************************************************************************
+[red yellow-background]*FIXME*
+
+Both the emulated pointer events and their associated touch events will
+have the PointerEmulated flag set.
+
+huh? we never get both events anyway.
+**************************************************************************
 
 
 [[glossary-notations]]

From 400365a9bfa9ab3eaaa0bec08e32023f54d04207 Mon Sep 17 00:00:00 2001
From: Daniel Stone 
Date: Tue, 26 Apr 2011 19:51:41 +0100
Subject: [PATCH 248/388] typo fix

Signed-off-by: Daniel Stone 
---
 specs/XI2proto.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index e66b614..e89f062 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -245,7 +245,7 @@ sequence by ceasing to touch the device.  Within this document, the term
 "touch sequence" is used to describe the above chain of events.
 In the protocol, the three stages are represented with the event
 types TouchBegin, TouchUpdate, and TouchEnd, respectively.
-A touch sequence always generates TouchBeing and TouchEnd events. It may
+A touch sequence always generates TouchBegin and TouchEnd events. It may
 generate TouchUpdate events.
 
 A client must select for TouchBegin, TouchUpdate, and TouchEnd events. A

From 75790691706447cecc9f7948ea55caba05dc0d7d Mon Sep 17 00:00:00 2001
From: Daniel Stone 
Date: Tue, 26 Apr 2011 20:30:13 +0100
Subject: [PATCH 249/388] Reword touch introduction, labels for all

Reword the introduction to the multitouch section to try to be a bit
clearer, and go on a mad section-labelling spree.

Signed-off-by: Daniel Stone 
---
 specs/XI2proto.txt | 101 +++++++++++++++++++++++++++++++++------------
 1 file changed, 74 insertions(+), 27 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index e89f062..7dd0f2a 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -244,38 +244,42 @@ 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.
 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. It may
-generate TouchUpdate events.
+types <>, <>, and
+<>, 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.
 
-A client must select for TouchBegin, TouchUpdate, and TouchEnd events. A
-TouchBegin event is sent to the client with the position information and
-properties of the touch when it began on the touch device.
-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
-affected by grabs. The event timestamp of touch events always represents the
-time the event occurred.
+When a touch starts, clients are sent a <> event
+detailing the position used to focus the event for delivery, 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.  The event timestamp of touch events always
+represents the time the event occurred.
 
-A TouchUpdate event is sent to the client whenever the position or any other
-property of the touch changes. Note that the server may compress multiple
-TouchUpdate events into one. If compression occurs, the TouchUpdate event
-represents the last state of the touch.
+Whenever the touch position or any other property of the touchpoint changes,
+a <> event is sent to the client with the
+updated information (usually new touch co-ordinates).
 
-A TouchEnd event is sent to the client when the touch ceases.
-
-Only one client may select for touch events from a device on a window.
+When the touch has physically ended, or a client will otherwise not receive
+any more events for a given touchpoint, a <> event
+will be sent.
 
 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. See XIPassiveGrabDevice for more information on passive
-grab activation. When a touch grab activates, the client whose grab
-activates becomes the “owner” of this touch sequence. For all other clients,
-the logical state of a device (as seen by means of the protocol) may now lag
-the physical state.
+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.
+See <> for more information on
+passive grab activation.
 
-The owner must either “accept” or "reject" the touch sequence. If a touch
-sequence is rejected, a TouchEnd event is sent to the owner. The touch
-sequence is then re-processed on the next window and a new passive grab may
+Once a grabbing client becomes the owner of a touch, it must either “accept” or
+"reject" the touch sequence using the
+<>. 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
+The touch sequence is then re-processed
+on the next window and a new passive grab may
 activate or the sequence may be delivered to the client with an event
 selection. The client who now receives the touch sequence becomes the new
 owner of the touch sequence. If a touch sequence is accepted, the touch
@@ -285,6 +289,10 @@ If the touch sequence ends while the client is the owner of the touch
 sequence, the client receives a TouchEnd event. The client must accept or
 reject the sequence nonetheless.
 
+Only one client may select for touch events from a given device on a window,
+although some overlapping selections (see the
+<>) are allowed.
+
 [[multitouch-ownership]]
 Ownership of touch sequences
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -614,6 +622,7 @@ are required to be 0.
 Requests introduced in version 2.0
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+[[requests-queryversion]]
     ┌───
         XIQueryVersion
         major_version:          CARD16
@@ -637,6 +646,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
@@ -846,6 +856,7 @@ two or more TouchAxisClasses. TouchAxisClasses and AxisClasses are not
 interchangable. A TouchAxisClass may only be part of a touch event,
 whereas an AxisClass may only be part of non-touch events.
 
+[[requests-selectevents]]
     ┌───
         XISelectEvents
             window:         Window
@@ -895,6 +906,7 @@ 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
@@ -918,6 +930,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
@@ -962,6 +975,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
@@ -1007,6 +1021,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
@@ -1038,6 +1053,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
@@ -1145,6 +1161,7 @@ selection will be canceled.
     deviceid
         Deviceid of the slave device.
 
+[[requests-setclientpointer]]
     ┌───
         XISetClientPointer
             win:             Window
@@ -1176,6 +1193,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
@@ -1197,6 +1215,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
@@ -1227,6 +1246,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
@@ -1236,6 +1256,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
@@ -1326,6 +1347,7 @@ This request fails and returns:
 
 To release a grab of a device, use XIUngrabDevice.
 
+[[requests-ungrabdevice]]
     ┌───
         XIUngrabDevice
             deviceid:        DEVICEID
@@ -1348,6 +1370,7 @@ 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
@@ -1442,6 +1465,7 @@ you pass to the event-mode argument:
         paired master device frozen by the client.
         AsyncPair has no effect if deviceid specifies a slave device.
 
+[[requests-passivegrabdevice]]
     ┌───
         XIPassiveGrabDevice
             deviceid:        DEVICE
@@ -1627,6 +1651,7 @@ 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
@@ -1658,6 +1683,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
@@ -1675,6 +1701,7 @@ List the properties associated with the given device.
         atoms
             All properties on the device.
 
+[[requests-changeproperty]]
     ┌───
         XIChangeProperty
             deviceid:        DEVICEID
@@ -1722,6 +1749,7 @@ property, use XIDeleteProperty.
 
 This request generates an XIPropertyEvent.
 
+[[requests-deleteproperty]]
     ┌───
         XIDeleteProperty
             deviceid:        DEVICEID
@@ -1738,6 +1766,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
@@ -1803,8 +1832,13 @@ 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-xi21]]
+Requests introduced in version 2.1
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+[[requests-allowtouchevents]]
     ┌───
-        XIAllowTouchEvents: (since XI 2.1)
+        XIAllowTouchEvents:
             deviceid:        DEVICEID
             touchid:         CARD32
             event_mode:      ALLOWTOUCHMODE
@@ -1905,6 +1939,11 @@ All events have a set of common fields specified as EVENTHEADER.
         Time in ms when the event occurred.
 
 
+[[events-xi20]]
+Events introduced in version 2.0
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+[[events-hierachyevent]]
     ┌───
         HierarchyEvent:
             EVENTHEADER
@@ -1952,6 +1991,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
@@ -1985,6 +2025,7 @@ master device, or by a physical device changing capabilities at runtime.
 
 For a detailed description of classes, see the XQueryDevice request.
 
+[[events-deviceevent]]
     ┌───
         DeviceEvent:
             EVENTHEADER
@@ -2135,6 +2176,7 @@ unique per each slave touch device.
 
 Touch events do not generate enter/leave events.
 
+[[events-rawevent]]
     ┌───
         RawEvent
             EVENTHEADER
@@ -2170,6 +2212,7 @@ that grabbed the device only.
     axisvalues_raw
         Untransformed valuator data in device-native resolution.
 
+[[events-enterleave]]
     ┌───
         Enter or Leave or FocusIn or FocusOut
             EVENTHEADER
@@ -2250,6 +2293,7 @@ zero if the device is a floating slave device.
     buttons
         Button state before the event.
 
+[[events-propertyevent]]
     ┌───
         XIPropertyEvent
             EVENTHEADER
@@ -2265,8 +2309,11 @@ modified by a client.
     what
         Specifies what has been changed.
      
-XI 2.1:
+[[events-xi21]]
+Events introduced in version 2.1
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+[[events-touchownershipevent]]
     ┌───
         TouchOwnershipEvent (since XI 2.1):
             EVENTHEADER

From 2d5294cb0b9dc641e0f8ef1ff5f2a1a1803a57ee Mon Sep 17 00:00:00 2001
From: Daniel Stone 
Date: Thu, 28 Apr 2011 12:02:43 +0100
Subject: [PATCH 250/388] Further cleanups and clarifications

Signed-off-by: Daniel Stone 
---
 specs/XI2proto.txt | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 7dd0f2a..bc23855 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -278,16 +278,15 @@ 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
-The touch sequence is then re-processed
-on the next window and a new passive grab may
-activate or the sequence may be delivered to the client with an event
-selection. The client who now receives the touch sequence becomes the new
-owner of the touch sequence. If a touch sequence is accepted, the touch
-sequence is exclusively delivered to the current owner.
+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.
 
 If the touch sequence ends while the client is the owner of the touch
-sequence, the client receives a TouchEnd event. The client must accept or
-reject the sequence nonetheless.
+sequence but has not accepted or rejected ownership, the client receives a
+TouchEnd event, but must still accept or reject the sequence nonetheless.
 
 Only one client may select for touch events from a given device on a window,
 although some overlapping selections (see the
@@ -298,11 +297,10 @@ Ownership of touch sequences
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Clients may opt for touch events to be delivered before they become the
-owner of the touch sequence. In this case, the logical state 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.
+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

From f17598c1beeadbc648588d192d2e7eb616019e2d Mon Sep 17 00:00:00 2001
From: Daniel Stone 
Date: Tue, 3 May 2011 17:21:34 +0100
Subject: [PATCH 251/388] Mostly typographical

Signed-off-by: Daniel Stone 
---
 specs/XI2proto.txt | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index bc23855..6bfbf98 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -249,28 +249,30 @@ types <>, <>, and
 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 <> event
+When a touch starts, clients are sent a <>
 detailing the position used to focus the event for delivery, 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.  The event timestamp of touch events always
-represents the time the event occurred.
+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 <> event is sent to the client with the
-updated information (usually new touch co-ordinates).
+a <> is sent to all clients listening
+to events for that touchpoint with the updated information (usually new touch
+co-ordinates).
 
 When the touch has physically ended, or a client will otherwise not receive
-any more events for a given touchpoint, a <> event
-will be sent.
+any more events for a given touchpoint, a <>
+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.
-See <> for more information on
-passive grab activation.
+See the <>
+documentation for more information on passive grab activation.
 
 Once a grabbing client becomes the owner of a touch, it must either “accept” or
 "reject" the touch sequence using the
@@ -345,7 +347,6 @@ touch sequence ceases on the device, even if the current owner of the
 sequence accepts the sequence.
 
 
-
 **************************************************************************
 [red yellow-background]*FIXME*
 
@@ -449,7 +450,7 @@ Pointer emulation for direct touch devices
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Touch sequences from direct touch devices may emulation pointer events. Only
-one touch sequence from a device may emulate pointer events at a time. Which
+one touch sequence from a device may emulate pointer events at a time; which
 touch sequence emulates pointer events is implementation dependent.
 
 **************************************************************************

From d331251884101c503c533e088bcace6b830b5a95 Mon Sep 17 00:00:00 2001
From: Daniel Stone 
Date: Tue, 3 May 2011 18:44:53 +0100
Subject: [PATCH 252/388] Clean up and reword multitouch ownership/emulation

Remove 'withheld' indirect section as well.

Signed-off-by: Daniel Stone 
---
 specs/XI2proto.txt | 129 ++++++++++++++++-----------------------------
 1 file changed, 46 insertions(+), 83 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 6bfbf98..0212a4a 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -270,10 +270,20 @@ 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.
-See the <>
+the client whose grab activates becomes the “owner” of this touch sequence,
+and must decide what to do with it, as per the
+<>.  See the
+<>
 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 (see the
+<>) are allowed.
+
+[[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
 <>. If a touch sequence is
@@ -284,19 +294,14 @@ 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.
+exclusively delivered to the owner from that point on.
 
-If the touch sequence ends while the client is the owner of the touch
-sequence but has not accepted or rejected ownership, the client receives a
-TouchEnd event, but must still accept or reject the sequence nonetheless.
-
-Only one client may select for touch events from a given device on a window,
-although some overlapping selections (see the
-<>) are allowed.
-
-[[multitouch-ownership]]
-Ownership of touch sequences
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+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.
 
 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
@@ -305,14 +310,14 @@ 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. 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.
+<> 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.
@@ -329,32 +334,15 @@ 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
-TouchEndEvent.
-
-[[multitouch-observer]]
-Observing touch sequences
-^^^^^^^^^^^^^^^^^^^^^^^^^
-A client that is the current owner of the sequence and rejects the sequence
-with TouchObserve will not be sent a TouchEnd event immediately. Instead,
-this client continues to receive touch events as they occur on the device.
-However, a client hat has rejected a touch sequence may not become the owner
-of this sequence again.
-
-A client who has a passive grab with grab type TouchObserve will receive
-touch events as they occur on the device. Such a client will not become the
-owner of this sequence. The client continues to receive events until the
-touch sequence ceases on the device, even if the current owner of the
-sequence accepts the sequence.
-
+TouchEnd event.
 
 **************************************************************************
 [red yellow-background]*FIXME*
 
-- can we have more than one TouchObserve on a device/window combination
-  then?
-- it's impossible to observe and still become the owner
-- having GrabtypeTouchObserve seems rather broken. if all we want to do is
-  observe, then why not use RawEvents or something similar?
+TouchPendingEnd -> TouchOwnership -> TouchEnd? so we send a TouchEnd event
+to the owner always, and only TouchPendingEnd to clients who don't yet
+own the touch?
+
 **************************************************************************
 
 [[multitouch-device-modes]]
@@ -400,17 +388,17 @@ Touch event delivery
 ~~~~~~~~~~~~~~~~~~~~
 
 For direct touch devices, the window set for event propagation is the set of
-windows from the root window to the child in which the touch sequence
-begins.
+windows from the root window to the topmost window lying at the co-ordinates
+of the touch.
 
 For indirect 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. An indirect device may only have one window set at a time. Any
-future touch sequence will use the same window set. The window set is
-cleared when all touch sequences on the device end.
+pointer. An indirect 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
+of the sequence. Modifications to the window hierarchy, new grabs or changed
 event selection do not affect the window set.
 
 **************************************************************************
@@ -424,30 +412,9 @@ incorrect, remove it? why would it matter?
 **************************************************************************
 
 
-[[multitouch-emulation-indirect]]
-Pointer event handling for indirect touch devices
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Indirect touch devices are expected to generate pointer events and no
-pointer emulation is performed. However, the pointer event may be generate
-in the driver by mapping one touch sequence to the pointer. In these cases,
-events for both the pointer and its associated touch sequence will have the
-PointerEmulated flag set.
-
-When the cursor of an attached master pointer of an indirect device leaves the
-window of a touch grab or selection, or when a client activates a pointer grab
-on either the master or slave device, touch begin and touch update events will
-be withheld. When the pointer re-enters the window or the pointer grab is
-deactivated, touch update events will be sent with updates to any touch
-positions and properties since the last touch event sent. Touch begin events for
-any new touches will also be sent, along with touch update events for new
-touches that have changed position or properties since the touch began. No events
-will be delivered for touches that began and ended while touch events were
-withheld.
-
-[[multitouch-emulation-direct]]
-Pointer emulation for direct touch devices
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+[[multitouch-emulation]]
+Pointer emulation from multitouch events
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Touch sequences from direct touch devices may emulation pointer events. Only
 one touch sequence from a device may emulate pointer events at a time; which
@@ -460,7 +427,7 @@ Pointer emulation events will only be delivered through the attached
 master device; no pointer events will be emulated for floating touch
 devices.
 
-why?
+what? why?
 **************************************************************************
 
 Pointer events are emulated as follows:
@@ -480,16 +447,13 @@ The touch sequences 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 any mode but ReplayPointer or ReplayDevice, or
-- the grab mode is synchronous and the device remains frozen as a result of
-  AllowEvents with mode SyncPointer or SyncDevice
+  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 event
-emulating pointer events is delivered
-
+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
@@ -498,8 +462,7 @@ emulating pointer events is delivered
   until a grab has been found,
 
 If no touch or pointer grab on any window was activated and the last window
-in the window set has been reached, the event is delivered
-
+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

From bef7648827a0696debdd629472a45508a30144b1 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 3 Jun 2011 15:13:12 +1000
Subject: [PATCH 253/388] 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 
Reviewed-by: Daniel Stone 
---
 XI2.h | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

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

From 2cd2adb7a454072954704e1a215df49ce9dac410 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 3 Jun 2011 15:56:21 +1000
Subject: [PATCH 254/388] 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 
Reviewed-by: Daniel Stone 
---
 XI2.h | 4 ++++
 1 file changed, 4 insertions(+)

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

From ee91dcda461513cdca45160df580841daa6f50e2 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Thu, 17 Mar 2011 16:29:08 +1000
Subject: [PATCH 255/388] specs: add a linebreak for asciidoc parsing

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 1 +
 1 file changed, 1 insertion(+)

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

From 2ba875f4f2907bb9735ee3317b7e07c5b9d1304b Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Tue, 2 Aug 2011 10:20:53 +1000
Subject: [PATCH 256/388] 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 
---
 XI2.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

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

From 343fd699457483d1572b5229874f8ce6460a9b2d Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Tue, 2 Aug 2011 15:22:15 -0700
Subject: [PATCH 257/388] Separate "XI2.x" into "XI 2.x" for readability

Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 0212a4a..9763d8a 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -71,7 +71,7 @@ The additions in XI 2.1 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-XI2.1 clients through emulation of XI2.0/XI1.x and core
+- while supporting pre-XI 2.1 clients through emulation of XI 2.0/XI 1.x and core
   pointer events.
 
 XI 2.1 caters for two modes of touch input devices:

From 3a2f149b33531d02fff8e46181ffdcfcecb0c8cb Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Tue, 2 Aug 2011 15:23:21 -0700
Subject: [PATCH 258/388] Yes, send TouchEnd to owner, TouchPendingEnd to other
 listeners

Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 9763d8a..b592cfe 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -336,15 +336,6 @@ 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.
 
-**************************************************************************
-[red yellow-background]*FIXME*
-
-TouchPendingEnd -> TouchOwnership -> TouchEnd? so we send a TouchEnd event
-to the owner always, and only TouchPendingEnd to clients who don't yet
-own the touch?
-
-**************************************************************************
-
 [[multitouch-device-modes]]
 Touch device modes
 ~~~~~~~~~~~~~~~~~~

From 45387042f8fa767dda610936557548adf76306c5 Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Tue, 2 Aug 2011 15:29:54 -0700
Subject: [PATCH 259/388] Update device type terminology

Remove IndepedentTouch and SemiMultitouch devices. These may be handled
in an implementation specific manner through the props array of ATOMs in
the touch class information.

Signed-off-by: Chase Douglas 
---
 XI2.h              |  2 --
 specs/XI2proto.txt | 37 +++++++++++--------------------------
 2 files changed, 11 insertions(+), 28 deletions(-)

diff --git a/XI2.h b/XI2.h
index e70defe..4b3c275 100644
--- a/XI2.h
+++ b/XI2.h
@@ -164,8 +164,6 @@
 /* Touch modes */
 #define XIDirectTouch                           1
 #define XIDependentTouch                        2
-#define XIIndependentPointer                    3
-#define XISemiMultitouch                        4
 
 /* 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 b592cfe..2fd3c45 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -76,11 +76,11 @@ The additions in XI 2.1 aim to:
 
 XI 2.1 caters for two modes of touch input devices:
 
-- 'direct' multi-touch input devices such as touchscreens. These 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.
-- 'indirect' touch input devices such as multi-touch trackpads and mice with
+- '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
@@ -354,25 +354,8 @@ DependentTouch:
     location of the device's cursor. An Example of a DependentTouch device is a
     trackpad.
 
-IndependentPointer:
-    These devices do not have any correlation between touch events and pointer
-    events. Pointer events are generated by physical interactions with the
-    device that are independent of any touch events. An example of an
-    IndependentPointer device is a mouse with a touch surface used for scrolling
-    or other gestural input.
-
-SemiMultitouch:
-    These devices only report the number of touches and the bounding box of the
-    touches on the touch surface. The touch information is sent as one touch
-    event sequence with four touch valuators defining the bounding box. Touch
-    events are delivered according to the location of the device's cursor.
-    Although DirectTouch and IndependentPointer devices may also be
-    SemiMultitouch devices, such devices are not allowed through this protocol.
-
 A device is identified as only one of the device modes above at any time, and
-the touch mode may change at any time. For the purposes of this protocol
-document, indirect touch devices refers to DependentTouch, IndependentPointer,
-and SemiMultitouch devices.
+the touch mode may change at any time.
 
 [[multitouch-processing]]
 Touch event delivery
@@ -382,9 +365,9 @@ 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 indirect devices, the window set for event propagation is the set of
+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. An indirect device may only have one window set at a time, for all
+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.
 
@@ -395,7 +378,7 @@ event selection do not affect the window set.
 **************************************************************************
 [red yellow-background]*FIXME*
 
-No touches from an indirect device may begin while the device is
+No touches from a dependent device may begin while the device is
 floating, as it does not have an associated pointer position to focus
 events.
 
@@ -646,7 +629,8 @@ If major_version is less than 2, a BadValue error occurs.
                   length:               CARD16
                   sourceid:             CARD16
                   mode:                 TOUCHMODE
-                  num_touches:          CARD16 }
+                  num_touches:          CARD16
+                  props:                LISTofATOM }
 
     TOUCHAXISCLASS* {
                   type:                 TouchAxisClass
@@ -658,8 +642,7 @@ If major_version is less than 2, a BadValue error occurs.
                   max:                  FP3232
                   resolution:           CARD32 }
 
-    TOUCHMODE* { DirectTouch, DependentTouch, IndependentPointer,
-                 SemiMultitouch }
+    TOUCHMODE* { DirectTouch, DependentTouch }
 
 * since XI 2.1
 
@@ -780,6 +763,8 @@ client. If no min and max information is available, both must be 0.
         The maximum number of simultaneous touchpoints the device may send.
         If num_touches is 0, the number of supported touches is unknown or
         unlimited.
+    props
+        A list of properties to denote extra information about the device.
 
 A device with a TouchClass must provide one or more TOUCHAXISCLASS
 specifiers.

From 951cb8314343fcd5cdc392dfc78024fa184fc694 Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Tue, 2 Aug 2011 15:53:35 -0700
Subject: [PATCH 260/388] Prettyify touch device types

Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 2fd3c45..4432035 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -343,12 +343,12 @@ Touch device modes
 Touch devices come in many different forms with varying capabilities. The
 following device modes are defined for this protocol:
 
-DirectTouch:
+'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.
 
-DependentTouch:
+'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

From b15ad6e0dc1759e514c998eecd7e61b25308add6 Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Fri, 5 Aug 2011 13:59:05 -0700
Subject: [PATCH 261/388] Peter is right, floating devices can emit touch
 events

Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 4432035..3452428 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -375,16 +375,6 @@ 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.
 
-**************************************************************************
-[red yellow-background]*FIXME*
-
-No touches from a dependent device may begin while the device is
-floating, as it does not have an associated pointer position to focus
-events.
-
-incorrect, remove it? why would it matter?
-**************************************************************************
-
 
 [[multitouch-emulation]]
 Pointer emulation from multitouch events

From 3172e3c52eb45e4830d85ae53888d0b28c13df62 Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Fri, 5 Aug 2011 14:20:05 -0700
Subject: [PATCH 262/388] Fix up pointer event emulation section

* Wording cleanups for tense and to make some sentences flow better.
* Upon further review, it does seem to make more sense to deliver
  emulated pointer events through the same slave device rather than the
  master device. Thus, slave devices (including floating devices) may
  emit emulated pointer events.
* Peter is correct, it doesn't make sense to set the PointerEmulated
  flag on touch events.

Signed-off-by: Chase Douglas 
---
 XI2.h              |  3 +--
 specs/XI2proto.txt | 59 +++++++++++++++++-----------------------------
 2 files changed, 22 insertions(+), 40 deletions(-)

diff --git a/XI2.h b/XI2.h
index 4b3c275..4d8380f 100644
--- a/XI2.h
+++ b/XI2.h
@@ -158,8 +158,7 @@
 /* Device event flags (pointer events only) */
 #define XIPointerEmulated                       (1 << 16)
 /* Device event flags (touch events only) */
-#define XIPointerEmulated                       (1 << 16)
-#define XITouchPendingEnd                       (1 << 17)
+#define XITouchPendingEnd                       (1 << 16)
 
 /* Touch modes */
 #define XIDirectTouch                           1
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 3452428..fa8d14c 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -380,34 +380,26 @@ event selection do not affect the window set.
 Pointer emulation from multitouch events
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Touch sequences from direct touch devices may emulation 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.
-
-**************************************************************************
-[red yellow-background]*FIXME*
-
-Pointer emulation events will only be delivered through the attached
-master device; no pointer events will be emulated for floating touch
-devices.
-
-what? why?
-**************************************************************************
+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:
 
-- TouchBegin events generate a pointer motion event to the location of the
-  touch, followed by a button press event for button 1.
-- TouchUpdate events generate a pointer motion event to update the location
-  of the touch.
-- TouchEnd events generate a pointer motion event to the location of the touch
-  if the touch has moved, followed by a button release event for button 1.
+- 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.
+- 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.
 
 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 this touch sequence.
+owner of the touch sequence.
 
-The touch sequences is considered to have been accepted if
+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
@@ -419,31 +411,22 @@ 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
+  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 window in the window set as in the same order as
-  until a grab has been found,
+- 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 was activated and the last window
-in the window set has been reached, the event is delivered:
+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.
 
-This sequence is repeated from the current window if the current owner of
-the sequence rejects the sequence.
-
-**************************************************************************
-[red yellow-background]*FIXME*
-
-Both the emulated pointer events and their associated touch events will
-have the PointerEmulated flag set.
-
-huh? we never get both events anyway.
-**************************************************************************
-
+Emulated pointer events will have the PointerEmulated flag set.
 
 [[glossary-notations]]
 Notations used in this document

From b5e357c76dc5d8b2176fa470186688ec943d08e6 Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Fri, 5 Aug 2011 14:49:32 -0700
Subject: [PATCH 263/388] Remove touch "Observe" grabs

The semantics of these grabs doesn't work for all use cases. Raw touch
events will likely work better.

Signed-off-by: Chase Douglas 
---
 XI2.h              |  2 --
 specs/XI2proto.txt | 18 +++---------------
 2 files changed, 3 insertions(+), 17 deletions(-)

diff --git a/XI2.h b/XI2.h
index 4d8380f..31257d1 100644
--- a/XI2.h
+++ b/XI2.h
@@ -90,7 +90,6 @@
 #define XIGrabtypeEnter                         2
 #define XIGrabtypeFocusIn                       3
 #define XIGrabtypeTouchBegin                    4
-#define XIGrabtypeTouchObserve                  5
 
 /* Passive grab modifier */
 #define XIAnyModifier                           (1U << 31)
@@ -108,7 +107,6 @@
 /* XIAllowTouchEvents bitmask event-modes */
 #define XITouchAccept                           (1 << 0)
 #define XITouchReject                           (1 << 1)
-#define XITouchObserve                          (1 << 2)
 
 /* DeviceChangedEvent change reasons */
 #define XISlaveSwitch                           1
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index fa8d14c..964f7a4 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1397,8 +1397,7 @@ you pass to the event-mode argument:
     └───
 
         GRABTYPE         { GrabtypeButton, GrabtypeKeycode, GrabtypeEnter,
-                           GrabtypeFocusIn, GrabtypeTouchBegin,
-                           GrabtypeTouchObserve }
+                           GrabtypeFocusIn, GrabtypeTouchBegin }
 
         GRABMODIFIERINFO {   status:    Access
                              modifiers: CARD32 }
@@ -1430,9 +1429,6 @@ on the specified input device.
             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.
-            Must be Asynchronous for
-            <> and
-            <>.
         mask_len
             Length of mask in 4 byte units.
         mask
@@ -1492,15 +1488,13 @@ device is actively grabbed if:
         - a passive grab of the same grab_type + modifier combination does not
           does not exist on an ancestor of grab_window.
 
-Or if grab_type is GrabtypeTouchBegin or GrabtypeTouchObserve, a
-touch grab begins if:
+Or if grab_type is GrabtypeTouchBegin, a touch grab begins if:
 
 - a touch begins in grab_window or one of its ancestors, and
 - the specified modifier keys are down
 
 Ownership of the touch sequence is granted to the grabbing client if:
 
-- grab_type is not GrabtypeTouchObserve, and
 - 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.
@@ -1517,9 +1511,6 @@ 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.
-A GrabtypeTouchBegin grab is converted to a GrabtypeTouchObserve grab
-when the client uses XIAllowTouchEvents with mode TouchObserve.
-A GrabtypeTouchObserve grab is released when the touch sequence ends.
 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.
@@ -1756,7 +1747,7 @@ Requests introduced in version 2.1
             flags:           SETofALLOWTOUCHFLAGS
     └───
 
-    ALLOWTOUCHMODE  { TouchAccept, TouchReject, TouchObserve }
+    ALLOWTOUCHMODE  { TouchAccept, TouchReject }
     ALLOWTOUCHFLAGS (none currently defined)
 
 The XIAllowTouchEvents request allows the current owner of a touch
@@ -1774,9 +1765,6 @@ sequence to direct further delivery.
         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.
-        Given TouchObserve, the client is not interested in ownership, but
-        still wishes to receive TouchUpdate events; ownership will be passed on
-        to the next listener.
     flags
         A bitmask of applicable flags.
 

From 29cd8aac674b1d831814b48b2ee2f2f7ff16497b Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Fri, 5 Aug 2011 14:41:59 -0700
Subject: [PATCH 264/388] Use the same valuator axes for pointer and touch
 events

Signed-off-by: Chase Douglas 
---
 XI2proto.h         | 15 ----------
 specs/XI2proto.txt | 68 ++++++++++------------------------------------
 2 files changed, 14 insertions(+), 69 deletions(-)

diff --git a/XI2proto.h b/XI2proto.h
index a631335..6991fda 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -200,21 +200,6 @@ typedef struct {
     uint8_t     num_touches;    /**< Maximum number of touches (0==unlimited) */
 } xXITouchInfo;
 
-/**
- * Denotes a multitouch valuator capability on a device.
- * One XITouchValuatorInfo describes exactly one valuator (axis) on the device.
- */
-typedef struct {
-    uint16_t    type;           /**< Always TouchValuatorClass  */
-    uint16_t    length;         /**< Length in 4 byte units */
-    uint16_t    sourceid;       /**< source device for this class */
-    uint16_t    number;         /**< Valuator number            */
-    Atom        label;          /**< Axis label                 */
-    FP3232      min;            /**< Min value                  */
-    FP3232      max;            /**< Max value                  */
-    uint32_t    resolution;     /**< Resolutions in units/m     */
-} xXITouchValuatorInfo;
-
 /**
  * Used to select for events on a given window.
  * Struct is followed by (mask_len * CARD8), with each bit set representing
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 964f7a4..3e18820 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -573,7 +573,7 @@ If major_version is less than 2, a BadValue error occurs.
                  name:                  LISTofCHAR8
                  classes:               LISTofCLASS }
 
-    CLASS { BUTTONCLASS, KEYCLASS, AXISCLASS, TOUCHCLASS*, TOUCHAXISCLASS* }
+    CLASS { BUTTONCLASS, KEYCLASS, AXISCLASS, TOUCHCLASS* }
 
     BUTTONCLASS { type:                 ButtonClass
                   length:               CARD16
@@ -605,16 +605,6 @@ If major_version is less than 2, a BadValue error occurs.
                   num_touches:          CARD16
                   props:                LISTofATOM }
 
-    TOUCHAXISCLASS* {
-                  type:                 TouchAxisClass
-                  length:               CARD16
-                  sourceid:             CARD16
-                  axisnumber:           CARD16
-                  label:                ATOM
-                  min:                  FP3232
-                  max:                  FP3232
-                  resolution:           CARD32 }
-
     TOUCHMODE* { DirectTouch, DependentTouch }
 
 * since XI 2.1
@@ -739,33 +729,9 @@ client. If no min and max information is available, both must be 0.
     props
         A list of properties to denote extra information about the device.
 
-A device with a TouchClass must provide one or more TOUCHAXISCLASS
-specifiers.
-
-    TouchAxisClass:
-    type
-        Always TouchAxisClass.
-    length
-        Length in 4 byte units.
-    sourceid
-        The device this class originates from.
-    axisnumber
-        Axis number of this axis. The axis number is in device-native
-        order and potential axis mappings are ignored.
-    label
-        Atom specifying the axis name. An Atom of None specifies an unlabeled
-        axis.
-    min
-        Minimum value for this axis.
-    max
-        Maximum value for this axis.
-    resolution
-        Resolution in counts/meter.
-
-Devices generating touch events must provide exactly one TouchClass and
-two or more TouchAxisClasses. TouchAxisClasses and AxisClasses are not
-interchangable. A TouchAxisClass may only be part of a touch event,
-whereas an AxisClass may only be part of non-touch events.
+Devices with a TouchClass emit touch events with the same axes as pointer
+events. However, the X and Y axes of touch events are always provided in
+absolute mode co-ordinates.
 
 [[requests-selectevents]]
     ┌───
@@ -2001,12 +1967,8 @@ KeyRelease, ButtonPress, ButtonRelease, Motion.
         Button state before the event.
     valuators
         Bitmask of valuators provided in axisvalues.
-        XI 2.1: For event types TouchBegin, TouchUpdate, and TouchEnd, the
-        valuators are those specified as TouchAxisClass.
     axisvalues
         Valuator data in device-native resolution.
-        XI 2.1: For event types TouchBegin, TouchUpdate, and TouchEnd, the
-        valuators are those specified as TouchAxisClass.
     flags
         Miscellaneous information about this event; the union of the
         common flag set and either the key or pointer flag set,
@@ -2058,10 +2020,10 @@ Modifier state in mods is detailed as follows:
 
 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 touch axis valuator value
-changes, or a 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.
+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
@@ -2246,8 +2208,8 @@ require the client to announce XI 2.1 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 a touch axis valuator value changes
-   for a touch sequence it received a TouchBegin event for.
+** 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.
 
@@ -2260,10 +2222,9 @@ require the client to announce XI 2.1 support in the XIQueryVersion request.
 ** 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 a touch 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.
+** 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 XIAllowTouchEvents with the XITouchAccept flag set; at
    this point, C receives a TouchEnd event, and undoes any processing it has
@@ -2300,8 +2261,7 @@ require the client to announce XI 2.1 support in the XIQueryVersion request.
    motion events being sent as TouchUpdate events.
 
 *  Driver DRV provides touch support from tracked device D:
-** DRV initializes a TouchClass for the device and a TouchAxisClass for each
-   axis available on the device.
+** 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

From 4adfb5ad6c064981e2c7eb57db4bdd81cc7029ea Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Fri, 5 Aug 2011 15:28:51 -0700
Subject: [PATCH 265/388] Specify dependent device pointer/touch handling

With the added rules, trackpads should be manageable no matter what
occurs (button presses and pointer motion). Gesture and touch semantics
during these actions are not well defined, and cancelling touches cleans
up the protocol and implementation.

Signed-off-by: Chase Douglas 
---
 XI2.h              |  2 ++
 specs/XI2proto.txt | 26 +++++++++++++++++++++++++-
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/XI2.h b/XI2.h
index 31257d1..f6bdbb2 100644
--- a/XI2.h
+++ b/XI2.h
@@ -157,6 +157,8 @@
 #define XIPointerEmulated                       (1 << 16)
 /* Device event flags (touch events only) */
 #define XITouchPendingEnd                       (1 << 16)
+#define XITouchCanceled                         (1 << 17)
+#define XITouchResumed                          (1 << 18)
 
 /* Touch modes */
 #define XIDirectTouch                           1
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 3e18820..29ab8bc 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -266,6 +266,14 @@ When the touch has physically ended, or a client will otherwise not receive
 any more events for a given touchpoint, a <>
 will be sent to that client.
 
+A touch sequence may be canceled and/or resumed. When a sequence is canceled, a
+TouchEnd event is sent with the TouchCanceled flag. When a touch is resumed, a
+TouchBegin event is sent with the TouchResumed flag. Touch resumption denotes
+that touch processing has resumed; a resumed touch may never have been a
+canceled touch if the touch began while touch processing was inhibited. If a
+touch has stayed in physical contact from cancel through resume, the resumed
+touch sequence will have the same tracking ID.
+
 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
@@ -371,6 +379,21 @@ 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.
 
+Button presses for buttons one, two, and three on dependent devices will cause
+the following:
+
+- All touch events from the device are canceled. New touches are inhibited from
+  beginning new touch sequences.
+- The button press is handled and delivered through normal pointer event
+  mechanisms.
+- Pointer motion events may be generated by the device.
+
+When all of the buttons have been released, any active touches will resume, and
+new touches will be allowed to begin.
+
+When a dependent device causes pointer motion, touch sequences are canceled.
+Touch sequences may resume after pointer motion ceases.
+
 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.
@@ -1929,7 +1952,8 @@ For a detailed description of classes, see the XQueryDevice request.
     DEVICEEVENTFLAGS (all events): none
     DEVICEEVENTFLAGS (key events only): { KeyRepeat }
     DEVICEEVENTFLAGS (pointer and touch events only): { PointerEmulated }
-    DEVICEEVENTFLAGS (touch events only): { TouchPendingEnd }
+    DEVICEEVENTFLAGS (touch events only): { TouchPendingEnd, TouchCanceled,
+                                            TouchResumed }
 
 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

From 9f33733fffddd166c64f0bfd293c3de385cf4411 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 17 Aug 2011 16:02:39 +1000
Subject: [PATCH 266/388] specs: ValuatorClass includes a mode

Documented in the description, but missing in the definition.

Signed-off-by: Peter Hutterer 
Reviewed-by: Daniel Stone 
---
 specs/XI2proto.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

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.
 

From 94b21b47b51c2c66aa0372dfc323d6aedf12b549 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Tue, 23 Aug 2011 15:28:50 +1000
Subject: [PATCH 267/388] specs: fix two typos in XI2proto.txt

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

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:

From 1b0c016d1f7615e3670fa97fc8f24bc6b79e4f7b Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 24 Aug 2011 09:07:11 +1000
Subject: [PATCH 268/388] XITouchClass' props needs a num_props

In XI2 requests, the length field isn't enough to determine the number of
elements since it may vary in future versions.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 29ab8bc..3bb11ec 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -626,6 +626,7 @@ If major_version is less than 2, a BadValue error occurs.
                   sourceid:             CARD16
                   mode:                 TOUCHMODE
                   num_touches:          CARD16
+                  num_props:            CARD16
                   props:                LISTofATOM }
 
     TOUCHMODE* { DirectTouch, DependentTouch }
@@ -749,6 +750,8 @@ client. If no min and max information is available, both must be 0.
         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.
 

From 9e46dd35896c2517b1c95224b979fc7126dce49f Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 24 Aug 2011 09:07:13 +1000
Subject: [PATCH 269/388] Changing the touch device mode generates a
 DeviceChangedEvent

State it explicitly.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 3bb11ec..e464f58 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -363,7 +363,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.
+the touch mode may change at any time. If a device's touch mode changes, a
+DeviceChangedEvent is generated.
 
 [[multitouch-processing]]
 Touch event delivery

From 544ce0cee3cc146ed1df06ed5762d21ecdfe9e8a Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 24 Aug 2011 09:07:14 +1000
Subject: [PATCH 270/388] Add two linebreaks for asciidoc list parsing

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index e464f58..eb6bce6 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -434,6 +434,7 @@ 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
@@ -443,6 +444,7 @@ pointer events is delivered:
 
 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

From ae6ba6b37e47134914b8fedb6524372f0a8119c0 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 24 Aug 2011 09:07:15 +1000
Subject: [PATCH 271/388] Coordinates are always absolute, no need to re-state
 it

Coordinates in DeviceEvents are always absolute, regardless of the axis
mode. The same is true for touch events, stating it again here just adds to
the confusion.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index eb6bce6..ee8ca49 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -759,8 +759,7 @@ client. If no min and max information is available, both must be 0.
         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. However, the X and Y axes of touch events are always provided in
-absolute mode co-ordinates.
+events.
 
 [[requests-selectevents]]
     ┌───

From 5b8a8bd0b4e779b947093f9722a2af2568c27118 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 24 Aug 2011 09:07:16 +1000
Subject: [PATCH 272/388] XISelectEvents: BadValue is generated, not returned

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index ee8ca49..9f2349e 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -805,11 +805,12 @@ 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 BadValue will be
-returned. 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.
+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]]
     ┌───

From 67e06b8f14ac39c6c38e851b94b879024ff806a9 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 24 Aug 2011 09:07:17 +1000
Subject: [PATCH 273/388] Fix missing 'and' in GrabTypeFocusIn description

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 9f2349e..3d34f30 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1479,7 +1479,7 @@ 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.
 

From e51dd1b6bd4aa506231a41cbb400a8ece5a6aeaa Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 24 Aug 2011 09:07:18 +1000
Subject: [PATCH 274/388] Reword the passive touch grab rules to be similar to
 the others

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 3d34f30..8bf06cd 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1483,10 +1483,13 @@ device is actively grabbed if:
         - a passive grab of the same grab_type + modifier combination does not
           does not exist on an ancestor of grab_window.
 
-Or if grab_type is GrabtypeTouchBegin, a touch grab begins if:
+Otherwise, if grab_type is GrabtypeTouchBegin, a touch grab begins if:
 
-- a touch begins in grab_window or one of its ancestors, and
-- the specified modifier keys are down
+        - 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:
 

From d7fd289ee02d7ebc4cac5357edaaac1b55a7d10c Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 24 Aug 2011 09:07:19 +1000
Subject: [PATCH 275/388] Indent Ownership explanation for consistent
 formatting

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 8bf06cd..85b9caa 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1493,9 +1493,10 @@ Otherwise, if grab_type is GrabtypeTouchBegin, a touch grab begins if:
 
 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 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

From f469fa99ae9ffda806c3e935bbebc73d633f8c10 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 24 Aug 2011 09:07:21 +1000
Subject: [PATCH 276/388] AllowTouchEvents can take any device id, not just
 slaves

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 85b9caa..2f0c937 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1753,7 +1753,7 @@ The XIAllowTouchEvents request allows the current owner of a touch
 sequence to direct further delivery.
 
     deviceid
-        The slave device ID for a grabbed touch sequence.
+        The device ID for a grabbed touch sequence.
     touchid
         The ID of the touch sequence to modify.
     event_mode

From b025106fe8d8aa3043abd48ba3f50bde29527939 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 24 Aug 2011 09:07:22 +1000
Subject: [PATCH 277/388] DeviceEvent: active_touches needs marker that it's XI
 2.1

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 2f0c937..5bff92e 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1944,9 +1944,11 @@ For a detailed description of classes, see the XQueryDevice request.
             buttons:                    SETofBUTTONMASK
             valuators:                  SETofVALUATORMASK
             axisvalues:                 LISTofFP3232
-            active_touches:             CARD32
+            active_touches*:             CARD32
     └───
 
+    * since XI 2.1
+
     BUTTONBIT { (1 << Button1), (1 << Button2), ... , (1 << ButtonN) }
     VALUATORBIT { (1 << 1), ( 1 << 2), ... ( 1 << n) }
 

From 1cb00433583341b3c52c8d3f62dcd19a55ddca29 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 24 Aug 2011 09:07:23 +1000
Subject: [PATCH 278/388] DeviceEvents: a TouchPendingEnd won't generate
 further TouchUpdate events

Update, not motion.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 5bff92e..a246dfb 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2024,7 +2024,7 @@ KeyRelease, ButtonPress, ButtonRelease, Motion.
         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 motion events once an event with TouchPendingEnd has been
+        further TouchUpdate events once an event with TouchPendingEnd has been
         received.
     active_touches
         Only in XI 2.1 and later. Only valid for TouchBegin, TouchUpdate, and

From cec253561ab3feaa0a5a57fa8aa47db15662cf3d Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Wed, 24 Aug 2011 13:32:30 -0700
Subject: [PATCH 279/388] Introduce Touch grab mode

Touch grabs are not really synchronous nor asynchronous. Use a separate
grab mode value for touch grabs, just to make the protocol seem more
sane.

Signed-off-by: Chase Douglas 
Reviewed-by: Peter Hutterer 
---
 XI2.h              |  1 +
 specs/XI2proto.txt | 10 ++++++++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/XI2.h b/XI2.h
index f6bdbb2..2aea35e 100644
--- a/XI2.h
+++ b/XI2.h
@@ -72,6 +72,7 @@
 /* Grab modes */
 #define XIGrabModeSync                          0
 #define XIGrabModeAsync                         1
+#define XIGrabModeTouch                         2
 
 /* Grab reply status codes */
 #define XIGrabSuccess                           0
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index a246dfb..68612a8 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1380,7 +1380,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
@@ -1397,6 +1397,8 @@ you pass to the event-mode argument:
         GRABMODIFIERINFO {   status:    Access
                              modifiers: CARD32 }
 
+* since XI 2.1
+
 Establish an explicit passive grab for a button or keycode
 on the specified input device.
 
@@ -1423,7 +1425,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
@@ -1547,6 +1550,9 @@ 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

From 79c22a2e7b3c2bf73cd8af7eba7182198f13d2e4 Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Wed, 24 Aug 2011 13:34:47 -0700
Subject: [PATCH 280/388] Fix indentation of active_touches definition

Signed-off-by: Chase Douglas 
Reviewed-by: Peter Hutterer 
---
 specs/XI2proto.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 68612a8..463e3bf 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1950,7 +1950,7 @@ For a detailed description of classes, see the XQueryDevice request.
             buttons:                    SETofBUTTONMASK
             valuators:                  SETofVALUATORMASK
             axisvalues:                 LISTofFP3232
-            active_touches*:             CARD32
+            active_touches*:            CARD32
     └───
 
     * since XI 2.1

From 9e46820e4a206ae48b3e87f6ef7506e583fa3793 Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Wed, 24 Aug 2011 15:10:21 -0700
Subject: [PATCH 281/388] Fix touch cancel/resume semantics

If a touch is ended through a cancel, the client may never know if the
touch will come back as a resumed sequence. Instead, send a touch update
with the cancel flag, like the pending end flag, and send an end event
only when the full touch sequence has ended.

Signed-off-by: Chase Douglas 
Reviewed-by: Peter Hutterer 
---
 specs/XI2proto.txt | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 463e3bf..2a96162 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -267,12 +267,13 @@ any more events for a given touchpoint, a <>
 will be sent to that client.
 
 A touch sequence may be canceled and/or resumed. When a sequence is canceled, a
-TouchEnd event is sent with the TouchCanceled flag. When a touch is resumed, a
-TouchBegin event is sent with the TouchResumed flag. Touch resumption denotes
-that touch processing has resumed; a resumed touch may never have been a
-canceled touch if the touch began while touch processing was inhibited. If a
-touch has stayed in physical contact from cancel through resume, the resumed
-touch sequence will have the same tracking ID.
+TouchUpdate event is sent with the TouchCanceled flag set. When a touch is
+resumed, either a TouchBegin or a TouchUpdate event is sent with the
+TouchResumed flag set. TouchUpdate is sent if the client previously received
+events for the touch sequence. TouchBegin is sent if the client has not
+previously received events for the touch sequence. Touch resumption denotes that
+touch processing has resumed. A TouchEnd event will be sent to a client of a
+canceled touch sequence when the sequence ends.
 
 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

From 47a2cc250398648732ba2086ca6ecb21e7dabdc0 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 8 Apr 2011 12:59:17 +1000
Subject: [PATCH 282/388] Bump to 2.0.99

Signed-off-by: Peter Hutterer 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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
 

From b35f20b7bd9620710a7a6b63e39758fe83b4dec8 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 8 Apr 2011 13:26:27 +1000
Subject: [PATCH 283/388] Announce 2.1 availability through the XI_2_Major and
 XI_2_Minor defines

Signed-off-by: Peter Hutterer 
---
 XI2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

From 1e63d01d041108db6fe5be32d033e80419a6ab05 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Tue, 12 Apr 2011 13:07:53 +1000
Subject: [PATCH 284/388] 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 
Acked-by: Chase Douglas 
Reviewed-by: Daniel Stone 
Reviewed-by: Jeremy Huddleston 
---
 specs/XI2proto.txt | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

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.

From af1fb609beece899188469a81ac9d8c5e07bfa4a Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 29 Jul 2011 10:09:02 +1000
Subject: [PATCH 285/388] 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 

Signed-off-by: Peter Hutterer 
Reviewed-by: Daniel Stone 
---
 XI2proto.h         | 2 +-
 specs/XI2proto.txt | 7 +++++++
 2 files changed, 8 insertions(+), 1 deletion(-)

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

From 53b58e679f977550301130794c8cb19391ecceb7 Mon Sep 17 00:00:00 2001
From: Daniel Stone 
Date: Tue, 15 Feb 2011 14:27:53 +0000
Subject: [PATCH 286/388] 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 
Reviewed-by: Peter Hutterer 
---
 XI2.h              | 1 +
 specs/XI2proto.txt | 5 ++++-
 2 files changed, 5 insertions(+), 1 deletion(-)

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:
 

From 186aa20619d1720bde49fd92d2834c8f9eadf49b Mon Sep 17 00:00:00 2001
From: Daniel Stone 
Date: Wed, 23 Feb 2011 17:37:29 +0000
Subject: [PATCH 287/388] 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 
Reviewed-by: Peter Hutterer 
---
 specs/XI2proto.txt | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

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:
 

From 7d5a303cd8976a7eac1b96897c70d5d25c57ecf1 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Mon, 15 Aug 2011 12:33:04 +1000
Subject: [PATCH 288/388] 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 
---
 XI2.h              |  9 ++++++
 XI2proto.h         | 15 +++++++++
 specs/XI2proto.txt | 77 ++++++++++++++++++++++++++++++++++++++--------
 3 files changed, 88 insertions(+), 13 deletions(-)

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.
+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.
 
-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.
+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

From 9cfdeedd16e96c0e67e70537e97a8f8dd0358244 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Thu, 2 Jun 2011 16:09:23 +1000
Subject: [PATCH 289/388] inputproto 2.0.99.1 (first snapshot of 2.1)

Signed-off-by: Peter Hutterer 
Reviewed-by: Jeremy Huddleston 
Reviewed-by: Daniel Stone 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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
 

From 4329d45d49741aad0e93f8e064042ba83e6a23a0 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Mon, 29 Aug 2011 09:20:28 +1000
Subject: [PATCH 290/388] specs: Fix in-document references

The primary format for the specs is still the txt format (since that's
guaranteed to be available anywhere, including cgit). Having in-paragraph
references breaks the flow of reading. Fix up some references that aren't
strictly necessary anyway, reword some to be easier to read and change the
titles of some to match the actual title of the section.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 48 +++++++++++++++++++++++-----------------------
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 2a96162..ea96b3a 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -89,8 +89,8 @@ XI 2.1 caters for two modes of touch input devices:
 Touch events are only available to clients supporting version 2.1 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.1 touch events to support older clients; see the
-<> section.
+alongside XI 2.1 touch events to support older clients; see Section
+<>.
 
 
 [[interop-xi1]]
@@ -131,10 +131,10 @@ respectively.
 Invisibility of Master Devices
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-XI 1.x was not designed with support for multiple master devices (see the
-<> section). 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.
 
 
 [[hierachy]]
@@ -228,8 +228,8 @@ 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; the
-<> section has more details.
+clients simultaneously; for more details see Section
+<>.
 
 [[multitouch-lifecycle]]
 Touch event sequences
@@ -244,12 +244,12 @@ 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.
 In the protocol, the three stages are represented with the event
-types <>, <>, and
-<>, 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.
+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 <>
+When a touch starts, clients are sent a TouchBegin event
 detailing the position used to focus the event for delivery, 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
@@ -258,13 +258,13 @@ 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 <> is sent to all clients listening
+a TouchUpdate event is sent to all clients listening
 to events for that touchpoint with the updated information (usually new touch
 co-ordinates).
 
 When the touch has physically ended, or a client will otherwise not receive
-any more events for a given touchpoint, a <>
-will be sent to that client.
+any more events for a given touchpoint, a TouchEnd event will be sent to
+that client.
 
 A touch sequence may be canceled and/or resumed. When a sequence is canceled, a
 TouchUpdate event is sent with the TouchCanceled flag set. When a touch is
@@ -280,14 +280,14 @@ 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 the
-<>.  See the
-<>
+and must decide what to do with it, as per Section
+<>.  See the
+<> 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 (see the
-<>) are allowed.
+although some overlapping selections are allowed (see Section
+<>).
 
 [[multitouch-ownership]]
 Ownership of touch sequences
@@ -295,7 +295,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
-<>. If a touch sequence is
+<> 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
@@ -319,7 +319,7 @@ 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
-<> mask in addition to 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
@@ -997,7 +997,7 @@ is returned.
                   deviceid:   DEVICEID }
 
 XIChangeHierarchy allows a client to modify the
-<>.
+<>.
 
     num_changes
         The number of changes to apply to the current hierarchy.

From 63f3097d264f790419ce59744e8d2733f9bb1026 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Mon, 29 Aug 2011 09:20:29 +1000
Subject: [PATCH 291/388] specs: Fix event lists for asciidoc parsing

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 45 ++++++++++++++++++++++++---------------------
 1 file changed, 24 insertions(+), 21 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index ea96b3a..d2c7478 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1794,28 +1794,31 @@ 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.1:
-        TouchBegin
-        TouchUpdate
-        TouchOwnership
-        TouchEnd
+
+        - TouchBegin
+        - TouchUpdate
+        - TouchOwnership
+        - TouchEnd
 
 All events have a set of common fields specified as EVENTHEADER.
 

From 3d23bf3782c9962b70dfa46ea34c86efee57eeb2 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Mon, 29 Aug 2011 09:20:30 +1000
Subject: [PATCH 292/388] Change file header to note version 2.x

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index d2c7478..7c5011c 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1,5 +1,5 @@
-The X Input Extension
-=====================
+The X Input Extension 2.x
+=========================
 :toc:
 :numbered:
 

From b55d236a66a614b2192da6d8a7ed4b7d831976f5 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Mon, 29 Aug 2011 09:20:31 +1000
Subject: [PATCH 293/388] Add comment to XI2.h to mark where the 2.1 events
 start

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 XI2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/XI2.h b/XI2.h
index 2aea35e..bd6829d 100644
--- a/XI2.h
+++ b/XI2.h
@@ -193,7 +193,7 @@
 #define XI_RawButtonPress                15
 #define XI_RawButtonRelease              16
 #define XI_RawMotion                     17
-#define XI_TouchBegin                    18
+#define XI_TouchBegin                    18 /* XI 2.1 */
 #define XI_TouchEnd                      19
 #define XI_TouchOwnership                20
 #define XI_TouchUpdate                   21

From 1b40cc4ff63ebbf0a4b17507762b17fa1e91bea9 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Mon, 29 Aug 2011 09:20:32 +1000
Subject: [PATCH 294/388] specs: extend XI2.1 raw events to include touch
 events

RawEvents are simple enough that we can re-use the detail field for the
touch ID tracking and just update the respective event types.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 XI2.h              | 8 +++++++-
 specs/XI2proto.txt | 7 ++++++-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/XI2.h b/XI2.h
index bd6829d..04e3631 100644
--- a/XI2.h
+++ b/XI2.h
@@ -197,7 +197,10 @@
 #define XI_TouchEnd                      19
 #define XI_TouchOwnership                20
 #define XI_TouchUpdate                   21
-#define XI_LASTEVENT                     XI_TouchUpdate
+#define XI_RawTouchBegin                 22
+#define XI_RawTouchEnd                   23
+#define XI_RawTouchUpdate                24
+#define XI_LASTEVENT                     XI_RawTouchUpdate
 /* 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. */
@@ -227,5 +230,8 @@
 #define XI_TouchEndMask                  (1 << XI_TouchEnd)
 #define XI_TouchOwnershipChangedMask     (1 << XI_TouchOwnershipChanged)
 #define XI_TouchUpdateMask               (1 << XI_TouchUpdate)
+#define XI_RawTouchBeginMask             (1 << XI_RawTouchBegin)
+#define XI_RawTouchEndMask               (1 << XI_RawTouchEnd)
+#define XI_RawTouchUpdateMask            (1 << XI_RawTouchUpdate)
 
 #endif /* _XI2_H_ */
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 7c5011c..e95a429 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1819,6 +1819,9 @@ Version 2.1:
         - TouchUpdate
         - TouchOwnership
         - TouchEnd
+        - RawTouchBegin
+        - RawTouchUpdate
+        - RawTouchEnd
 
 All events have a set of common fields specified as EVENTHEADER.
 
@@ -2107,7 +2110,7 @@ that grabbed the device only.
     eventtype
         The type of event that occured on the device.
     detail
-        The button number or keycode.
+        The button number, keycode or touch ID*.
     flags
         Flags as described in DeviceEvent.
     valuators_len
@@ -2119,6 +2122,8 @@ that grabbed the device only.
     axisvalues_raw
         Untransformed valuator data in device-native resolution.
 
+* since XI 2.1
+
 [[events-enterleave]]
     ┌───
         Enter or Leave or FocusIn or FocusOut

From 42284fa0a233240d365ff2b49cc34c257e2d2bee Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Mon, 12 Sep 2011 15:55:28 -0500
Subject: [PATCH 295/388] Revert "Fix touch cancel/resume semantics"

The main use case for this was drag and drop, which we realized does not
need any special handling that requires canceling touches.

This reverts commit 9e46820e4a206ae48b3e87f6ef7506e583fa3793.

Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index e95a429..0f69558 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -267,13 +267,12 @@ any more events for a given touchpoint, a TouchEnd event will be sent to
 that client.
 
 A touch sequence may be canceled and/or resumed. When a sequence is canceled, a
-TouchUpdate event is sent with the TouchCanceled flag set. When a touch is
-resumed, either a TouchBegin or a TouchUpdate event is sent with the
-TouchResumed flag set. TouchUpdate is sent if the client previously received
-events for the touch sequence. TouchBegin is sent if the client has not
-previously received events for the touch sequence. Touch resumption denotes that
-touch processing has resumed. A TouchEnd event will be sent to a client of a
-canceled touch sequence when the sequence ends.
+TouchEnd event is sent with the TouchCanceled flag. When a touch is resumed, a
+TouchBegin event is sent with the TouchResumed flag. Touch resumption denotes
+that touch processing has resumed; a resumed touch may never have been a
+canceled touch if the touch began while touch processing was inhibited. If a
+touch has stayed in physical contact from cancel through resume, the resumed
+touch sequence will have the same tracking ID.
 
 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

From d6dcfd4039ede37e9c858ab6e890fdb9582a5a9d Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Mon, 12 Sep 2011 16:01:53 -0500
Subject: [PATCH 296/388] Revert "Specify dependent device pointer/touch
 handling"

See parent commit for details.

This reverts commit 4adfb5ad6c064981e2c7eb57db4bdd81cc7029ea.

Signed-off-by: Chase Douglas 
---
 XI2.h              |  2 --
 specs/XI2proto.txt | 26 +-------------------------
 2 files changed, 1 insertion(+), 27 deletions(-)

diff --git a/XI2.h b/XI2.h
index 04e3631..43c5836 100644
--- a/XI2.h
+++ b/XI2.h
@@ -158,8 +158,6 @@
 #define XIPointerEmulated                       (1 << 16)
 /* Device event flags (touch events only) */
 #define XITouchPendingEnd                       (1 << 16)
-#define XITouchCanceled                         (1 << 17)
-#define XITouchResumed                          (1 << 18)
 
 /* Touch modes */
 #define XIDirectTouch                           1
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 0f69558..ca72559 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -266,14 +266,6 @@ 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.
 
-A touch sequence may be canceled and/or resumed. When a sequence is canceled, a
-TouchEnd event is sent with the TouchCanceled flag. When a touch is resumed, a
-TouchBegin event is sent with the TouchResumed flag. Touch resumption denotes
-that touch processing has resumed; a resumed touch may never have been a
-canceled touch if the touch began while touch processing was inhibited. If a
-touch has stayed in physical contact from cancel through resume, the resumed
-touch sequence will have the same tracking ID.
-
 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
@@ -380,21 +372,6 @@ 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.
 
-Button presses for buttons one, two, and three on dependent devices will cause
-the following:
-
-- All touch events from the device are canceled. New touches are inhibited from
-  beginning new touch sequences.
-- The button press is handled and delivered through normal pointer event
-  mechanisms.
-- Pointer motion events may be generated by the device.
-
-When all of the buttons have been released, any active touches will resume, and
-new touches will be allowed to begin.
-
-When a dependent device causes pointer motion, touch sequences are canceled.
-Touch sequences may resume after pointer motion ceases.
-
 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.
@@ -1976,8 +1953,7 @@ For a detailed description of classes, see the XQueryDevice request.
     DEVICEEVENTFLAGS (all events): none
     DEVICEEVENTFLAGS (key events only): { KeyRepeat }
     DEVICEEVENTFLAGS (pointer and touch events only): { PointerEmulated }
-    DEVICEEVENTFLAGS (touch events only): { TouchPendingEnd, TouchCanceled,
-                                            TouchResumed }
+    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

From 24e7dac91fb919c1668736f6e4309ae522a96d86 Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Tue, 13 Sep 2011 14:27:13 -0500
Subject: [PATCH 297/388] Switch multitouch additions to XI 2.2

Signed-off-by: Chase Douglas 
---
 XI2.h              |  7 ++++++-
 specs/XI2proto.txt | 46 +++++++++++++++++++++++-----------------------
 2 files changed, 29 insertions(+), 24 deletions(-)

diff --git a/XI2.h b/XI2.h
index ca5ce07..3c1f4a5 100644
--- a/XI2.h
+++ b/XI2.h
@@ -30,12 +30,17 @@
 #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 */
 
 #define XI_2_Major                              2
-#define XI_2_Minor                              1
+#define XI_2_Minor                              2
 
 /* Property event flags */
 #define XIPropertyDeleted                       0
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index e555e46..18ae599 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -27,7 +27,7 @@ Authors:
 History 
 -------
 
-- v2.1, ?? 2011: Multitouch support added
+- v2.2, ??: Multitouch support added
 - v2.0, October 2009: Initial release of XI2 protocol
 
 [[intro-xi20]]
@@ -66,22 +66,22 @@ Changes introduced by version 2.1
 -----------
 Changes introduced by version 2.2
 
-XI 2.1 introduces support for multi-touch devices. The traditional
+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.1 aim to:
+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.1 clients through emulation of XI 2.0/XI 1.x and core
+- while supporting pre-XI 2.2 clients through emulation of XI 2.x/XI 1.x and core
   pointer events.
 
-XI 2.1 caters for two modes of touch input devices:
+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;
@@ -93,10 +93,10 @@ XI 2.1 caters for two modes of touch input devices:
   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.1 or later of
+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.1 touch events to support older clients; see Section
+alongside XI 2.2 touch events to support older clients; see Section
 <>.
 
 //                            ❧❧❧❧❧❧❧❧❧❧❧
@@ -1269,7 +1269,7 @@ 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.  This request does not, however, affect the processing of XI 2.1
+device.  This request does not, however, affect the processing of XI 2.2
 touch events.
 
     deviceid
@@ -1485,7 +1485,7 @@ you pass to the event-mode argument:
         GRABMODIFIERINFO {   status:    Access
                              modifiers: CARD32 }
 
-* since XI 2.1
+* since XI 2.2
 
 Establish an explicit passive grab for a button or keycode
 on the specified input device.
@@ -1827,8 +1827,8 @@ 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-xi21]]
-Requests introduced in version 2.1
+[[requests-xi22]]
+Requests introduced in version 2.2
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 [[requests-allowtouchevents]]
@@ -1900,7 +1900,7 @@ Version 2.0:
         - FocusOut
         - PropertyEvent
 
-Version 2.1:
+Version 2.2:
 
         - TouchBegin
         - TouchUpdate
@@ -2047,7 +2047,7 @@ For a detailed description of classes, see the XIQueryDevice request.
             active_touches*:            CARD32
     └───
 
-    * since XI 2.1
+    * since XI 2.2
 
     BUTTONBIT { (1 << Button1), (1 << Button2), ... , (1 << ButtonN) }
     VALUATORBIT { (1 << 1), ( 1 << 2), ... ( 1 << n) }
@@ -2071,7 +2071,7 @@ 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.1: The event type may also be TouchBegin, TouchUpdate, or TouchEnd.
+    XI 2.2: The event type may also be TouchBegin, TouchUpdate, or TouchEnd.
 
     detail
         The button number, key code, touch ID, or 0.
@@ -2128,7 +2128,7 @@ KeyRelease, ButtonPress, ButtonRelease, Motion.
         further TouchUpdate events once an event with TouchPendingEnd has been
         received.
     active_touches
-        Only in XI 2.1 and later. Only valid for TouchBegin, TouchUpdate, and
+        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
@@ -2153,7 +2153,7 @@ Modifier state in mods is detailed as follows:
     locked_group
         XKB locked group state.
 
-    XI 2.1:
+    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
@@ -2221,7 +2221,7 @@ when the device is grabbed by another client.
     axisvalues_raw
         Untransformed valuator data in device-native resolution.
 
-* since XI 2.1
+* since XI 2.2
 
 [[events-enterleave]]
     ┌───
@@ -2320,13 +2320,13 @@ modified by a client.
     what
         Specifies what has been changed.
      
-[[events-xi21]]
-Events introduced in version 2.1
+[[events-xi22]]
+Events introduced in version 2.2
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 [[events-touchownershipevent]]
     ┌───
-        TouchOwnershipEvent (since XI 2.1):
+        TouchOwnershipEvent (since XI 2.2):
             EVENTHEADER
             sourceid:                   DEVICEID
             touchid:                    CARD32
@@ -2347,13 +2347,13 @@ is now the owner of the touch sequence specified by touchid.
 
 
 // FIXME: why do we get '11. Appendix A:' rather than just 'Appendix A:'?!
-[[xi21-usecases]]
+[[xi22-usecases]]
 [appendix]
-XI 2.1 Use-cases
+XI 2.2 Use-cases
 ----------------
 
 All use-cases that include the receiving and processing of touch events
-require the client to announce XI 2.1 support in the XIQueryVersion request.
+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.

From cfa06b98d50d6892e5961e86f6223b6b096d9ef4 Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Tue, 13 Sep 2011 15:09:57 -0500
Subject: [PATCH 298/388] Bump version to 2.1.99 for XI 2.2 multitouch changes

Signed-off-by: Chase Douglas 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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
 

From dd32802d2e6134cf9c4efd49c56c118ed02e6a2b Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 14 Sep 2011 05:21:31 +1000
Subject: [PATCH 299/388] specs: misc typos, rewording, etc.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 48 ++++++++++++++++++++++++----------------------
 1 file changed, 25 insertions(+), 23 deletions(-)

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-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

From 4782a76b6e679493f130a53afe158a13628fa504 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 14 Sep 2011 05:25:15 +1000
Subject: [PATCH 300/388] specs: remove comment about overlapping selections,
 not true

There are no overlapping selections for touch events.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

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
 <> 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
-<>).
+Only one client may select for touch events from a given device on a window.
 
 [[multitouch-ownership]]
 Ownership of touch sequences

From 94fecdf129d8ab5bece049a26eed03d24affb549 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 14 Sep 2011 05:26:54 +1000
Subject: [PATCH 301/388] specs: remove broken asciidoc link to
 XIAllowTouchEvents

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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. 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

From 05fc509fdca8d8b414a20f1359b9cb80caf5240a Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 14 Sep 2011 05:46:43 +1000
Subject: [PATCH 302/388] specs: if a sequence ends, all clients get
 TouchPendingEnd

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

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

From dd9e4bc5f5f2e0eb87b08199ce417849070249ab Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Tue, 13 Sep 2011 15:30:34 -0500
Subject: [PATCH 303/388] Really kill touch valuators

Signed-off-by: Chase Douglas 
---
 XI2.h | 1 -
 1 file changed, 1 deletion(-)

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

From 3c400af4f98740debd7916ad711cf91124a0f994 Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Tue, 13 Sep 2011 15:47:15 -0500
Subject: [PATCH 304/388] Add event windows to ownership events

Also, match device event structure to make things easy.

Signed-off-by: Chase Douglas 
---
 XI2proto.h         |  6 +++++-
 specs/XI2proto.txt | 14 +++++++++++---
 2 files changed, 16 insertions(+), 4 deletions(-)

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.
 

From 2ea2f99f4fe1dcd3b8e539ca41c482fc40a0533d Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Wed, 14 Sep 2011 09:46:18 -0500
Subject: [PATCH 305/388] 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 
Reviewed-by: Peter Hutterer 
---
 XI2.h              |  6 ++--
 XI2proto.h         | 20 ++---------
 specs/XI2proto.txt | 87 ++++++++++++++++++----------------------------
 3 files changed, 38 insertions(+), 75 deletions(-)

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

From fa16231f0e5244cdcf77e262647525716f507bdd Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Wed, 14 Sep 2011 10:10:14 -0500
Subject: [PATCH 306/388] 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 
Reviewed-by: Peter Hutterer 
---
 XI2proto.h         |  3 ++-
 specs/XI2proto.txt | 28 ++++++++++++++++++----------
 2 files changed, 20 insertions(+), 11 deletions(-)

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]]
     ┌───

From 88410aa51d03dbb5599e979998137ba6558ff677 Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Tue, 13 Sep 2011 16:59:54 -0500
Subject: [PATCH 307/388] 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 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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
 

From 22c06a5ddb1d3be2743a79b78eff3844f457dc5e Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Wed, 14 Sep 2011 20:15:49 -0500
Subject: [PATCH 308/388] Fix Xi 2.x version comment in XI2.h

Signed-off-by: Chase Douglas 
---
 XI2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

From cec7567863c3d363b6b75c707540cfe524f849ba Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Wed, 14 Sep 2011 22:09:28 -0500
Subject: [PATCH 309/388] 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 
Reviewed-by: Peter Hutterer 
---
 XI2proto.h         | 1 -
 specs/XI2proto.txt | 6 ------
 2 files changed, 7 deletions(-)

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

From 463ffaabab506ad6ddb3b55c5781ae91fcccfd04 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 23 Sep 2011 08:41:18 +1000
Subject: [PATCH 310/388] specs: clarify that Preferred scroll valuators are
 per scroll direction

Reported-by: Daniel Stone 
Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

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
 ------------------------------------

From 86ce2d05e86852d52f5b135ad03288e4cb16d5df Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Thu, 3 Nov 2011 09:30:20 +1000
Subject: [PATCH 311/388] 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 
Reviewed-by: Chase Douglas 
Reviewed-by: Jeremy Huddleston 
Signed-off-by: Chase Douglas 
---
 XI2.h | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

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. */

From b289b1c039e36a9440c238ff09dfa3eb67e141e4 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Thu, 20 Oct 2011 15:55:54 +1000
Subject: [PATCH 312/388] XI2: Use touchid, not touch_id in XIAllowEvents

Be consistent with other usages of touchid.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 XI2proto.h         | 2 +-
 specs/XI2proto.txt | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

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

From 9f2b1a33063b139756e08951affe802e8af39a76 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Tue, 8 Nov 2011 15:29:24 +1000
Subject: [PATCH 313/388] specs: We're up to version 2.1 now, say so

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 1 +
 1 file changed, 1 insertion(+)

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

From 279524b089c7b42871ee072cfc03a1fad7421b7b Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Tue, 8 Nov 2011 15:36:02 +1000
Subject: [PATCH 314/388] specs: scroll events have no specific event type,
 state so.

This wasn't clear enough in the current spec.

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

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.
+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.
 
-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.
+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

From c9c4e13e8a3eb90b45c5ef65f729089b7f742e6a Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 11 Nov 2011 14:22:08 +1000
Subject: [PATCH 315/388] inputproto 2.1.99.2

Signed-off-by: Peter Hutterer 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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
 

From a9fcea66eb18fab330f3b27b3daedef2b5c9210a Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 11 Nov 2011 14:33:34 +1000
Subject: [PATCH 316/388] specs: smooth scrolling was added in 2.1, say so

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 1 +
 1 file changed, 1 insertion(+)

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
 
 //                            ❧❧❧❧❧❧❧❧❧❧❧
 

From 019a252a59c1d076b07a0162cb3ee6af42ceea14 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 2 Dec 2011 15:03:46 +1000
Subject: [PATCH 317/388] specs: typo fix

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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.

From c4703fd9d97c962d5c599a7f826a9a11fc91ee70 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Mon, 12 Dec 2011 10:26:20 +1000
Subject: [PATCH 318/388] 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 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 XI2.h | 10 ----------
 1 file changed, 10 deletions(-)

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 */

From 7d20c9bf38d3d47adc7fb1a70faa370dda1a390c Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Fri, 9 Dec 2011 13:32:35 -0800
Subject: [PATCH 319/388] 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 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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.
 

From 84c049b6603e370afcd267ce4c53a566f842fd69 Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Mon, 12 Dec 2011 10:50:58 -0800
Subject: [PATCH 320/388] 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 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

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.
 

From 02eadf00f07abb9b0f19a05728b70e42eac08adb Mon Sep 17 00:00:00 2001
From: Chase Douglas 
Date: Tue, 13 Dec 2011 10:35:18 -0800
Subject: [PATCH 321/388] inputproto 2.1.99.3

Signed-off-by: Chase Douglas 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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
 

From b1d71fe4cd3871a78e442159443c141193e79a7f Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 14 Dec 2011 08:56:09 +1000
Subject: [PATCH 322/388] specs: drop leftover from active_touches removal

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 6082166..dcc2bc9 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2112,11 +2112,6 @@ KeyRelease, ButtonPress, ButtonRelease, Motion.
         further TouchUpdate events once an event with TouchPendingEnd has been
         received.
 
-The active_touches value denotes the number of touches in contact with
-the source touch device surface when the event occurred. The value
-includes the new touch for a TouchBegin event, and does not include the
-ending touch for a TouchEnd event.
-
 Modifier state in mods is detailed as follows:
 
     base_mods

From 8687f155d8072763c2c7d52cb48eb5f46bfaf705 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 14 Dec 2011 08:56:59 +1000
Subject: [PATCH 323/388] specs: clarify button state in touch events

Emulated pointer events will have button 1 logically down, but touch events
only represent the actual button state, irrespective of the touches.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 specs/XI2proto.txt | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index dcc2bc9..8b79210 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -467,10 +467,12 @@ Pointer events are emulated as follows:
   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.
+  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.
+  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
@@ -2150,6 +2152,9 @@ 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]]

From b701750ee99e1e227ad8baa994b6fd3398949a3a Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Thu, 15 Dec 2011 17:07:54 +0100
Subject: [PATCH 324/388] specs: Fix tiny typo.

Signed-off-by: Cyril Brulebois 
Reviewed-by: Peter Hutterer 
Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 8b79210..46895d8 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2390,7 +2390,7 @@ require the client to announce XI 2.2 support in the XIQueryVersion request.
    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 be subject to the synchronous delivery mechanism. The
+   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

From 8640944f4ff193027ce0f21622918b88da910e72 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 16 Dec 2011 11:06:13 +1000
Subject: [PATCH 325/388] inputproto 2.1

Signed-off-by: Peter Hutterer 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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
 

From ee0bc61ee3fd775127f8cd222d83314f66255f2b Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Tue, 20 Dec 2011 08:22:52 +1000
Subject: [PATCH 326/388] Drop wrong comment for sourceid in
 TouchOwnershipEvents

Copy/paste error from DeviceChangedEvent

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 XI2proto.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/XI2proto.h b/XI2proto.h
index 56df401..93d7e32 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -901,7 +901,7 @@ typedef struct
     Window      event;
     Window      child;
 /* └──────── 32 byte boundary ────────┘ */
-    uint16_t    sourceid;           /**< Source of the new classes */
+    uint16_t    sourceid;
     uint16_t    pad0;
     uint32_t    flags;
     uint32_t    pad1;

From 9a9746b95f3585bba9730105769e9c74520f6bc4 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Tue, 20 Dec 2011 08:23:55 +1000
Subject: [PATCH 327/388] Reinstate libXi's version defines

Realistically, we can't remove these from the protocol without breaking
older libraries.

Introduced in a02566ca7fd37d279b957037e1251a3b3419866d

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
Signed-off-by: Chase Douglas 
---
 XI.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/XI.h b/XI.h
index 378b34a..7b44399 100644
--- a/XI.h
+++ b/XI.h
@@ -135,6 +135,17 @@ SOFTWARE.
 #define XI_FOOTMOUSE	"FOOTMOUSE"
 #define XI_JOYSTICK	"JOYSTICK"
 
+/* Indices into the versions[] array (XExtInt.c). Used as a index to
+ * retrieve the minimum version of XI from _XiCheckExtInit */
+#define Dont_Check			0
+#define XInput_Initial_Release		1
+#define XInput_Add_XDeviceBell		2
+#define XInput_Add_XSetDeviceValuators	3
+#define XInput_Add_XChangeDeviceControl	4
+#define XInput_Add_DevicePresenceNotify	5
+#define XInput_Add_DeviceProperties	6
+/* DO NOT ADD TO HERE -> XI2 */
+
 #define XI_Absent		0
 #define XI_Present		1
 

From aef700dbac09d3c8a576387be47e5693460f1393 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 21 Dec 2011 15:23:23 +1000
Subject: [PATCH 328/388] specs: remove parts of the "Work in progress" warning

The protocol is stable enough now that a simple warning should be enough.

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 46895d8..dfcbde9 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -4,18 +4,6 @@ The X Input Extension 2.x
 :numbered:
 
 .This is a work in progress!
-*****************************************************************************
-While XI 2.0 is final and widely deployed, XI 2.1 is still a work in progress;
-the protocol is not final and is subject to change at any time. While testing
-and feedback is strongly encouraged and very much welcome, please be aware that
-any part of the XI 2.1 additions may change from underneath you. We strongly
-recommend against deploying it in production for this reason.
-
-Developing against XI 2.1 requires passing the --enable-unstable-protocol
-argument when building inputproto, and additionally defining
-XINPUT2_1_USE_UNSTABLE_PROTOCOL when building your applications. I'm sure you
-get the point by now, so I promise not to mention it again.
-*****************************************************************************
 
 Authors:
 

From 5c9a6569e5182a4c4c6ec052bcd76a9ca3b8f645 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 21 Dec 2011 15:24:44 +1000
Subject: [PATCH 329/388] Remove --enable-unstable-protocol configure option

Protocol is reasonably stable and about to be merged onto the master
branch. People should be used to stuff on master being a tad unstable, don't
require any specific configure flags.

Signed-off-by: Peter Hutterer 
---
 configure.ac | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/configure.ac b/configure.ac
index d2b1c3c..d6c5904 100644
--- a/configure.ac
+++ b/configure.ac
@@ -11,14 +11,6 @@ XORG_DEFAULT_OPTIONS
 XORG_ENABLE_SPECS
 XORG_WITH_ASCIIDOC(8.4.5)
 
-AC_ARG_ENABLE(unstable-protocol,
-              AS_HELP_STRING([--enable-unstable-protocol],
-                             [Enables compilation of yet-to-be-finalised protocol (default: disabled)]),
-              [UNSTABLE_PROTO=$enableval], [UNSTABLE_PROTO=no])
-if ! test "x$UNSTABLE_PROTO" = xyes; then
-    AC_MSG_ERROR([This branch contains protocol elements which have not yet been finalised.  When this branch is updated, you will probably need to recompile both the server, libXi, and input-using clients, and may experience crashes or undefined behaviour if you do not.])
-fi
-
 AC_OUTPUT([Makefile
            specs/Makefile
            inputproto.pc])

From c508e9360414f9724cc875a4731a5fd8a3969d2b Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 21 Dec 2011 15:27:47 +1000
Subject: [PATCH 330/388] specs: add XI 2.1 release to history section

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index dfcbde9..05d7801 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -16,6 +16,8 @@ History
 -------
 
 - 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]]

From b9f1b26f076cdba373e8b7a0b73384b35e8d799c Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 21 Dec 2011 15:30:22 +1000
Subject: [PATCH 331/388] inputproto 2.1.99.4

Signed-off-by: Peter Hutterer 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index d6c5904..efc5242 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
 AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.1.99.3], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.1.99.4], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
 AM_INIT_AUTOMAKE([foreign dist-bzip2])
 AM_MAINTAINER_MODE
 

From 9611be0a5bc7f4d583d49d51a0e98d3b9b75fc7a Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 23 Dec 2011 18:03:09 +1000
Subject: [PATCH 332/388] specs: Clarify rejection for touch events on current
 owner

The current owner never gets a TouchUpdate(PendingEnd), that event is
superfluous for the owner. The owner receives a TouchEnd when the touch
physically ends. If the touch is still active, the owner receives a
TouchEnd after rejecting the touch.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 0455ed3..2f03b50 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -366,11 +366,16 @@ 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.
+has not yet accepted or rejected ownership, the owner receives a TouchEnd
+event and all other 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.
+
+If the touch sequence has not physically ended yet and the owner of the
+touch sequence rejects, the owner receives a TouchEnd event and ownership is
+passed to the next client.
 
 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

From e65ba758c2d4147c3873c63c262db36ec23bba63 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Tue, 3 Jan 2012 09:23:23 +1000
Subject: [PATCH 333/388] specs: only pointer events have a PointerEmulated
 flag

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 2f03b50..7ea2048 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2047,7 +2047,7 @@ For a detailed description of classes, see the XIQueryDevice request.
 
     DEVICEEVENTFLAGS (all events): none
     DEVICEEVENTFLAGS (key events only): { KeyRepeat }
-    DEVICEEVENTFLAGS (pointer and touch events only): { PointerEmulated }
+    DEVICEEVENTFLAGS (pointer events only): { PointerEmulated }
     DEVICEEVENTFLAGS (touch events only): { TouchPendingEnd }
 
 An XIDeviceEvent is generated whenever the logical state of a device

From 5ee845c1bf457159a034111c3d0df584aa600cd6 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Tue, 3 Jan 2012 09:24:38 +1000
Subject: [PATCH 334/388] specs: purge leftover TouchAccepted note

This flag does not exist anymore.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 7ea2048..8e2eea8 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2102,9 +2102,6 @@ KeyRelease, ButtonPress, ButtonRelease, Motion.
         and 7) if a smooth-scrolling event on the Rel Vert Scroll or
         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

From 997ae0343730c66d581fd147741cbe27fbe55af2 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Tue, 3 Jan 2012 09:26:22 +1000
Subject: [PATCH 335/388] Set a flag on the pointer-emulating touch event

Toolkits need to know which touch event emulated a pointer event and which
ones do not. To quote Carlos Garnacho:

    GTK+ does client-side windows by default (GdkWindows without a backing X
    window), for this to work the toplevel window in the client needs to
    select for more events that it wouldn't normally select for in order to
    cater for the event masks in such child "windows". This means that
    ideally GTK+ should set the touch events mask in the toplevel, and then
    find out whether the "window" would receive pointer or touch events for
    the sequence emulating the pointer, and perform the emulation itself.

Reported-by: Carlos Garnacho 
Reviewed-by: Chase Douglas 
Signed-off-by: Peter Hutterer 
---
 XI2.h              | 1 +
 specs/XI2proto.txt | 8 ++++++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/XI2.h b/XI2.h
index 4368006..e864b06 100644
--- a/XI2.h
+++ b/XI2.h
@@ -158,6 +158,7 @@
 #define XIPointerEmulated                       (1 << 16)
 /* Device event flags (touch events only) */
 #define XITouchPendingEnd                       (1 << 16)
+#define XITouchEmulatingPointer                 (1 << 17)
 
 /* Touch modes */
 #define XIDirectTouch                           1
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 8e2eea8..6ab2559 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -505,7 +505,8 @@ window set has been reached, the event is delivered:
 - otherwise, to the next parent window in the window set until a selection has
   been found.
 
-Emulated pointer events will have the PointerEmulated flag set.
+Emulated pointer events will have the PointerEmulated flag set. A touch
+event that emulates pointer events has the TouchEmulatingPointer flag set.
 
 [[glossary-notations]]
 Notations used in this document
@@ -2048,7 +2049,8 @@ 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 (touch events only): { TouchPendingEnd }
+    DEVICEEVENTFLAGS (touch events only): { TouchPendingEnd,
+                                            TouchEmulatingPointer }
 
 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
@@ -2108,6 +2110,8 @@ 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.
+        TouchEmulatingPointer is set on touch events that emulate pointer
+        events.
 
 Modifier state in mods is detailed as follows:
 

From 1306ccf9f262c0c699bec093ffdc4b6695601599 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 6 Jan 2012 13:35:25 +1000
Subject: [PATCH 336/388] inputproto 2.1.99.5

Signed-off-by: Peter Hutterer 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index efc5242..abd8355 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
 AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.1.99.4], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.1.99.5], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
 AM_INIT_AUTOMAKE([foreign dist-bzip2])
 AM_MAINTAINER_MODE
 

From 08ba2d4e1094fb196d1b7a7b3a3b27a81cb9834c Mon Sep 17 00:00:00 2001
From: Gaetan Nadon 
Date: Wed, 25 Jan 2012 17:03:11 -0500
Subject: [PATCH 337/388] specs: Edit titles for section 3 and 4

In the htlm version, the section number appeared to be 3.2.1 and
4.2.2 because of the generated section number.

A section title should not begin with a number.

Signed-off-by: Gaetan Nadon 
Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 6ab2559..b19d901 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -46,15 +46,15 @@ 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 in version 2.1
+----------------------
 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 in version 2.2
+----------------------
 Changes introduced by version 2.2
 
 XI 2.2 introduces support for multi-touch devices. The traditional

From 508a360f6530e75d94cd2999e56cb329b315ce5d Mon Sep 17 00:00:00 2001
From: Gaetan Nadon 
Date: Wed, 25 Jan 2012 17:03:14 -0500
Subject: [PATCH 338/388] specs: use subsections to group use cases description

It makes an entry in the appendix for quick navigation.
It looks more readable with subtitles.

Signed-off-by: Gaetan Nadon 
Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 56 +++++++++++++++++++++++-----------------------
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index b19d901..c148883 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2345,65 +2345,65 @@ 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
+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
+* 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
+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
+* 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
+* 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
+* 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
+* 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.
+* 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
+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
+* 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
+* 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
+* 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
+* 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
+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
+* 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.

From 9ff28b092f91ea1d7ff58f54a9404347f517361b Mon Sep 17 00:00:00 2001
From: Gaetan Nadon 
Date: Wed, 25 Jan 2012 17:03:12 -0500
Subject: [PATCH 339/388] specs: remove older manually typed in section number

These would come out in html as 5.2, 6.3 and 6.4.3.4

Signed-off-by: Gaetan Nadon 
Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index c148883..ec2afeb 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -93,8 +93,8 @@ alongside XI 2.2 touch events to support older clients; see Section
 
 //                            ❧❧❧❧❧❧❧❧❧❧❧
 
-2. Notations used in this document
-----------------------------------
+Notations used in this document
+-------------------------------
 
 Notation for requests:
 
@@ -127,8 +127,8 @@ or, if multiple of these fields exist:
 
 //                            ❧❧❧❧❧❧❧❧❧❧❧
 
-3. Interoperability between version 1.x and 2.0
------------------------------------------------
+Interoperability between version 1.x and 2.0
+--------------------------------------------
 
 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
@@ -169,8 +169,8 @@ 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
-~~~~~~~~~~~~~~~~~~~~
+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,

From f3d2feead483f6637ef8ff004afad55b5bbf2c62 Mon Sep 17 00:00:00 2001
From: Gaetan Nadon 
Date: Wed, 25 Jan 2012 17:03:13 -0500
Subject: [PATCH 340/388] specs: fix Appendix A title

This section starts a new numbered sequence.

Signed-off-by: Gaetan Nadon 
Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index ec2afeb..0eecb76 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2336,7 +2336,7 @@ is now the owner of the touch sequence specified by touchid.
         A bitmask of flags for this event.
 
 
-// FIXME: why do we get '11. Appendix A:' rather than just 'Appendix A:'?!
+:numbered!:
 [[xi22-usecases]]
 [appendix]
 XI 2.2 Use-cases

From 535a4377ddb4c2680d54b4cbbb273134bb5f58a3 Mon Sep 17 00:00:00 2001
From: Gaetan Nadon 
Date: Wed, 25 Jan 2012 17:03:15 -0500
Subject: [PATCH 341/388] specs: replace hard coded number in some "See
 section" references

The glossary does not accept <> however.

Signed-off-by: Gaetan Nadon 
Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 0eecb76..ca315c1 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -31,7 +31,8 @@ XI2 provides a number of enhancements over version 1.5, including:
 
 - use of XGE and GenericEvents. GenericEvents are of flexible length with a
   minimum length of 32 bytes.
-- explicit device hierarchy of master and slave devices. See Section 4.
+- explicit device hierarchy of master and slave devices. See Section
+<>.
 - use of multiple independent master devices (Multi-Poiner X or MPX).
 - the ability for devices to change capabilities at runtime.
 - raw device events
@@ -564,7 +565,8 @@ Data types
     DEVICEUSE { MasterPointer, MasterKeyboard, SlavePointer,
                 SlaveKeyboard, FloatingSlave }
             A DEVICEUSE field specifies the current use of a device in the MD/SD
-            device hierarchy. See Section 4 for more information.
+            device hierarchy. See Section "The Master/Slave device hierarchy"
+            for more information.
 
     EVENTMASK
             An EVENTMASK is a binary mask defined as (1 << event type).
@@ -1172,8 +1174,8 @@ Set the ClientPointer for the client owning win to the given device.
 Some protocol requests are ambiguous and the server has to choose a device
 to provide data for a request or a reply. By default, the server will
 choose a client's ClientPointer device to provide the data, unless the
-client currently has a grab on another device. See section 4.4 for more
-details.
+client currently has a grab on another device. See section
+<> for more details.
 
 If win is None, the ClientPointer for this client is set to the given
 device. Otherwise, if win is a valid window, the ClientPointer for the
@@ -1669,10 +1671,10 @@ 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.
+See section <> 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]]
     ┌───

From 556ea96060071ab807ece4f77304208e15f25f9b Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Thu, 26 Jan 2012 13:32:33 +1000
Subject: [PATCH 342/388] specs: move touch mode explanations to where it
 belongs

Rather than have two different explanations to the touch modes, remove it
from the "Changes in version 2.2" section and merge the content into the
text.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 21 +++++++--------------
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index ca315c1..15131dd 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -74,18 +74,6 @@ The additions in XI 2.2 aim to:
 - 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
@@ -420,13 +408,18 @@ 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
+    events are delivered to window at the location of the touch. "direct"
+    here refers to the user manipulating objects at their screen location,
+    e.g. touching an object and physically moving it. 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
+    location of the device's cursor and often need to be interpreted
+    relative to the current position of that cursor. Such interactions are
+    usually the result of a gesture performed on the device, rather than
+    direct manipulation. 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

From 92f769675b0e39c51280db9690db4b3d80637069 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Thu, 26 Jan 2012 13:33:40 +1000
Subject: [PATCH 343/388] specs: remove superfluous "Changes introduced by ..."

The line right above says the same thing.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 2 --
 1 file changed, 2 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 15131dd..518769a 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -49,14 +49,12 @@ device information in each event (with the exception of core events).
 
 Changes in version 2.1
 ----------------------
-Changes introduced by version 2.1
 
 - RawEvents are sent regardless of the grab state.
 - Addition of the ScrollClass for smooth scrolling
 
 Changes in version 2.2
 ----------------------
-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

From fc9372868bb772f38a6b17299ef26e3dc9c2ff87 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Thu, 26 Jan 2012 13:36:24 +1000
Subject: [PATCH 344/388] specs: move touch support details to "Touch device
 support" section

Keep the changelog small.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 43 +++++++++++++++++++++++--------------------
 1 file changed, 23 insertions(+), 20 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 518769a..90076b6 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -56,27 +56,8 @@ Changes in version 2.1
 Changes in 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.
+- Multitouch support added
 
-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.
-
-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
-<>.
 
 //                            ❧❧❧❧❧❧❧❧❧❧❧
 
@@ -283,6 +264,28 @@ ClientPointer to a different master pointer.
 Touch device support
 --------------------
 
+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.
+
+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
+<>.
+
 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

From 217afacda01b082f39fb6816e62ec20e4791857f Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Thu, 26 Jan 2012 13:56:38 +1000
Subject: [PATCH 345/388] specs: explain touch behaviour for dependent devices

Dependent devices don't send touch events until the interaction is a true
touch interaction (i.e. doesn't just serve to move the pointer). Once that
happens, all touchpoints send touch events exclusively. Pointer movement
restarts once we're down to one touch that controls the pointer again.

For clients listening to touch events in addition to pointer events, this
also means that a two-finger tap looks identical to holding one finger down
and tapping with a second-finger. Both actions will result in short
TouchBegin/TouchEnd sequences for both fingers.

The above is the default behaviour we expect from touchpads, the protocol is
more generically worded to leave more room for drivers to decide when a
touch only controls the pointer and when it doesn't.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 50 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 90076b6..21c7203 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -445,6 +445,56 @@ 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.
 
+Pointer control of dependent devices
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+On a dependent device, the device may differ between a pointer-controlling
+touch and a non-pointer-controlling touch. For example, on a touchpad the
+first touch is pointer-controlling (i.e. serves only to move the visible
+pointer). Multi-finger gestures on a touchpad cause all touches to be
+non-pointer-controlling.
+
+For pointer-controlling touches, no touch events are sent; the touch
+generates regular pointer events instead. Non-pointer-controlling touches
+send touch events. A touch may change from pointer-controlling to
+non-pointer-controlling, or vice versa.
+
+- If a touch changes from pointer-controlling to non-pointer-controlling,
+ a new touch ID is assigned and a TouchBegin is sent for the last known
+ position of the touch. Further events are sent as TouchUpdate events, or as
+ TouchEnd event if the touch terminates.
+
+- If a touch changes from non-pointer-controlling to pointer-controlling, a
+  TouchEnd is sent for that touch at the last known position of the touch.
+  Further events are sent as pointer events.
+
+The conditions to switch from pointer-controlling to non-pointer-controlling
+touch is implementation-dependent. A device may support touches that are
+both pointer-controlling and a touch event.
+
+.Dependent touch example event sequence on a touchpad, touches are marked
+when switching to pointer-controlling (pc) or to non-pointer-controlling (np)
+[width="50%", options="header"]
+|====================================================
+| Finger 1 | Finger 2 | Event generated(touchid)
+|  down    |          | Motion
+|  move    |          | Motion
+|  move    |          | Motion
+|  (np)    |   down   | TouchBegin(0), TouchBegin(1)
+|  move    |    --    | TouchUpdate(0)
+|   --     |   move   | TouchUpdate(1)
+|   up     |   (pc)   | TouchEnd(0), TouchEnd(1)
+|          |   move   | Motion
+|  down    |   (np)   | TouchBegin(2), TouchBegin(3)
+|  move    |    --    | TouchUpdate(2)
+|   up     |   (pc)   | TouchEnd(2), TouchEnd(3)
+|          |    up    | Motion
+|  down    |          | Motion
+|  (np)    |   down   | TouchBegin(4), TouchBegin(5)
+|  (pc)    |    up    | TouchEnd(4), TouchEnd(5)
+|  move    |          | Motion
+|   up     |          | Motion
+|====================================================
+
 
 [[multitouch-emulation]]
 Pointer emulation from multitouch events

From 5e18f74e24a17d6a1f18339600a00f5591dc6a82 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 8 Feb 2012 03:17:28 +1000
Subject: [PATCH 346/388] Unbreak protocol ABI for XIAllowEvents - inputproto
 2.1.99.6

XIAllowEvents was extended with touchid and grab_window in
2ea2f99f4fe1dcd3b8e539ca41c482fc40a0533d. This extended the size of
the request from 12 to 20 but also broke the ABI. Older server
match the request size exactly, so compiling libXi 1.5 against
inputproto 2.2 and then running it against a pre-XI 2.2 server causes a
BadLength for any XIAllowEvent request.

Add a new request for the new data.

Signed-off-by: Peter Hutterer 
Reviewed-by: Keith Packard 
---
 XI2proto.h   | 19 +++++++++++++++++--
 configure.ac |  2 +-
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/XI2proto.h b/XI2proto.h
index 93d7e32..733f923 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -639,6 +639,21 @@ typedef struct {
 /**
  * Allow or replay events on the specified grabbed device.
  */
+typedef struct {
+    uint8_t     reqType;
+    uint8_t     ReqType;                /**< Always ::X_XIAllowEvents */
+    uint16_t    length;                 /**< Length in 4 byte units */
+    Time        time;
+    uint16_t    deviceid;
+    uint8_t     mode;
+    uint8_t     pad;
+} xXIAllowEventsReq;
+#define sz_xXIAllowEventsReq                   12
+
+/**
+ * Allow or replay events on the specified grabbed device.
+ * Since XI 2.2
+ */
 typedef struct {
     uint8_t     reqType;
     uint8_t     ReqType;                /**< Always ::X_XIAllowEvents */
@@ -649,8 +664,8 @@ typedef struct {
     uint8_t     pad;
     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 */
+} xXI2_2AllowEventsReq;
+#define sz_xXI2_2AllowEventsReq                20
 
 
 /**
diff --git a/configure.ac b/configure.ac
index abd8355..028538b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
 AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.1.99.5], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.1.99.6], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
 AM_INIT_AUTOMAKE([foreign dist-bzip2])
 AM_MAINTAINER_MODE
 

From 9a2e10213c996010124a3d58e71140f41202416c Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 29 Feb 2012 14:56:37 +1000
Subject: [PATCH 347/388] =?UTF-8?q?specs:=20fix=20typos=20'hierachy'=20?=
 =?UTF-8?q?=E2=86=92=20'hierarchy'?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 21c7203..e438fd0 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -32,7 +32,7 @@ XI2 provides a number of enhancements over version 1.5, including:
 - use of XGE and GenericEvents. GenericEvents are of flexible length with a
   minimum length of 32 bytes.
 - explicit device hierarchy of master and slave devices. See Section
-<>.
+<>.
 - use of multiple independent master devices (Multi-Poiner X or MPX).
 - the ability for devices to change capabilities at runtime.
 - raw device events
@@ -176,14 +176,14 @@ 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.
 
-[[hierachy]]
+[[hierarchy]]
 The Master/Slave device hierarchy
 ---------------------------------
 
 XI2 introduces a device hierarchy split up into so-called Master Devices (MD)
 and Slave Devices (SD).
 
-[[hierachy-master]]
+[[hierarchy-master]]
 Master devices
 ~~~~~~~~~~~~~~
 An MD is a virtual device created and managed by the server. MDs may send core
@@ -197,7 +197,7 @@ 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).
 
-[[hierachy-slave]]
+[[hierarchy-slave]]
 Slave devices
 ~~~~~~~~~~~~~
 An SD is usually a physical device configured in the server. SDs are not
@@ -217,7 +217,7 @@ If an event is generated by an SD
   Both the sprite and the focus must be managed explicitly by the client
   program.
 
-[[hierachy-dcce]]
+[[hierarchy-dcce]]
 Event processing for attached slave devices
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -1093,7 +1093,7 @@ or the device is removed, whichever comes earlier.
 If deviceid does not specify a master pointer, a BadDevice error
 is returned.
 
-[[requests-changehierachy]]
+[[requests-changehierarchy]]
     ┌───
         XIChangeHierarchy
             num_changes:     CARD8
@@ -1130,7 +1130,7 @@ is returned.
                   deviceid:   DEVICEID }
 
 XIChangeHierarchy allows a client to modify the
-<>.
+<>.
 
     num_changes
         The number of changes to apply to the current hierarchy.
@@ -1975,7 +1975,7 @@ All events have a set of common fields specified as EVENTHEADER.
 Events introduced in version 2.0
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-[[events-hierachyevent]]
+[[events-hierarchyevent]]
     ┌───
         HierarchyEvent:
             EVENTHEADER

From 883143e3454c7fe44b12b11fc12ff3ec2267ecd1 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 2 Mar 2012 09:32:18 +1000
Subject: [PATCH 348/388] specs: some wording fixes

Button press events are insufficient even on scroll wheels, so don't say
they are good enough.

Remove duplicate claim of event emulation

Don't claim we send touch events "without delay"

Touch screens hardly ever "physically move" an object.

Hyphenate "implementation-dependent"

Remove unnecessary "however"

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 23 ++++++++++-------------
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index e438fd0..b50e67d 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -143,10 +143,9 @@ 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.
+right.  This is insufficient for e.g. 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 scrolling information through valuators to
 provide clients with more precision than the legacy button events. This
@@ -276,7 +275,6 @@ 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.
 
@@ -376,7 +374,7 @@ 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
+touch events as they occur on the device. 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
@@ -410,9 +408,8 @@ 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. "direct"
-    here refers to the user manipulating objects at their screen location,
-    e.g. touching an object and physically moving it. An example
-    of a DirectTouch device is a touchscreen.
+    here refers to the user manipulating objects at their screen location.
+    An example of a DirectTouch device is a touchscreen.
 
 'DependentTouch':
     These devices do not have a direct correlation between a touch location and
@@ -502,7 +499,7 @@ 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.
+sequence emulates pointer events is implementation-dependent.
 
 Pointer events are emulated as follows:
 
@@ -1315,7 +1312,7 @@ 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.  This request does not, however, affect the processing of XI 2.2
+device.  This request does not affect the processing of XI 2.2
 touch events.
 
     deviceid
@@ -1687,8 +1684,8 @@ 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, XIGrabtypeFocusIn, XIGrabtypeTouchBegin, or
-XIGrabtypeTouchBeginInert with the same grab_window and the same
+grab_type XIGrabtypeEnter, XIGrabtypeFocusIn, or
+XIGrabtypeTouchBegin 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.

From 0d7bfc10bffa29de1b7217d6399e8f0d5b24c579 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 2 Mar 2012 09:55:21 +1000
Subject: [PATCH 349/388] specs: Formatting fix

asciidoc requires caption to be on one line but this one here is too long.
Split it up instead.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index b50e67d..6b7c174 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -468,8 +468,10 @@ The conditions to switch from pointer-controlling to non-pointer-controlling
 touch is implementation-dependent. A device may support touches that are
 both pointer-controlling and a touch event.
 
-.Dependent touch example event sequence on a touchpad, touches are marked
-when switching to pointer-controlling (pc) or to non-pointer-controlling (np)
+In the dependent touch example event sequence below, touches are marked when
+switching to pointer-controlling (pc) or to non-pointer-controlling (np).
+
+.Dependent touch example event sequence on a touchpad
 [width="50%", options="header"]
 |====================================================
 | Finger 1 | Finger 2 | Event generated(touchid)

From 000a20296a3c52f4232aa466d29faa2e424ca626 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 2 Mar 2012 10:07:21 +1000
Subject: [PATCH 350/388] specs: XITouchClass doesn't have properties

Leftover from an earlier version.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 6b7c174..15b6b8d 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -740,9 +740,7 @@ If major_version is less than 2, a BadValue error occurs.
                   length:               CARD16
                   sourceid:             CARD16
                   mode:                 TOUCHMODE
-                  num_touches:          CARD16
-                  num_props:            CARD16
-                  props:                LISTofATOM }
+                  num_touches:          CARD16 }
 
     TOUCHMODE { DirectTouch, DependentTouch }
 
@@ -886,10 +884,6 @@ exist per ValuatorClass.
         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.

From 4de6f26a705062343f5b93dd9827a736c721e265 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 2 Mar 2012 10:08:33 +1000
Subject: [PATCH 351/388] =?UTF-8?q?specs:=20replace=20=E2=80=A0=20with=20?=
 =?UTF-8?q?=C2=B2?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

† looks too much like a letter and we can't use * and ** because asciidoc
interprets it as lists.

Use numbers instead, and replace all current * with ¹.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 15b6b8d..f3a81c9 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -724,7 +724,7 @@ If major_version is less than 2, a BadValue error occurs.
                   resolution:           CARD32
                   mode:                 CARD8 }
 
-    SCROLLCLASS* {type:                 ScrollClass
+    SCROLLCLASS¹ {type:                 ScrollClass
                   length:               CARD16
                   sourceid:             CARD16
                   axisnumber:           CARD16
@@ -736,7 +736,7 @@ If major_version is less than 2, a BadValue error occurs.
 
     SCROLLFLAGS { NoEmulation, Preferred }
 
-    TOUCHCLASS† { type:                 TouchClass
+    TOUCHCLASS² { type:                 TouchClass
                   length:               CARD16
                   sourceid:             CARD16
                   mode:                 TOUCHMODE
@@ -744,8 +744,8 @@ If major_version is less than 2, a BadValue error occurs.
 
     TOUCHMODE { DirectTouch, DependentTouch }
 
-    * since XI 2.1
-    † since XI 2.2
+    ¹ since XI 2.1
+    ² since XI 2.2
 
 XIQueryDevice details information about the requested input devices.
 
@@ -1410,13 +1410,13 @@ active device grab becomes not viewable.
             time:            TIMESTAMP or CurrentTime
             event_mode:      { AsyncDevice, SyncDevice,
                                AsyncPairedDevice, SyncPairedDevice,
-                               ReplayDevice, AsyncPair, SyncPair, AcceptTouch*,
-                               RejectTouch* }
-            touchid*:        CARD32
-            grab_window*:    Window
+                               ReplayDevice, AsyncPair, SyncPair, AcceptTouch¹,
+                               RejectTouch¹ }
+            touchid¹:        CARD32
+            grab_window¹:    Window
     └───
 
-* since XI 2.2
+    ¹ since XI 2.2
 
 The XIAllowEvents request releases some queued events if the client
 has caused a device to freeze. It also is used to handle touch grab and
@@ -1535,7 +1535,7 @@ you pass to the event-mode argument:
             grab_window:     Window
             cursor:          Cursor
             owner_events:    Bool
-            grab_mode:       { Synchronous, Asynchronous, Touch* }
+            grab_mode:       { Synchronous, Asynchronous, Touch¹ }
             paired_device_mode: { Synchronous, Asynchronous }
             num_modifiers:   INT16
             mask_len:        CARD16
@@ -1552,7 +1552,7 @@ you pass to the event-mode argument:
         GRABMODIFIERINFO {   status:    Access
                              modifiers: CARD32 }
 
-* since XI 2.2
+    ¹ since XI 2.2
 
 Establish an explicit passive grab for a button or keycode
 on the specified input device.
@@ -2200,7 +2200,7 @@ Touch events do not generate enter/leave events.
         RawEvent
             EVENTHEADER
             detail:                    CARD32
-            sourceid*:                 DEVICEID
+            sourceid¹:                 DEVICEID
             flags:                     DEVICEEVENTFLAGS
             valuators_len:             CARD16
             valuators:                 SETofVALUATORMASK
@@ -2208,7 +2208,7 @@ Touch events do not generate enter/leave events.
             axisvalues_raw:            LISTofFP3232
     └───
 
-    * since XI 2.1
+    ¹ 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
@@ -2227,7 +2227,7 @@ when the device is grabbed by another client.
     eventtype
         The type of event that occured on the device.
     detail
-        The button number, keycode or touch ID*.
+        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.
@@ -2242,7 +2242,7 @@ when the device is grabbed by another client.
     axisvalues_raw
         Untransformed valuator data in device-native resolution.
 
-* since XI 2.2
+    ¹ since XI 2.2
 
 [[events-enterleave]]
     ┌───

From 3773e33579f0b5bd6de9f01481b8608fa3101a2b Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 2 Mar 2012 10:19:42 +1000
Subject: [PATCH 352/388] specs: formatting fix, move AcceptTouch and
 RejectTouch onto their own line

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index f3a81c9..2155cf1 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1410,8 +1410,8 @@ active device grab becomes not viewable.
             time:            TIMESTAMP or CurrentTime
             event_mode:      { AsyncDevice, SyncDevice,
                                AsyncPairedDevice, SyncPairedDevice,
-                               ReplayDevice, AsyncPair, SyncPair, AcceptTouch¹,
-                               RejectTouch¹ }
+                               ReplayDevice, AsyncPair, SyncPair,
+                               AcceptTouch¹, RejectTouch¹ }
             touchid¹:        CARD32
             grab_window¹:    Window
     └───

From b321ea46fbb251970c2d655b73209750f24c0b8e Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 2 Mar 2012 10:21:12 +1000
Subject: [PATCH 353/388] specs: GrabtypeTouchBegin was added in XI 2.2

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 2155cf1..622c706 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1547,7 +1547,7 @@ you pass to the event-mode argument:
     └───
 
         GRABTYPE         { GrabtypeButton, GrabtypeKeycode, GrabtypeEnter,
-                           GrabtypeFocusIn, GrabtypeTouchBegin }
+                           GrabtypeFocusIn, GrabtypeTouchBegin¹ }
 
         GRABMODIFIERINFO {   status:    Access
                              modifiers: CARD32 }

From b1458f6fa9952365f4ad86dc87b385d467318fb1 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 2 Mar 2012 10:25:03 +1000
Subject: [PATCH 354/388] specs: fix link to touch ownership section

Introduced in 535a4377ddb4c2680d54b4cbbb273134bb5f58a3

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 622c706..3090ac8 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1708,10 +1708,11 @@ before the grab deactivates.
 For GrabtypeTouchBegin, grab_mode must be Touch or a BadValue error
 is generated.
 
-See section <> 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.
+See section <> 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]]
     ┌───

From a09ca92ce31ede86b883cb74fb1767f8ed687ca5 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 2 Mar 2012 10:26:04 +1000
Subject: [PATCH 355/388] specs: whitespace fix to avoid wrong asciidoc
 formatting

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 3090ac8..ba3d856 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2097,7 +2097,7 @@ 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.
+XI 2.2: The event type may also be TouchBegin, TouchUpdate, or TouchEnd.
 
     detail
         The button number, key code, touch ID, or 0.
@@ -2170,9 +2170,8 @@ 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
+In servers supporting 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

From b42e4d24a26fb8467ed54183480c9dacd66fc804 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 2 Mar 2012 10:28:46 +1000
Subject: [PATCH 356/388] specs: remove TouchOwnership mention from DeviceEvent

TouchOwnership is described separately below.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index ba3d856..b9a68ee 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2175,8 +2175,7 @@ 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.
+in a TouchUpdate event being sent with zero valuators.
 
 The average finger size is significantly larger than one pixel. The
 selection of the hotspot of a touchpoint is implementation dependent and

From 3ac053f2c7ef8d07b4a6dcb64d8ca47edad15716 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 2 Mar 2012 10:31:26 +1000
Subject: [PATCH 357/388] specs: remove "since" from TouchOwnershipEvent

It's already in a section "Events introduced in version 2.2"

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index b9a68ee..024b107 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2346,7 +2346,7 @@ Events introduced in version 2.2
 
 [[events-touchownershipevent]]
     ┌───
-        TouchOwnershipEvent (since XI 2.2):
+        TouchOwnershipEvent
             EVENTHEADER
             touchid:                    CARD32
             root:                       Window

From 950a7a0b2e733d9713a88612b669603b0c155329 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 29 Feb 2012 14:55:26 +1000
Subject: [PATCH 358/388] specs: Remove work in progress warning

We're close enough to a release now.

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 2 --
 1 file changed, 2 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 024b107..11fc39c 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -3,8 +3,6 @@ The X Input Extension 2.x
 :toc:
 :numbered:
 
-.This is a work in progress!
-
 Authors:
 
 - Peter Hutterer (Red Hat) 

From b02b0b42e266560bd48f7e8f38c8338417394fd0 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 29 Feb 2012 15:08:01 +1000
Subject: [PATCH 359/388] specs: XI 2.2 release date is March 2012

Signed-off-by: Peter Hutterer 
Reviewed-by: Chase Douglas 
---
 specs/XI2proto.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 11fc39c..fb32768 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -13,7 +13,7 @@ Authors:
 History 
 -------
 
-- v2.2, ??: Multitouch support added
+- v2.2, March 2012: Multitouch support added
 - v2.1, December 2011: new raw event behaviour, smooth scrolling support
   added
 - v2.0, October 2009: Initial release of XI2 protocol

From e752e92dbdcf01b1cd46a3853f582ff765d19e90 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 2 Mar 2012 12:58:18 +1000
Subject: [PATCH 360/388] inputproto 2.2

Signed-off-by: Peter Hutterer 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 028538b..1c74810 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
 AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.1.99.6], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.2], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
 AM_INIT_AUTOMAKE([foreign dist-bzip2])
 AM_MAINTAINER_MODE
 

From 3ed8aed32199edaa8621ccea571a04883e050cb5 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Thu, 14 Jun 2012 08:56:55 +1000
Subject: [PATCH 361/388] Fix two typos in spec/comments

The ButtonClass provides the number of buttons, not the lentgh of the mask.

Signed-off-by: Peter Hutterer 
---
 XI2proto.h         | 2 +-
 specs/XI2proto.txt | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/XI2proto.h b/XI2proto.h
index 733f923..1260200 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -154,7 +154,7 @@ typedef struct {
     uint16_t    type;           /**< Always ButtonClass */
     uint16_t    length;         /**< Length in 4 byte units */
     uint16_t    sourceid;       /**< source device for this class */
-    uint16_t    num_buttons;    /**< Number of buttons provide */
+    uint16_t    num_buttons;    /**< Number of buttons provided */
 } xXIButtonInfo;
 
 /**
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index fb32768..76d7695 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -701,7 +701,7 @@ If major_version is less than 2, a BadValue error occurs.
     BUTTONCLASS { type:                 ButtonClass
                   length:               CARD16
                   sourceid:             CARD16
-                  buttons_len:          CARD16
+                  num_buttons:          CARD16
                   state:                SETofBUTTONMASK
                   labels:               LISTofATOM }
 

From 74098071768a4b25670cf5582bc68433403deefe Mon Sep 17 00:00:00 2001
From: Ran Benita 
Date: Sat, 27 Oct 2012 14:56:48 +0200
Subject: [PATCH 362/388] specs: XI2: make event/request name formatting
 consistent

None of the other have ':' there.

Signed-off-by: Ran Benita 
Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 76d7695..2547692 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -639,8 +639,8 @@ Errors are sent using core X error reports.
 
 
 [[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
@@ -1403,7 +1403,7 @@ active device grab becomes not viewable.
 
 [[requests-allowevents]]
     ┌───
-        XIAllowEvents:
+        XIAllowEvents
             deviceid:        DEVICEID
             time:            TIMESTAMP or CurrentTime
             event_mode:      { AsyncDevice, SyncDevice,
@@ -1969,7 +1969,7 @@ Events introduced in version 2.0
 
 [[events-hierarchyevent]]
     ┌───
-        HierarchyEvent:
+        HierarchyEvent
             EVENTHEADER
             flags:                      SETofHIERARCHYMASK
             num_info:                   CARD16
@@ -2017,7 +2017,7 @@ device. Clients should ignore deviceid and instead use the devices list.
 
 [[events-devicechangedevent]]
     ┌───
-        DeviceChangedEvent:
+        DeviceChangedEvent
             EVENTHEADER
             reason:                CHANGEREASON
             source:                DEVICEID
@@ -2051,7 +2051,7 @@ For a detailed description of classes, see the XIQueryDevice request.
 
 [[events-deviceevent]]
     ┌───
-        DeviceEvent:
+        DeviceEvent
             EVENTHEADER
             detail:                     CARD32
             root:                       Window

From a06905c8efc053e8ffcd0fc93736c0e45b715c38 Mon Sep 17 00:00:00 2001
From: Ran Benita 
Date: Sat, 27 Oct 2012 14:56:49 +0200
Subject: [PATCH 363/388] specs: XI2: add titles to requests/events and show
 them in TOC

You often want to quickly jump to the specification of a specific
request/event, so add them to the table of contents to allow for that.
This also provides the reader with a quick glance at what the protocol
looks like.

Signed-off-by: Ran Benita 
Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 57 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 2547692..376a6bb 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1,5 +1,6 @@
 The X Input Extension 2.x
 =========================
+:toclevels: 3
 :toc:
 :numbered:
 
@@ -655,6 +656,8 @@ Requests introduced in version 2.0
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 [[requests-queryversion]]
+XIQueryVersion
+^^^^^^^^^^^^^^
     ┌───
         XIQueryVersion
         major_version:          CARD16
@@ -679,6 +682,8 @@ server supports a version which is compatible with its expectations.
 If major_version is less than 2, a BadValue error occurs.
 
 [[requests-querydevice]]
+XIQueryDevice
+^^^^^^^^^^^^^
     ┌───
         XIQueryDevice
         DEVICE                  deviceid
@@ -887,6 +892,8 @@ Devices with a TouchClass emit touch events with the same axes as pointer
 events.
 
 [[requests-selectevents]]
+XISelectEvents
+^^^^^^^^^^^^^^
     ┌───
         XISelectEvents
             window:         Window
@@ -938,6 +945,8 @@ specific device when another client has a selection for XIAllDevices), a
 BadAccess error occurs.
 
 [[requests-getselectedevents]]
+XIGetSelectedEvents
+^^^^^^^^^^^^^^^^^^^
     ┌───
         XIGetSelectedEvents
             window:         Window
@@ -962,6 +971,8 @@ If num_masks is 0, no events have been selected by this client on the
 given window.
 
 [[requests-querypointer]]
+XIQueryPointer
+^^^^^^^^^^^^^^
     ┌───
         XIQueryPointer
             window:         Window
@@ -1007,6 +1018,8 @@ If the device is not a master pointer device or not a floating slave
 pointer, a BadDevice error results.
 
 [[requests-warppointer]]
+XIWarpPointer
+^^^^^^^^^^^^^
     ┌───
         XIWarpPointer
             src_win:         Window
@@ -1053,6 +1066,8 @@ This request will generate events just as if the user had instantaneously
 moved the pointer.
 
 [[requests-changecursor]]
+XIChangeCursor
+^^^^^^^^^^^^^^
     ┌───
         XIChangeCursor
             win:             Window
@@ -1085,6 +1100,8 @@ If deviceid does not specify a master pointer, a BadDevice error
 is returned.
 
 [[requests-changehierarchy]]
+XIChangeHierarchy
+^^^^^^^^^^^^^^^^^
     ┌───
         XIChangeHierarchy
             num_changes:     CARD8
@@ -1193,6 +1210,8 @@ selection will be canceled.
         Deviceid of the slave device.
 
 [[requests-setclientpointer]]
+XISetClientPointer
+^^^^^^^^^^^^^^^^^^
     ┌───
         XISetClientPointer
             win:             Window
@@ -1225,6 +1244,8 @@ If window does not specify a valid window or client ID and is not None, a
 BadWindow error is returned.
 
 [[requests-getclientpointer]]
+XIGetClientPointer
+^^^^^^^^^^^^^^^^^^
     ┌───
         XIGetClientPointer
             win:             Window
@@ -1247,6 +1268,8 @@ XISetClientPointer and a ClientPointer implicitly assigned by the server
 in response to an ambiguous request.
 
 [[requests-setfocus]]
+XISetFocus
+^^^^^^^^^^
     ┌───
         XISetFocus
             focus:           Window
@@ -1278,6 +1301,8 @@ 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
+^^^^^^^^^^
     ┌───
         XIGetFocus
             deviceid:        DEVICEID
@@ -1288,6 +1313,8 @@ Otherwise, the last-focus-change time is set to the specified time.
 Return the current focus window for the given device.
 
 [[requests-grabdevice]]
+XIGrabDevice
+^^^^^^^^^^^^
     ┌───
         XIGrabDevice
             deviceid:        DEVICEID
@@ -1379,6 +1406,8 @@ This request fails and returns:
 To release a grab of a device, use XIUngrabDevice.
 
 [[requests-ungrabdevice]]
+XIUngrabDevice
+^^^^^^^^^^^^^^
     ┌───
         XIUngrabDevice
             deviceid:        DEVICEID
@@ -1402,6 +1431,8 @@ An XIUngrabDevice is performed automatically if the event window for an
 active device grab becomes not viewable.
 
 [[requests-allowevents]]
+XIAllowEvents
+^^^^^^^^^^^^^
     ┌───
         XIAllowEvents
             deviceid:        DEVICEID
@@ -1525,6 +1556,8 @@ you pass to the event-mode argument:
         sequence, ownership will be passed on to the next listener.
 
 [[requests-passivegrabdevice]]
+XIPassiveGrabDevice
+^^^^^^^^^^^^^^^^^^^
     ┌───
         XIPassiveGrabDevice
             deviceid:        DEVICE
@@ -1713,6 +1746,8 @@ events continues even if the device is frozen due to a grab by another
 client.
 
 [[requests-passiveungrabdevice]]
+XIPassiveUngrabDevice
+^^^^^^^^^^^^^^^^^^^^^
     ┌───
         XIPassiveUngrabDevice
             deviceid:        DEVICEID
@@ -1745,6 +1780,8 @@ of the same type, same button or keycode (if applicable) and modifier
 combination on the grab_window.
 
 [[requests-listproperties]]
+XIListProperties
+^^^^^^^^^^^^^^^^
     ┌───
         XIListProperties
             deviceid:        DEVICEID
@@ -1763,6 +1800,8 @@ List the properties associated with the given device.
             All properties on the device.
 
 [[requests-changeproperty]]
+XIChangeProperty
+^^^^^^^^^^^^^^^^
     ┌───
         XIChangeProperty
             deviceid:        DEVICEID
@@ -1811,6 +1850,8 @@ property, use XIDeleteProperty.
 This request generates an XIPropertyEvent.
 
 [[requests-deleteproperty]]
+XIDeleteProperty
+^^^^^^^^^^^^^^^^
     ┌───
         XIDeleteProperty
             deviceid:        DEVICEID
@@ -1828,6 +1869,8 @@ 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
+^^^^^^^^^^^^^
     ┌───
         XIGetProperty
             deviceid:        DEVICEID
@@ -1968,6 +2011,8 @@ Events introduced in version 2.0
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 [[events-hierarchyevent]]
+HierarchyEvent
+^^^^^^^^^^^^^^
     ┌───
         HierarchyEvent
             EVENTHEADER
@@ -2016,6 +2061,8 @@ deviceid in an XIHierarchyEvent is always the first affected
 device. Clients should ignore deviceid and instead use the devices list.
 
 [[events-devicechangedevent]]
+DeviceChangedEvent
+^^^^^^^^^^^^^^^^^^
     ┌───
         DeviceChangedEvent
             EVENTHEADER
@@ -2050,6 +2097,8 @@ master device, or by a physical device changing capabilities at runtime.
 For a detailed description of classes, see the XIQueryDevice request.
 
 [[events-deviceevent]]
+DeviceEvent
+^^^^^^^^^^^
     ┌───
         DeviceEvent
             EVENTHEADER
@@ -2193,6 +2242,8 @@ physical buttons only, even if that sequence is emulating pointer events.
 Touch events do not generate enter/leave events.
 
 [[events-rawevent]]
+RawEvent
+^^^^^^^^
     ┌───
         RawEvent
             EVENTHEADER
@@ -2242,6 +2293,8 @@ when the device is grabbed by another client.
     ¹ since XI 2.2
 
 [[events-enterleave]]
+Enter or Leave or FocusIn or FocusOut
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     ┌───
         Enter or Leave or FocusIn or FocusOut
             EVENTHEADER
@@ -2323,6 +2376,8 @@ zero if the device is a floating slave device.
         Button state before the event.
 
 [[events-propertyevent]]
+XIPropertyEvent
+^^^^^^^^^^^^^^^
     ┌───
         XIPropertyEvent
             EVENTHEADER
@@ -2343,6 +2398,8 @@ Events introduced in version 2.2
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 [[events-touchownershipevent]]
+TouchOwnershipEvent
+^^^^^^^^^^^^^^^^^^^
     ┌───
         TouchOwnershipEvent
             EVENTHEADER

From 743cb2cf1567cf685dfe5444621eb56447768c7c Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 2 Nov 2012 15:37:28 +1000
Subject: [PATCH 364/388] XI2proto: spec formatting fix

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 376a6bb..f425d7c 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2209,7 +2209,8 @@ Modifier state in mods is detailed as follows:
     locked_mods
         XKB locked modifier state.
 
-    Group state in group is detailed as follows:
+Group state in group is detailed as follows:
+
     base_group
         XKB base group state.
     latched_group

From b30e7221b8888b674e6889beeada9b5b9dfc2f34 Mon Sep 17 00:00:00 2001
From: Daniel Martin 
Date: Wed, 7 Nov 2012 12:41:47 +0100
Subject: [PATCH 365/388] specs: XI2: Fix typos

Signed-off-by: Daniel Martin 
Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index f425d7c..d239254 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -32,7 +32,7 @@ XI2 provides a number of enhancements over version 1.5, including:
   minimum length of 32 bytes.
 - explicit device hierarchy of master and slave devices. See Section
 <>.
-- use of multiple independent master devices (Multi-Poiner X or MPX).
+- use of multiple independent master devices (Multi-Pointer X or MPX).
 - the ability for devices to change capabilities at runtime.
 - raw device events
 
@@ -616,7 +616,7 @@ Data types
 
     FP1616
             Fixed point decimal in 16.16 format as one INT16 and one CARD16.
-            The INT16 contains the integral part, the CARD32 the decimal fraction
+            The INT16 contains the integral part, the CARD16 the decimal fraction
             shifted by 16.
 
     FP3232
@@ -1794,9 +1794,9 @@ List the properties associated with the given device.
 
         deviceid
             The device to list the properties for.
-        num_atoms
-            Number of atoms in the reply
-        atoms
+        num_properties
+            Number of properties in the reply
+        properties
             All properties on the device.
 
 [[requests-changeproperty]]

From eb38fd9af846afe39287d5cf281b0274f42e8558 Mon Sep 17 00:00:00 2001
From: Daniel Martin 
Date: Wed, 7 Nov 2012 12:41:48 +0100
Subject: [PATCH 366/388] specs: XI2: Rename AxisClass to ValuatorClass

ValuatorClass is the XI2 term for AxisClass.

Signed-off-by: Daniel Martin 
Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 72 +++++++++++++++++++++++-----------------------
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index d239254..3c88891 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -701,39 +701,39 @@ XIQueryDevice
                  name:                  LISTofCHAR8
                  classes:               LISTofCLASS }
 
-    CLASS { BUTTONCLASS, KEYCLASS, AXISCLASS, SCROLLCLASS, TOUCHCLASS }
+    CLASS { BUTTONCLASS, KEYCLASS, VALUATORCLASS, SCROLLCLASS, TOUCHCLASS }
 
-    BUTTONCLASS { type:                 ButtonClass
-                  length:               CARD16
-                  sourceid:             CARD16
-                  num_buttons:          CARD16
-                  state:                SETofBUTTONMASK
-                  labels:               LISTofATOM }
+    BUTTONCLASS   { type:                 ButtonClass
+                    length:               CARD16
+                    sourceid:             CARD16
+                    num_buttons:          CARD16
+                    state:                SETofBUTTONMASK
+                    labels:               LISTofATOM }
 
-    KEYCLASS    { type:                 KeyClass
-                  length:               CARD16
-                  sourceid:             CARD16
-                  num_keys:             CARD16
-                  keys:                 LISTofCARD32 }
+    KEYCLASS      { type:                 KeyClass
+                    length:               CARD16
+                    sourceid:             CARD16
+                    num_keys:             CARD16
+                    keys:                 LISTofCARD32 }
 
-    AXISCLASS   { type:                 AxisClass
-                  length:               CARD16
-                  sourceid:             CARD16
-                  axisnumber:           CARD16
-                  label:                ATOM
-                  min:                  FP3232
-                  max:                  FP3232
-                  value:                FP3232
-                  resolution:           CARD32
-                  mode:                 CARD8 }
+    VALUATORCLASS { type:                 ValuatorClass
+                    length:               CARD16
+                    sourceid:             CARD16
+                    number:               CARD16
+                    label:                ATOM
+                    min:                  FP3232
+                    max:                  FP3232
+                    value:                FP3232
+                    resolution:           CARD32
+                    mode:                 CARD8 }
 
-    SCROLLCLASS¹ {type:                 ScrollClass
-                  length:               CARD16
-                  sourceid:             CARD16
-                  axisnumber:           CARD16
-                  scroll_type:          SCROLLTYPE
-                  flags:                SETofSCROLLFLAGS
-                  increment:            FP3232 }
+    SCROLLCLASS¹  { type:                 ScrollClass
+                    length:               CARD16
+                    sourceid:             CARD16
+                    number:               CARD16
+                    scroll_type:          SCROLLTYPE
+                    flags:                SETofSCROLLFLAGS
+                    increment:            FP3232 }
 
     SCROLLTYPE { Vertical, Horizontal }
 
@@ -825,15 +825,15 @@ The following classes may occur only once: ButtonClass, KeyClass
     keys
         List of keycodes provided.
 
-    AxisClass:
+    ValuatorClass:
     type
-        Always AxisClass.
+        Always ValuatorClass.
     length
         Length in 4 byte units.
     sourceid
         The device this class originates from.
-    axisnumber
-        Axis number of this axis. The axis number is in device-native
+    number
+        Valuator number of this axis. The valuator number is in device-native
         order and potential axis mappings are ignored.
     label
         Atom specifying the axis name. An Atom of None specifies an unlabeled
@@ -855,8 +855,8 @@ client. If no min and max information is available, both must be 0.
     ScrollClass:
     type
         Always ScrollClass.
-    axisnumber
-        Axis number that is referred to. This axis number must be listed in
+    number
+        Valuator number that is referred to. This valuator number must be listed in
         the ValuatorClassInfo.
     scroll_type:
         Vertical for a vertical scrolling axis, Horizontal for a horizontal
@@ -871,7 +871,7 @@ client. If no min and max information is available, both must be 0.
         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
+and each valuator number listed in any ScrollClass. Only one ScrollClass may
 exist per ValuatorClass.
 
     TouchClass:

From 377efaaa9828b4004741744ae172a193b5483a34 Mon Sep 17 00:00:00 2001
From: Daniel Martin 
Date: Wed, 7 Nov 2012 12:41:49 +0100
Subject: [PATCH 367/388] specs: XI2: Fix mods in XIPassive(Un)GrabDevice

XIPassiveGrabDevice and XIPassiveUngrabDevice are using lists of
modifier masks. This one corrects these types.

MODIFIERMASK was introduced, because a SETofMODIFIERMASK differs from a
SETofKEYMASK: AnyModifier=(1<<15) vs. GrabAnyModifier=(1U<<31).

Signed-off-by: Daniel Martin 
Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 3c88891..c018026 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -624,6 +624,11 @@ Data types
             The INT32 contains the integral part, the CARD32 the decimal fraction
             shifted by 32.
 
+    MODIFIERMASK
+            A MODIFIERMASK is a binary mask defined as (1 << modifier map index).
+            A SETofMODIFIERMASK is a binary OR of zero or more MODIFIERMASK or
+            GrabAnyModifier.
+
     VALUATORMASK
             A binary mask defined as (1 << valuator number).
             A SETofVALUATORMASK is a binary OR of zero or more VALUATORMASK.
@@ -1571,17 +1576,17 @@ XIPassiveGrabDevice
             num_modifiers:   INT16
             mask_len:        CARD16
             masks:           SETofEVENTMASK
-            modifiers:       CARD32 or GrabAnyModifier
+            modifiers:       LISTofSETofMODIFIERMASK
             ▶
             num_modifiers_return:    INT16
-            modifiers_return:        GRABMODIFIERINFO
+            modifiers_return:        LISTofGRABMODIFIERINFO
     └───
 
         GRABTYPE         { GrabtypeButton, GrabtypeKeycode, GrabtypeEnter,
                            GrabtypeFocusIn, GrabtypeTouchBegin¹ }
 
         GRABMODIFIERINFO {   status:    Access
-                             modifiers: CARD32 }
+                             modifiers: SETofMODIFIERMASK }
 
     ¹ since XI 2.2
 
@@ -1755,7 +1760,7 @@ XIPassiveUngrabDevice
             grab_type:       GRABTYPE
             grab_window:     Window
             num_modifiers:   INT16
-            modifiers:       MODIFIERINFO
+            modifiers:       LISTofSETofMODIFIERMASK
     └───
 
 Release an explicit passive grab on the specified input device.

From 48e32091c5a3220a464caad49fd7dd013c429eda Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 7 Dec 2012 12:55:24 +1000
Subject: [PATCH 368/388] Fix typo in comment

Signed-off-by: Peter Hutterer 
---
 XI2proto.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/XI2proto.h b/XI2proto.h
index 1260200..9418357 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -1021,7 +1021,7 @@ typedef struct
     uint8_t     type;                   /**< Always GenericEvent */
     uint8_t     extension;              /**< XI extension offset */
     uint16_t    sequenceNumber;
-    uint32_t    length;                 /**< Length in 4 byte uints */
+    uint32_t    length;                 /**< Length in 4 byte units */
     uint16_t    evtype;                 /**< ::XI_PropertyEvent */
     uint16_t    deviceid;
     Time        time;

From 0b88ca65bdaab4c60f945fe64c48982bc89e5d1f Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 7 Dec 2012 14:41:54 +1000
Subject: [PATCH 369/388] Claim support for XI 2.3

Signed-off-by: Peter Hutterer 
---
 XI2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/XI2.h b/XI2.h
index e864b06..7b8b607 100644
--- a/XI2.h
+++ b/XI2.h
@@ -30,7 +30,7 @@
    See commit libXi-1.4.2-21-ge8531dd */
 
 #define XI_2_Major                              2
-#define XI_2_Minor                              2
+#define XI_2_Minor                              3
 
 /* Property event flags */
 #define XIPropertyDeleted                       0

From 5f9d3b8584d88f49fa7533c429e32199a06ed215 Mon Sep 17 00:00:00 2001
From: "Jasper St. Pierre" 
Date: Fri, 7 Dec 2012 14:42:17 +1000
Subject: [PATCH 370/388] Add support for pointer barrier events

Signed-off-by: Jasper St. Pierre 
Signed-off-by: Peter Hutterer 
---
 XI2.h              |  11 ++-
 XI2proto.h         |  49 +++++++++++-
 specs/XI2proto.txt | 188 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 246 insertions(+), 2 deletions(-)

diff --git a/XI2.h b/XI2.h
index 7b8b607..b1498a7 100644
--- a/XI2.h
+++ b/XI2.h
@@ -160,6 +160,11 @@
 #define XITouchPendingEnd                       (1 << 16)
 #define XITouchEmulatingPointer                 (1 << 17)
 
+/* Barrier event flags */
+#define XIBarrierPointerReleased                (1 << 0)
+#define XIBarrierDeviceIsGrabbed                (1 << 1)
+
+
 /* Touch modes */
 #define XIDirectTouch                           1
 #define XIDependentTouch                        2
@@ -199,7 +204,9 @@
 #define XI_RawTouchBegin                 22
 #define XI_RawTouchUpdate                23
 #define XI_RawTouchEnd                   24
-#define XI_LASTEVENT                     XI_RawTouchEnd
+#define XI_BarrierHit                    25 /* XI 2.3 */
+#define XI_BarrierLeave                  26
+#define XI_LASTEVENT                     XI_BarrierLeave
 /* 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. */
@@ -232,5 +239,7 @@
 #define XI_RawTouchBeginMask             (1 << XI_RawTouchBegin)
 #define XI_RawTouchEndMask               (1 << XI_RawTouchEnd)
 #define XI_RawTouchUpdateMask            (1 << XI_RawTouchUpdate)
+#define XI_BarrierHitMask                (1 << XI_BarrierHit)
+#define XI_BarrierLeaveMask              (1 << XI_BarrierLeave)
 
 #endif /* _XI2_H_ */
diff --git a/XI2proto.h b/XI2proto.h
index 9418357..4cdaa0d 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -67,6 +67,7 @@
 #define Time    uint32_t
 #define Atom    uint32_t
 #define Cursor  uint32_t
+#define Barrier uint32_t
 
 /**
  * XI2 Request opcodes
@@ -92,9 +93,10 @@
 #define X_XIDeleteProperty              58
 #define X_XIGetProperty                 59
 #define X_XIGetSelectedEvents           60
+#define X_XIBarrierReleasePointer       61
 
 /** Number of XI requests */
-#define XI2REQUESTS (X_XIGetSelectedEvents - X_XIQueryPointer + 1)
+#define XI2REQUESTS (X_XIBarrierReleasePointer - X_XIQueryPointer + 1)
 /** Number of XI2 events */
 #define XI2EVENTS   (XI_LASTEVENT + 1)
 
@@ -815,6 +817,22 @@ typedef struct {
 } xXIGetPropertyReply;
 #define sz_xXIGetPropertyReply               32
 
+typedef struct {
+    uint16_t    deviceid;
+    uint16_t    pad;
+    Barrier     barrier;
+    uint32_t    eventid;
+} xXIBarrierReleasePointerInfo;
+
+typedef struct {
+    uint8_t     reqType;                /**< Input extension major opcode */
+    uint8_t     ReqType;                /**< Always X_XIBarrierReleasePointer */
+    uint16_t    length;
+    uint32_t    num_barriers;
+    /* array of xXIBarrierReleasePointerInfo */
+} xXIBarrierReleasePointerReq;
+#define sz_xXIBarrierReleasePointerReq       8
+
 /*************************************************************************************
  *                                                                                   *
  *                                      EVENTS                                       *
@@ -1035,10 +1053,39 @@ typedef struct
     uint32_t    pad3;
 } xXIPropertyEvent;
 
+typedef struct
+{
+    uint8_t     type;                   /**< Always GenericEvent */
+    uint8_t     extension;              /**< XI extension offset */
+    uint16_t    sequenceNumber;
+    uint32_t    length;                 /**< Length in 4 byte units */
+    uint16_t    evtype;                 /**< ::XI_BarrierHit or ::XI_BarrierLeave */
+    uint16_t    deviceid;
+    Time        time;
+    uint32_t    eventid;
+    Window      root;
+    Window      event;
+    Barrier     barrier;
+/* └──────── 32 byte boundary ────────┘ */
+    uint32_t    dtime;
+    uint32_t    flags;                  /**< ::XIBarrierPointerReleased
+                                             ::XIBarrierDeviceIsGrabbed */
+    uint16_t    sourceid;
+    int16_t     pad;
+    FP1616      root_x;
+    FP1616      root_y;
+    FP3232      dx;
+    FP3232      dy;
+} xXIBarrierEvent;
+
+typedef xXIBarrierEvent xXIBarrierHitEvent;
+typedef xXIBarrierEvent xXIBarrierPointerReleasedEvent;
+typedef xXIBarrierEvent xXIBarrierLeaveEvent;
 
 #undef Window
 #undef Time
 #undef Atom
 #undef Cursor
+#undef Barrier
 
 #endif /* _XI2PROTO_H_ */
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index c018026..b1c29c0 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -14,6 +14,7 @@ Authors:
 History 
 -------
 
+- v2.3, December 2012: Pointer barrier events added
 - v2.2, March 2012: Multitouch support added
 - v2.1, December 2011: new raw event behaviour, smooth scrolling support
   added
@@ -57,6 +58,10 @@ Changes in version 2.2
 
 - Multitouch support added
 
+Changes in version 2.3
+----------------------
+
+- Pointer barrier events added
 
 //                            ❧❧❧❧❧❧❧❧❧❧❧
 
@@ -551,6 +556,54 @@ window set has been reached, the event is delivered:
 Emulated pointer events will have the PointerEmulated flag set. A touch
 event that emulates pointer events has the TouchEmulatingPointer flag set.
 
+
+[[barrier-events]]
+Pointer barrier events
+^^^^^^^^^^^^^^^^^^^^^^
+If a master pointer moves against a pointer barrier blocking movement in
+that pointer's direction, the movement of the pointer is clamped to the x or
+y coordinate of the barrier, whichever applies. For a description of pointer
+barriers and barrier creation and destruction see the XFixes protocol
+specification v 5.0 or later.
+http://cgit.freedesktop.org/xorg/proto/fixesproto/plain/fixesproto.txt
+
+A pointer hitting a blocking barrier creates a new barrier event sequence,
+identified by a unique event ID. A new event ID is assigned when the pointer
+first hits a barrier. Subsequent movements against or along the pointer
+barrier are assigned the same event ID. The event generated by the pointer
+leaving the barrier, or being released by a client request, is the last
+event with this event ID. Any future movements of this device blocked by
+this barrier will be assigned a new event ID.
+
+Pointer barrier events are delivered exclusively to the client that created
+the barrier, and to the window specified in the CreatePointerBarrier
+request (the "barrier window"). A pointer barrier blocks pointer movement
+regardless of whether its window is mapped and/or viewable. If the pointer
+barrier window is destroyed, the pointer barrier remains blocking but a
+client will not receive further events.
+
+If a device is actively grabbed by a client or a passive grab activated
+for this client, and the pointer moves against a pointer barrier created by
+this client and the grab-window is the barrier window, that client will
+receive pointer barrier events if:
+- owner-events is true or false and the grab's event mask includes
+  pointer barrier events, or
+- owner-events is true and the client has selected for barrier events on the
+  barrier window.
+
+If the grab-window is not the barrier window, the client will receive events
+if:
+- the client has selected for barrier events on the barrier window.
+
+If the barrier is not owned by this client, no barrier events are sent to
+this client. The client owning the barrier will receive events if:
+- the client has pointer barrier events selected on the window associated
+  with the pointer barrier
+
+The BarrierDeviceIsGrabbed flag is set whenever a pointer barrier event is
+generated while the device is actively grabbed by any client or a passive
+grab has activated for this device prior to the event.
+
 [[glossary-notations]]
 Notations used in this document
 -------------------------------
@@ -1940,6 +1993,48 @@ 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.  
+
+[[requests-xi23]]
+Requests introduced in version 2.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+[[requests-barrierreleasepointer]]
+XIBarrierReleasePointer
+^^^^^^^^^^^^^^^^^^^^^^^
+    ┌───
+        XIBarrierReleasePointer
+            num_items:       CARD32
+            ▶
+            data:            LISTofBARRIERRELEASEINFO
+    └───
+
+    BARRIERRELEASEINFO { deviceid: DEVICEID,
+                         barrier:  Barrier,
+                         eventid: CARD32 }
+
+Release a pointer currently blocked by a barrier. In the future, movement of
+this pointer against the barrier will not be blocked.
+
+        deviceid
+            The device currently being blocked by a barrier
+        barrier
+            The barrier currently blocking the device
+        eventid
+            The unique event ID assigned to this barrier event sequence
+
+If the barrier given does not currently block this device, or the eventid
+is invalid, this request does nothing.
+
+Releasing a pointer barrier is only valid during one barrier event sequence,
+and only applies to the next movement of this device against this barrier.
+If the pointer moves away from the barrier following a
+XIBarrierReleasePointer request, the release request is discarded. In the
+future, if the pointer moves against the barrier again, a new eventid is
+assigned and the client must re-issue the XIBarrierReleasePointer request.
+
+If the device is not a master pointer device, a BadDevice error results.
+If the barrier does not name a valid barrier, a BadValue error results.
+
      
 [[events]]
 Events
@@ -1984,6 +2079,11 @@ Version 2.2:
         - RawTouchUpdate
         - RawTouchEnd
 
+Version 2.3:
+
+        - BarrierHit
+        - BarrierLeave
+
 All events have a set of common fields specified as EVENTHEADER.
 
 
@@ -2434,6 +2534,94 @@ is now the owner of the touch sequence specified by touchid.
     flags
         A bitmask of flags for this event.
 
+[[events-xi23]]
+Events introduced in version 2.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+[[events-barrierevent]]
+BarrierEvent
+^^^^^^^^^^^^
+    ┌───
+        BarrierEvent
+            EVENTHEADER
+            eventid:                    CARD32
+            root:                       Window
+            event:                      Window
+            barrier:                    Barrier
+            dtime:                      CARD32
+            flags:                      SETofBARRIERFLAGS
+            sourceid:                   DEVICEID
+            root_x:                     FP1616
+            root_y:                     FP1616
+            dx:                         FP3232
+            dy:                         FP3232
+    └───
+
+    BARRIERFLAGS { PointerReleased, DeviceIsGrabbed }
+
+A BarrierEvent indicates interaction between a barrier and a pointer device.
+If the event type is BarrierHit, pointer movement has been blocked by a
+barrier. If the event type is BarrierLeave, a pointer previously blocked
+by a barrier has moved away from that barrier, or has moved
+through the blocking barrier following an earlier XIBarrierReleasePointer
+request.
+
+    eventid
+       The unique event ID for this barrier event sequence.
+    root
+    event
+        The root window or barrier window, respectively. The barrier window
+        is always the drawable specified in in the CreatePointerBarrier request.
+    barrier
+        The barrier blocking pointer movement.
+    dtime
+        The relative time in milliseconds between the last event and this
+        event.
+    flags
+        A set of flags that apply to this barrier event
+        PointerReleased:
+           The pointer has moved through the barrier following a
+           XIBarrierReleasePointer request (BarrierLeave only).
+        DeviceIsGrabbed:
+           The pointer device that generated this event is currently
+           grabbed.
+    sourceid
+        The source device that originally generated the event.
+    root_x
+    root_y
+        The position of the pointer in screen coordinates (16.16 fixed
+        point), after being constrained by barrier and/or screen extents.
+    dx
+    dy
+        The relative movement of the pointer from its previous position to
+        the new position if pointer movement were not constrained by this
+        barrier.
+
+Root coordinates in barrier events represent the position of the cursor
+after confinement by barriers, screens and RandR output extents.
+
+Barrier event IDs are provided in the eventid field of barrier events. Its
+value is always provided in every barrier event. Event IDs are
+represented as unsigned 32-bit values and increase strictly monotonically in
+value for each new barrier event sequence, wrapping back to 0 upon reaching
+the numerical limit of IDs. The increment between two event IDs is
+indeterminate. Clients may not assume that any future barrier constraints
+will have specific event IDs. IDs are unique per device per barrier.
+
+If a pointer is actively grabbed after a barrier event sequence has
+initiated, future barrier events of this sequence continue to use the same
+eventid, but all barrier events have the DeviceIsGrabbed flag set. If the
+pointer is ungrabbed, future events of this sequence have the same eventid
+and the DeviceIsGrabbed flag is unset.
+
+The PointerReleased flag may only be set on a BarrierLeave event.
+A BarrierLeave(PointerReleased) event is generated when the pointer moves
+through the barrier following a XIBarrierReleasePointer request. The time
+between the XIBarrierReleasePointer and the BarrierLeave event thus depends
+on user input.
+A BarrierLeave(PointerReleased) event is also generated if the barrier is
+destroyed while pointer movement is constrained by the barrier. This event
+has a dx/dy of 0/0.
 
 :numbered!:
 [[xi22-usecases]]

From bc009eb4dadf2138212291da05b514854923ae85 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 7 Dec 2012 14:41:03 +1000
Subject: [PATCH 371/388] inputproto 2.2.99.1

Signed-off-by: Peter Hutterer 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 1c74810..7c8e2eb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
 AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.2], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.2.99.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
 AM_INIT_AUTOMAKE([foreign dist-bzip2])
 AM_MAINTAINER_MODE
 

From e93e9d004c11a59cab56139c0c04ea2b5c6a926b Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Mon, 17 Dec 2012 14:18:07 +1000
Subject: [PATCH 372/388] specs: removing a device results in a BarrierLeave
 event

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index b1c29c0..d30fcca 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2620,7 +2620,8 @@ through the barrier following a XIBarrierReleasePointer request. The time
 between the XIBarrierReleasePointer and the BarrierLeave event thus depends
 on user input.
 A BarrierLeave(PointerReleased) event is also generated if the barrier is
-destroyed while pointer movement is constrained by the barrier. This event
+destroyed while pointer movement is constrained by the barrier, or the
+master pointer blocked by the barrier is removed. This event
 has a dx/dy of 0/0.
 
 :numbered!:

From 8cad031f9f583089dd33bae41dfa8a7e0d8a71f4 Mon Sep 17 00:00:00 2001
From: Adam Jackson 
Date: Tue, 15 Jan 2013 14:01:10 -0500
Subject: [PATCH 373/388] configure: Remove AM_MAINTAINER_MODE

Signed-off-by: Adam Jackson 
---
 configure.ac | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 7c8e2eb..85dfaf1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,7 +1,6 @@
 AC_PREREQ([2.60])
 AC_INIT([InputProto], [2.2.99.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
 AM_INIT_AUTOMAKE([foreign dist-bzip2])
-AM_MAINTAINER_MODE
 
 # Require xorg-macros: XORG_WITH_ASCIIDOC
 m4_ifndef([XORG_MACROS_VERSION],

From f8428123019e7357891bbfc0aef21dbb4d0db10f Mon Sep 17 00:00:00 2001
From: Colin Walters 
Date: Wed, 4 Jan 2012 17:37:06 -0500
Subject: [PATCH 374/388] autogen.sh: Implement GNOME Build API

http://people.gnome.org/~walters/docs/build-api.txt

Signed-off-by: Adam Jackson 
---
 autogen.sh | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/autogen.sh b/autogen.sh
index 904cd67..fc34bd5 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -9,4 +9,6 @@ cd $srcdir
 autoreconf -v --install || exit 1
 cd $ORIGDIR || exit $?
 
-$srcdir/configure --enable-maintainer-mode "$@"
+if test -z "$NOCONFIGURE"; then
+    $srcdir/configure "$@"
+fi

From f33a329026c9f2eaa5fa436543e4feb0e54b685d Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Thu, 7 Mar 2013 10:42:39 +1000
Subject: [PATCH 375/388] inputproto 2.3

Signed-off-by: Peter Hutterer 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 85dfaf1..e6f3db4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
 AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.2.99.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.3], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
 AM_INIT_AUTOMAKE([foreign dist-bzip2])
 
 # Require xorg-macros: XORG_WITH_ASCIIDOC

From 65f14b2edaf70a2520e0180609f79f52836ca4f9 Mon Sep 17 00:00:00 2001
From: Gaetan Nadon 
Date: Sat, 26 Oct 2013 09:42:05 -0400
Subject: [PATCH 376/388] config: replace deprecated use of AC_OUTPUT with
 AC_CONFIG_FILES

Fix Automake warning: AC_OUTPUT should be used without arguments.
www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Files

Signed-off-by: Gaetan Nadon 
---
 configure.ac | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index e6f3db4..addad75 100644
--- a/configure.ac
+++ b/configure.ac
@@ -10,6 +10,7 @@ XORG_DEFAULT_OPTIONS
 XORG_ENABLE_SPECS
 XORG_WITH_ASCIIDOC(8.4.5)
 
-AC_OUTPUT([Makefile
+AC_CONFIG_FILES([Makefile
            specs/Makefile
            inputproto.pc])
+AC_OUTPUT

From 06da19e15c9d3a9e57f4fe89fe507a4fa7160a45 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 19 Jul 2013 15:54:45 +1000
Subject: [PATCH 377/388] specs: clarify SD keyboard focus behaviour

The smart thing would be to have the SD's keyboard focus to be identical to
the MD's keyboard focus (and a BadDevice returned when trying to set an
attached SD's keyboard focus) but alas, the server never implemented this
behaviour and we've now shipped 7 versions with separate SD and MD focus. So
consider this set in stone. oops.

Signed-off-by: Peter Hutterer 
Reviewed-by: Jasper St. Pierre 
---
 specs/XI2proto.txt | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index d30fcca..79988fc 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -212,6 +212,8 @@ If an event is generated by an SD
 
 - if the SD is attached to a master pointer, it changes the position and/or
   button state of the master pointer.
+- if the SD has a keyboard focus other than None, the key event is sent to
+  the focus window.
 - if the SD is attached to a master keyboard, it sends events to this
   keyboard's focus window (if applicable) and/or changes the modifier state of
   this keyboard.
@@ -220,6 +222,13 @@ If an event is generated by an SD
   Both the sprite and the focus must be managed explicitly by the client
   program.
 
+Note: the keyboard focus of an attached slave device is independent to that
+of the master device. Two keyboard events are generated, once with deviceid
+and sourceid set to the slave device. This keyboard event is sent to the
+slave device's focus window. The second event has a deviceid of the master
+and a sourceid of the slave device. This second event is delivered to the
+master keyboard's focus window.
+
 [[hierarchy-dcce]]
 Event processing for attached slave devices
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From 3c1ebd1cfe71029ebc6a732a6b55308861e549e0 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 14 Aug 2013 19:30:24 +1000
Subject: [PATCH 378/388] specs: note that axis values are non-sparse arrays

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 79988fc..2f81bef 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2290,7 +2290,9 @@ XI 2.2: The event type may also be TouchBegin, TouchUpdate, or TouchEnd.
     valuators
         Bitmask of valuators provided in axisvalues.
     axisvalues
-        Valuator data in device-native resolution.
+        Valuator data in device-native resolution. This is a non-sparse
+        array, value N represents the axis corresponding to the Nth bit set
+        in valuators.
     flags
         Miscellaneous information about this event; the union of the
         common flag set and either the key or pointer flag set,
@@ -2401,9 +2403,13 @@ when the device is grabbed by another client.
     valuators
         Bitmask of valuators provided in axisvalues and axisvalues_raw.
     axisvalues
-        Valuator data in device-native resolution.
+        Valuator data in device-native resolution. This is a non-sparse
+        array, value N represents the axis corresponding to the Nth bit set
+        in valuators.
     axisvalues_raw
-        Untransformed valuator data in device-native resolution.
+        Untransformed valuator data in device-native resolution. This is a
+        non-sparse array, value N represents the axis corresponding to the
+        Nth bit set in valuators.
 
     ¹ since XI 2.2
 

From b4184619702b6801e3a2ea9733ae1620fa4ceda7 Mon Sep 17 00:00:00 2001
From: Keith Packard 
Date: Mon, 16 Dec 2013 09:43:41 -0800
Subject: [PATCH 379/388] inputproto: Allow library users to avoid having the
 'Pointer' typedef declared

'Pointer' collides with too many other application names, so stop
using it locally and allow applications to avoid having it in the API.

Signed-off-by: Keith Packard 
Reviewed-by: Eric Anholt 
---
 XIproto.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/XIproto.h b/XIproto.h
index e00ab61..82323d8 100644
--- a/XIproto.h
+++ b/XIproto.h
@@ -85,12 +85,14 @@ typedef struct  _XExtEventInfo
     BYTE	word;
     } XExtEventInfo;
 
-typedef unsigned char *Pointer;
+#ifndef _XITYPEDEF_POINTER
+typedef void *Pointer;
+#endif
 
 struct tmask
     {
     Mask	mask;
-    Pointer     dev;
+    void        *dev;
     };
 
 /*********************************************************

From c2cf8cab4aa781306ff26b171107d26f12bac015 Mon Sep 17 00:00:00 2001
From: Daniel Martin 
Date: Thu, 29 May 2014 12:24:46 +0200
Subject: [PATCH 380/388] XI2: Fix XI_TouchOwnershipChangedMask value

A none existing define
    XI_TouchOwnershipChanged
had been used to set the value of XI_TouchOwnershipChangedMask. Fix this
by using
    XI_TouchOwnership.

Signed-off-by: Daniel Martin 
Signed-off-by: Peter Hutterer 
---
 XI2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/XI2.h b/XI2.h
index b1498a7..5a1c66a 100644
--- a/XI2.h
+++ b/XI2.h
@@ -234,7 +234,7 @@
 #define XI_RawMotionMask                 (1 << XI_RawMotion)
 #define XI_TouchBeginMask                (1 << XI_TouchBegin)
 #define XI_TouchEndMask                  (1 << XI_TouchEnd)
-#define XI_TouchOwnershipChangedMask     (1 << XI_TouchOwnershipChanged)
+#define XI_TouchOwnershipChangedMask     (1 << XI_TouchOwnership)
 #define XI_TouchUpdateMask               (1 << XI_TouchUpdate)
 #define XI_RawTouchBeginMask             (1 << XI_RawTouchBegin)
 #define XI_RawTouchEndMask               (1 << XI_RawTouchEnd)

From 343ff0938f592876b9d82c966f166bf45a78c3c8 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Fri, 30 May 2014 11:25:39 +1000
Subject: [PATCH 381/388] inputproto 2.3.1

Signed-off-by: Peter Hutterer 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index addad75..56115df 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
 AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.3], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.3.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
 AM_INIT_AUTOMAKE([foreign dist-bzip2])
 
 # Require xorg-macros: XORG_WITH_ASCIIDOC

From 81378a1e7139af9d476d90df8737c0c1a58670f3 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Mon, 25 Aug 2014 11:04:38 +1000
Subject: [PATCH 382/388] specs: note the (unused) time field in
 XIPassiveGrabDevice

We don't actually use it either in libXi or in the server, it's a copy/paste
error that never got noticed and removed.

Signed-off-by: Peter Hutterer 
---
 specs/XI2proto.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 2f81bef..e3636ac 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1630,6 +1630,7 @@ XIPassiveGrabDevice
             deviceid:        DEVICE
             detail:          CARD32
             grab_type:       GRABTYPE
+            time:            TIMESTAMP
             grab_window:     Window
             cursor:          Cursor
             owner_events:    Bool
@@ -1695,6 +1696,8 @@ on the specified input device.
             Number of elements in modifiers_return
         modifiers_return
             XKB modifier state that could not be grabbed.
+        time
+            This field is unused.
 
 If owner-events is False, input events generated from this device are
 reported with respect to grab-window, and are only reported if

From 7c7c2c18864d166391e49758d83e9cc601bbfb17 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Mon, 27 Oct 2014 14:22:58 +1000
Subject: [PATCH 383/388] specs: rename EVENTMASK to EVTYPEMASK

EVENTMASK was used twice in the spec, once as the actual bitmask for events,
once as the set of deviceid, mask length and mask.

The libXi public API uses XIEventMask for the latter data triplet, so leave
EVENTMASK, and rename the pure bitmask to EVTYPEMASK.

Reported-by: Gabriel Laskar 
Signed-off-by: Peter Hutterer 
Reviewed-by: Hans de Goede 
---
 specs/XI2proto.txt | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index e3636ac..697dd89 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -672,9 +672,9 @@ Data types
             device hierarchy. See Section "The Master/Slave device hierarchy"
             for more information.
 
-    EVENTMASK
-            An EVENTMASK is a binary mask defined as (1 << event type).
-            A SETofEVENTMASK is a binary OR of zero or more EVENTMASK.
+    EVTYPEMASK
+            An EVTYPEMASK is a binary mask defined as (1 << event type).
+            A SETofEVTYPEMASK is a binary OR of zero or more EVTYPEMASK.
 
     FP1616
             Fixed point decimal in 16.16 format as one INT16 and one CARD16.
@@ -971,7 +971,7 @@ XISelectEvents
 
     EVENTMASK { deviceid:          DEVICE,
                 mask_len:          CARD16,
-                mask:              SETofEVENTMASK
+                mask:              SETofEVTYPEMASK }
 
     window
         The window to select the events on.
@@ -1392,7 +1392,7 @@ XIGrabDevice
             time:            TIMESTAMP or CurrentTime
             cursor:          Cursor
             mask_len:        CARD16
-            masks:           SETofEVENTMASK
+            masks:           SETofEVTYPEMASK
             ▶
             status:          Success, AlreadyGrabbed, Frozen, InvalidTime, NotViewable
     └───
@@ -1638,7 +1638,7 @@ XIPassiveGrabDevice
             paired_device_mode: { Synchronous, Asynchronous }
             num_modifiers:   INT16
             mask_len:        CARD16
-            masks:           SETofEVENTMASK
+            masks:           SETofEVTYPEMASK
             modifiers:       LISTofSETofMODIFIERMASK
             ▶
             num_modifiers_return:    INT16

From 1dbdc297d915e4979a7823d6a569d9c7fed14617 Mon Sep 17 00:00:00 2001
From: Andreas Boll 
Date: Fri, 11 Dec 2015 10:49:33 +0100
Subject: [PATCH 384/388] specs: Set TZ=UTC before calling asciidoc

Set TZ=UTC before calling asciidoc to make the embedded dates invariant
to timezones in order to make the package build reproducibly.

Fixes bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795981

v2: Set TZ=UTC after $(AM_V_GEN) (fixes non-verbose build)

Suggested-by: Eduard Sanou 
Signed-off-by: Andreas Boll 
Signed-off-by: Peter Hutterer 
---
 specs/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specs/Makefile.am b/specs/Makefile.am
index a83cf40..f2454bc 100644
--- a/specs/Makefile.am
+++ b/specs/Makefile.am
@@ -6,7 +6,7 @@ doc_DATA = XI2proto.html XIproto.html
 dist_doc_DATA = XI2proto.txt XIproto.txt
 
 %.html: %.txt
-	$(AM_V_GEN)$(ASCIIDOC) -o $@ $<
+	$(AM_V_GEN)TZ=UTC $(ASCIIDOC) -o $@ $<
 
 CLEANFILES = $(doc_DATA)
 

From 6946d497e3fe496818fa70de6702934bf70e44ec Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Mon, 4 Apr 2016 12:28:42 +1000
Subject: [PATCH 385/388] inputproto 2.3.2

Signed-off-by: Peter Hutterer 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 56115df..7480425 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
 AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.3.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.3.2], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
 AM_INIT_AUTOMAKE([foreign dist-bzip2])
 
 # Require xorg-macros: XORG_WITH_ASCIIDOC

From 7ac1b1086ef3ae1b7b1dbab8b82e3b63ff8c8700 Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Tue, 24 Jan 2017 10:32:07 +1000
Subject: [PATCH 386/388] autogen.sh: use exec instead of waiting for configure
 to finish

Syncs the invocation of configure with the one from the server.

Signed-off-by: Peter Hutterer 
---
 autogen.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/autogen.sh b/autogen.sh
index fc34bd5..fd9c59a 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -10,5 +10,5 @@ autoreconf -v --install || exit 1
 cd $ORIGDIR || exit $?
 
 if test -z "$NOCONFIGURE"; then
-    $srcdir/configure "$@"
+    exec $srcdir/configure "$@"
 fi

From fa0fad73652b45e89f1a2770cc86b59cd6c1904d Mon Sep 17 00:00:00 2001
From: Emil Velikov 
Date: Mon, 9 Mar 2015 12:00:52 +0000
Subject: [PATCH 387/388] autogen.sh: use quoted string variables

Place quotes around the $srcdir, $ORIGDIR and $0 variables to prevent
fall-outs, when they contain space.

Signed-off-by: Emil Velikov 
Reviewed-by: Peter Hutterer 
Signed-off-by: Peter Hutterer 
---
 autogen.sh | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/autogen.sh b/autogen.sh
index fd9c59a..0006de8 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -1,14 +1,14 @@
 #! /bin/sh
 
-srcdir=`dirname $0`
+srcdir=`dirname "$0"`
 test -z "$srcdir" && srcdir=.
 
 ORIGDIR=`pwd`
-cd $srcdir
+cd "$srcdir"
 
 autoreconf -v --install || exit 1
-cd $ORIGDIR || exit $?
+cd "$ORIGDIR" || exit $?
 
 if test -z "$NOCONFIGURE"; then
-    exec $srcdir/configure "$@"
+    exec "$srcdir"/configure "$@"
 fi

From c6d1092daa34d3ca32f7bd266c1dc0032d7636a7 Mon Sep 17 00:00:00 2001
From: Mihail Konev 
Date: Thu, 26 Jan 2017 13:52:48 +1000
Subject: [PATCH 388/388] autogen: add default patch prefix

Signed-off-by: Mihail Konev 
---
 autogen.sh | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/autogen.sh b/autogen.sh
index 0006de8..a79dc33 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -9,6 +9,9 @@ cd "$srcdir"
 autoreconf -v --install || exit 1
 cd "$ORIGDIR" || exit $?
 
+git config --local --get format.subjectPrefix >/dev/null 2>&1 ||
+    git config --local format.subjectPrefix "PATCH inputproto"
+
 if test -z "$NOCONFIGURE"; then
     exec "$srcdir"/configure "$@"
 fi