File inputproto-update.patch of Package xorg-x11-proto-inputproto

File inputproto-update.patch of Package xorg-x11-proto-inputproto (Revision 1307174b4e9058ea9c06979e1d9e3cb1)

Currently displaying revision 1307174b4e9058ea9c06979e1d9e3cb1, show latest

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/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
diff --git a/XI2proto.h b/XI2proto.h
index 2fd91eb..84574a5 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -60,6 +60,7 @@
 #include <X11/Xproto.h>
 #include <X11/X.h>
 #include <X11/extensions/XI2.h>
+#include <stdint.h>
 
 /* make sure types have right sizes for protocol structures. */
 #define Window  uint32_t
diff --git a/XI2proto.txt b/XI2proto.txt
deleted file mode 100644
index 10f58c2..0000000
--- a/XI2proto.txt
+++ /dev/null
@@ -1,1677 +0,0 @@
-
-                            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.
-
-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
-
-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
-
-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.
-
-                              ❧❧❧❧❧❧❧❧❧❧❧
-
-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 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.
-
-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.
-
-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
-
-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 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.
-
-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. Padding bytes in XI2 protocol requests
-are required to be 0.
-
-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 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.
-
-    ┌───
-        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
-                  sourceid:             CARD16
-                  buttons_len:          CARD16
-                  state:                SETofBUTTONMASK
-                  labels:               LISTofATOM }
-
-    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 }
-
-    XIQueryDevice 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 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.
-
-    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.
-    sourceid
-        The device this class originates from.
-    num_buttons
-        Number of buttons provided by the device.
-    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 regardless of the current button mapping.
-    state
-        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
-        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
-        List of keycodes provided.
-
-    AxisClass:
-    type
-        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.
-    label
-        Atom specifying the axis name. An Atom of None specifies an unlabeled
-        axis.
-    min
-        Minimum value.
-    max
-        Minimum value.
-    resolution
-        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.
-
-    ┌───
-        XISelectEvents
-            window:         Window
-            num_masks:      CARD16
-            masks:          LISTofEVENTMASK
-
-    └───
-
-    EVENTMASK { deviceid:          DEVICE,
-                mask_len:          CARD16,
-                mask:              SETofEVENTMASK
-
-    window
-        The window to select the events on.
-    num_masks
-        Number of items in masks.
-    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.
-
-    The mask for XIHierarchyEvents may only be selected for XIAllDevices.
-    Setting it for any other device results in a BadValue error.
-
-    ┌───
-        XIGetSelectedEvents
-            window:         Window
-            ▶
-            num_masks:      CARD16
-            masks:          LISTofEVENTMASK
-    └───
-
-    window
-        The window to select the events on.
-    num_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
-    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.
-
-    ┌───
-        XIQueryPointer
-            window:         Window
-            deviceid:       DEVICEID
-            ▶
-            root:           Window
-            child:          Window
-            root_x:         FP1616
-            root_y:         FP1616
-            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.
-
-    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.
-    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.
-
-    If the device is not a master pointer device or not a floating slave
-    pointer, a BadDevice error results.
-
-    ┌───
-        XIWarpPointer
-            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
-    └───
-
-    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
-       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.
-
-    ┌───
-        XIChangeCursor
-            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.
-
-    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.
-
-    ┌───
-        XIChangeHierarchy
-            num_changes:     CARD8
-            changes:         LISTofHIERARCHYCHANGES
-    └───
-
-    HIERARCHYCHANGE { ADDMASTER, REMOVEMASTER, ATTACHSLAVE, DETACHSLAVE }
-
-    HIERARCHYCHANGETYPE { AddMaster, RemoveMaster, AttachSlave, DetachSlave }
-
-    CHANGEMODE { Float, Attach }
-
-    ADDMASTER { 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 }
-
-    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.
-
-    ADDMASTER creates a pair of master devices.
-    type
-        Always AddMaster.
-    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. If return_mode is Float, return_pointer
-        and return_keyboard are undefined.
-
-    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. 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 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.
-
-    ┌───
-        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 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
-            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.
-
-    ┌───
-        XIGetFocus
-            deviceid:        DEVICEID
-            ▶
-            focus:           Window
-    └───
-
-    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
-            cursor:          Cursor
-            mask_len:        CARD16
-            masks:           SETofEVENTMASK
-            ▶
-            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.
-
-    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.
-
-    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.
-
-    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.
-    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 a device, use XIUngrabDevice.
-
-    ┌───
-        XIUngrabDevice
-            deviceid:        DEVICEID
-            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.
-
-    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.
-
-    ┌───
-        XIAllowEvents:
-            deviceid:        DEVICEID
-            time:            TIMESTAMP or CurrentTime
-            event_mode:      { AsyncDevice, SyncDevice,
-                               AsyncPairedDevice, SyncPairedDevice,
-                               ReplayDevice, AsyncPair, SyncPair }
-    └───
-
-    The XIAllowEvents request releases some queued events if the client
-    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:
-    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, 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.
-    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.
-
-    ┌───
-        XIPassiveGrabDevice
-            deviceid:        DEVICE
-            detail:          CARD32
-            grab_type:       GRABTYPE
-            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
-    └───
-
-        GRABTYPE         { GrabtypeButton, GrabtypeKeycode, GrabtypeEnter,
-                           GrabtypeFocusIn}
-
-        GRABMODIFIERINFO {   status:    Access
-                             modifiers: CARD32 }
-
-        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
-            is not GrabtypeButton, this argument is ignored.
-        deviceid
-            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.
-        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.
-
-        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
-        - 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 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/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:
-        - 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.
-
-        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.
-
-        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 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.
-
-    ┌───
-        XIPassiveUngrabDevice
-            deviceid:        DEVICEID
-            detail:          CARD32
-            grab_type:       GRABTYPE
-            grab_window:     Window
-            num_modifiers:   INT16
-            modifiers:       MODIFIERINFO
-    └───
-
-        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
-            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 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
-            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 XIDeleteProperty.
-
-        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:
-
-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
-        RawKeyPress
-        RawKeyRelease
-        RawButtonPress
-        RawButtonRelease
-        RawMotion
-        Enter
-        Leave
-        FocusIn
-        FocusOut
-        PropertyEvent
-
-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.
-
-
-    ┌───
-        HierarchyEvent:
-            EVENTHEADER
-            flags:                      SETofHIERARCHYMASK
-            num_info:                   CARD16
-            info:                       LISTofHIERARCHYINFO
-    └───
-
-
-    HIERARCHYMASK { MasterAdded, MasterRemoved, SlaveAttached, SlaveDetached,
-                    SlaveAdded, SlaveRemoved, DeviceEnabled, DeviceDisabled }
-
-    HIERARCHYINFO { deviceid:           DEVICEID,
-                    attachment:         DEVICEID,
-                    type:               DEVICEUSE
-                    enabled:            BOOL
-                    flags:              SETofHIERARCHYMASK}
-
-    flags
-        Set of the changes that have occured, causing this event.
-    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, 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.
-
-    ┌───
-        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
-        the device itself.
-    source
-        The source of the new classes.
-    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 XQueryDevice 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
-            flags:                      DEVICEEEVENTFLAGS
-            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,
-                    effective_mods:      CARD32}
-    GROUPINFO     { base_group:          CARD8,
-                    latched_group:       CARD8,
-                    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. The event type may be one of KeyPress,
-    KeyRelease, ButtonPress, ButtonRelease, Motion.
-
-    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.
-    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
-        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
-            detail:                    CARD32
-            flags:                     DEVICEEVENTFLAGS
-            valuators_len:             CARD16
-            valuators:                 SETofVALUATORMASK
-            axisvalues:                LISTofFP3232
-            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.
-
-    eventtype
-        The type of event that occured on the device.
-    detail
-        The button number or keycode.
-    flags
-        Flags as described in DeviceEvent.
-    valuators_len
-        The length of valuators in 4 byte units.
-    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 or FocusIn or FocusOut
-            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
-            mods:               MODIFIERINFO
-            group:              GROUPINFO
-            buttons_len:        CARD16
-            buttons:            SETofBUTTONMASK
-    └───
-
-    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.
-    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
-    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. 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.
-    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. This field is
-        unspecified for focus in/out events.
-    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.
-
-    ┌───
-        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.
-     
-
-                              ❧❧❧❧❧❧❧❧❧❧❧
diff --git a/XIproto.txt b/XIproto.txt
deleted file mode 100644
index f9d19f0..0000000
--- a/XIproto.txt
+++ /dev/null
@@ -1,2544 +0,0 @@
-           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
-   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}
-
-   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: <see below>
-                       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.
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..a83cf40
--- /dev/null
+++ b/specs/Makefile.am
@@ -0,0 +1,14 @@
+
+if ENABLE_SPECS
+if HAVE_ASCIIDOC
+
+doc_DATA = XI2proto.html XIproto.html
+dist_doc_DATA = XI2proto.txt XIproto.txt
+
+%.html: %.txt
+	$(AM_V_GEN)$(ASCIIDOC) -o $@ $<
+
+CLEANFILES = $(doc_DATA)
+
+endif
+endif
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
new file mode 100644
index 0000000..1e3adbe
--- /dev/null
+++ b/specs/XI2proto.txt
@@ -0,0 +1,1715 @@
+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.
+
+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
+----------------------------------
+
+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
+-----------------------------------------------
+
+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.
+
+//                            ❧❧❧❧❧❧❧❧❧❧❧
+
+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 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.
+
+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.
+
+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
+-------------
+
+    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 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.
+
+    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. Padding bytes in XI2 protocol requests
+are required to be 0.
+
+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 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.
+
+    ┌───
+        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
+                  sourceid:             CARD16
+                  buttons_len:          CARD16
+                  state:                SETofBUTTONMASK
+                  labels:               LISTofATOM }
+
+    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 }
+
+XIQueryDevice 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 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.
+
+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.
+    sourceid
+        The device this class originates from.
+    num_buttons
+        Number of buttons provided by the device.
+    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 regardless of the current button mapping.
+    state
+        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
+        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
+        List of keycodes provided.
+
+    AxisClass:
+    type
+        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.
+    label
+        Atom specifying the axis name. An Atom of None specifies an unlabeled
+        axis.
+    min
+        Minimum value.
+    max
+        Minimum value.
+    resolution
+        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.
+
+    ┌───
+        XISelectEvents
+            window:         Window
+            num_masks:      CARD16
+            masks:          LISTofEVENTMASK
+
+    └───
+
+    EVENTMASK { deviceid:          DEVICE,
+                mask_len:          CARD16,
+                mask:              SETofEVENTMASK
+
+    window
+        The window to select the events on.
+    num_masks
+        Number of items in masks.
+    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.
+
+The mask for XIHierarchyEvents may only be selected for XIAllDevices.
+Setting it for any other device results in a BadValue error.
+
+    ┌───
+        XIGetSelectedEvents
+            window:         Window
+            ▶
+            num_masks:      CARD16
+            masks:          LISTofEVENTMASK
+    └───
+
+    window
+        The window to select the events on.
+    num_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
+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.
+
+    ┌───
+        XIQueryPointer
+            window:         Window
+            deviceid:       DEVICEID
+            ▶
+            root:           Window
+            child:          Window
+            root_x:         FP1616
+            root_y:         FP1616
+            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.
+
+    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.
+    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.
+
+If the device is not a master pointer device or not a floating slave
+pointer, a BadDevice error results.
+
+    ┌───
+        XIWarpPointer
+            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
+    └───
+
+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
+       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.
+
+    ┌───
+        XIChangeCursor
+            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.
+
+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.
+
+    ┌───
+        XIChangeHierarchy
+            num_changes:     CARD8
+            changes:         LISTofHIERARCHYCHANGES
+    └───
+
+    HIERARCHYCHANGE { ADDMASTER, REMOVEMASTER, ATTACHSLAVE, DETACHSLAVE }
+
+    HIERARCHYCHANGETYPE { AddMaster, RemoveMaster, AttachSlave, DetachSlave }
+
+    CHANGEMODE { Float, Attach }
+
+    ADDMASTER { 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 }
+
+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.
+
+    ADDMASTER creates a pair of master devices.
+    type
+        Always AddMaster.
+    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. If return_mode is Float, return_pointer
+        and return_keyboard are undefined.
+
+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. 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 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.
+
+    ┌───
+        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 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
+            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.
+
+    ┌───
+        XIGetFocus
+            deviceid:        DEVICEID
+            ▶
+            focus:           Window
+    └───
+
+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
+            cursor:          Cursor
+            mask_len:        CARD16
+            masks:           SETofEVENTMASK
+            ▶
+            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.
+
+    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.
+
+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.
+
+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.
+    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 a device, use XIUngrabDevice.
+
+    ┌───
+        XIUngrabDevice
+            deviceid:        DEVICEID
+            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.
+
+    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.
+
+    ┌───
+        XIAllowEvents:
+            deviceid:        DEVICEID
+            time:            TIMESTAMP or CurrentTime
+            event_mode:      { AsyncDevice, SyncDevice,
+                               AsyncPairedDevice, SyncPairedDevice,
+                               ReplayDevice, AsyncPair, SyncPair }
+    └───
+
+The XIAllowEvents request releases some queued events if the client
+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:
+
+    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, 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.
+    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.
+
+    ┌───
+        XIPassiveGrabDevice
+            deviceid:        DEVICE
+            detail:          CARD32
+            grab_type:       GRABTYPE
+            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
+    └───
+
+        GRABTYPE         { GrabtypeButton, GrabtypeKeycode, GrabtypeEnter,
+                           GrabtypeFocusIn}
+
+        GRABMODIFIERINFO {   status:    Access
+                             modifiers: CARD32 }
+
+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
+            is not GrabtypeButton, this argument is ignored.
+        deviceid
+            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.
+        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.
+
+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
+        - 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 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/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:
+
+        - 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.
+
+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.
+
+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 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.
+
+    ┌───
+        XIPassiveUngrabDevice
+            deviceid:        DEVICEID
+            detail:          CARD32
+            grab_type:       GRABTYPE
+            grab_window:     Window
+            num_modifiers:   INT16
+            modifiers:       MODIFIERINFO
+    └───
+
+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
+            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 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
+            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 XIDeleteProperty.
+
+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:
+----------
+
+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
+        RawKeyPress
+        RawKeyRelease
+        RawButtonPress
+        RawButtonRelease
+        RawMotion
+        Enter
+        Leave
+        FocusIn
+        FocusOut
+        PropertyEvent
+
+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.
+
+
+    ┌───
+        HierarchyEvent:
+            EVENTHEADER
+            flags:                      SETofHIERARCHYMASK
+            num_info:                   CARD16
+            info:                       LISTofHIERARCHYINFO
+    └───
+
+
+    HIERARCHYMASK { MasterAdded, MasterRemoved, SlaveAttached, SlaveDetached,
+                    SlaveAdded, SlaveRemoved, DeviceEnabled, DeviceDisabled }
+
+    HIERARCHYINFO { deviceid:           DEVICEID,
+                    attachment:         DEVICEID,
+                    type:               DEVICEUSE
+                    enabled:            BOOL
+                    flags:              SETofHIERARCHYMASK}
+
+    flags
+        Set of the changes that have occured, causing this event.
+    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, 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.
+
+    ┌───
+        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
+        the device itself.
+    source
+        The source of the new classes.
+    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 XQueryDevice 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
+            flags:                      DEVICEEEVENTFLAGS
+            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,
+                    effective_mods:      CARD32}
+    GROUPINFO     { base_group:          CARD8,
+                    latched_group:       CARD8,
+                    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. The event type may be one of KeyPress,
+KeyRelease, ButtonPress, ButtonRelease, Motion.
+
+    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.
+    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
+        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
+            detail:                    CARD32
+            flags:                     DEVICEEVENTFLAGS
+            valuators_len:             CARD16
+            valuators:                 SETofVALUATORMASK
+            axisvalues:                LISTofFP3232
+            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.
+
+    eventtype
+        The type of event that occured on the device.
+    detail
+        The button number or keycode.
+    flags
+        Flags as described in DeviceEvent.
+    valuators_len
+        The length of valuators in 4 byte units.
+    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 or FocusIn or FocusOut
+            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
+            mods:               MODIFIERINFO
+            group:              GROUPINFO
+            buttons_len:        CARD16
+            buttons:            SETofBUTTONMASK
+    └───
+
+    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.
+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
+    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. 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.
+    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. This field is
+        unspecified for focus in/out events.
+    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.
+
+    ┌───
+        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.
+
+
+//                            ❧❧❧❧❧❧❧❧❧❧❧
diff --git a/specs/XIproto.txt b/specs/XIproto.txt
new file mode 100644
index 0000000..1095a26
--- /dev/null
+++ b/specs/XIproto.txt
@@ -0,0 +1,2576 @@
+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
+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}
+
+   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
+                =>
+                        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.
+
+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
+                =>
+                        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.
+
+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, 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.
+
+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, 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 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 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 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 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.
+
+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 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]
+
+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). 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.
+
+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.
+
+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: <see below>
+                    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 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.
+
+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.