summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMatthieu Herrb <matthieu@cvs.openbsd.org>2010-05-18 19:25:29 +0000
committerMatthieu Herrb <matthieu@cvs.openbsd.org>2010-05-18 19:25:29 +0000
commitdeed853a98813032c070cc01de9defc5ca33b21f (patch)
treedfca49a2dc15b1159cf77f9b39f31d9252ebda68
parente3927c0603c5449094cda0a6ecb83f1d347ce18c (diff)
Update to inputproto 2.0. Tested on a bulk ports build by naddy@.
-rw-r--r--proto/inputproto/ChangeLog1391
-rw-r--r--proto/inputproto/Makefile4
-rw-r--r--proto/inputproto/Makefile.am11
-rw-r--r--proto/inputproto/XI.h13
-rw-r--r--proto/inputproto/XI2.h181
-rw-r--r--proto/inputproto/XI2proto.h976
-rw-r--r--proto/inputproto/XI2proto.txt1677
-rw-r--r--proto/inputproto/XInput.h1273
-rw-r--r--proto/inputproto/XIproto.h1038
-rw-r--r--proto/inputproto/XIproto.txt2542
-rw-r--r--proto/inputproto/configure.ac8
11 files changed, 7253 insertions, 1861 deletions
diff --git a/proto/inputproto/ChangeLog b/proto/inputproto/ChangeLog
index c04e4d6ef..bbfc73ef3 100644
--- a/proto/inputproto/ChangeLog
+++ b/proto/inputproto/ChangeLog
@@ -1,60 +1,881 @@
-commit d38e79ca3ddd6031ca4a335eb2faf99294a6731f
-Author: Peter Hutterer <peter.hutterer@redhat.com>
-Date: Wed Nov 26 21:37:06 2008 +1000
+commit 34a9ab1151fb7b35a371cc98a34a20993816f78a
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Oct 2 11:38:12 2009 +1000
- inputproto 1.5.0
+ inputproto 2.0
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-commit 5829370cafb112e488156e7ac1dd7902cfd1659a
-Author: Peter Hutterer <peter.hutterer@redhat.com>
-Date: Mon Nov 17 10:58:31 2008 +1000
+commit 0470d29c1e690f3784ca1a42f6d27aa322f9b37a
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Thu Oct 1 16:47:11 2009 +1000
- Remove Configure/QueryDeviceProperty.
- (cherry picked from commit 18ef04f8a2026cca5d2d2b796ec2ea1c949bad36)
+ Add XIproto.txt
- Removing Configure/QueryDevice property from XInput.h as well.
- Not cherry-picked as XInput.h is moved to libXi in master.
+ This is the XI protocol specification document that used to be in xorg-docs.
+ It's now moved here, and if it ever sees updates, the updates will only
+ apply to here.
- Conflicts:
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit bda99e7e5ac528aaa08664b21f0380db67bd2ac2
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Oct 2 11:31:13 2009 +1000
+
+ Require macros 1.3 for XORG_DEFAULT_OPTIONS
- XIproto.h
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-commit 6a4aefa04bb95c05d223027cebbe83c4117829f0
-Author: Peter Hutterer <peter.hutterer@redhat.com>
-Date: Thu Sep 18 16:28:09 2008 +0930
+commit 472309905a66245c9fd420ef64716ec630216323
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Aug 21 14:25:51 2009 +1000
- Add XI_JOYSTICK type.
- (cherry picked from commit c9454a8e84b2dce54bb346ff1aafb32e3c0ac5b9)
+ inputproto 1.9.99.902 (RC 2)
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-commit 6af8447fab4a06d943398e6540e6b869d8a714ae
-Author: Peter Hutterer <peter.hutterer@redhat.com>
-Date: Mon Nov 17 10:13:15 2008 +1000
+commit f3f79c0642f33b6a39a0f7fdab2bcb06d9cab0f7
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Aug 25 10:04:01 2009 +1000
- Undef Atom after we're done so we don't pollute users of XIproto.h
- (cherry picked from commit 36c8a6f3faf56a8f8ca31455812c9132b379b1b3)
+ Device cursors are deleted once the window or the device disappear.
- Conflicts:
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit ae4588ff0c6e5cc7009e4ac78a3f953bc399bd84
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Aug 21 14:24:23 2009 +1000
+
+ XIWarpPointer needs to take FP1616 for positions.
+
+ This was already in the spec but the protocol itself hadn't cought up with
+ it.
- XIproto.h
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-commit 72fb0941fff83f00fb039f865edcf5d25584757c
-Author: Peter Hutterer <peter.hutterer@redhat.com>
-Date: Mon Nov 17 10:12:50 2008 +1000
+commit 8eccc169c045fcf68b5a0974c49a8e6863894cf3
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Aug 21 13:56:11 2009 +1000
- Make sure Atoms are defined as CARD32.
- (cherry picked from commit c919917e375aefaf473570c1b25b3c22231e858d)
+ Replace four leftover INT16 with int16_t.
+
+commit 68cdaf8d26e133f700404bca93b18240aa6b8f86
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Aug 21 13:55:52 2009 +1000
+
+ XIQueryPointer only works on master pointers and floating slaves.
- Conflicts:
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit d9aa0917b491e9d6ef887ac59fb7a01fb428fa62
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Aug 18 15:05:09 2009 +1000
+
+ XI2proto: XIChangeCursor request requires a master pointer.
+
+ State that the server will return BadDevice in this case.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 4f9d8d49eca460b24daca2a28a2c644f7edc19bd
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Aug 18 15:04:47 2009 +1000
+
+ XI2proto.txt: typo fix
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 6719ae1ed024270f7fe1cb6bbee1f84cdaeba90c
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Aug 7 10:39:46 2009 +1000
+
+ Remove eventtype field from xXIRawEvent.
+
+ With c455db2, raw events were split up into using multiple evtypes instead
+ of a sub event type. The eventtype field itself however has not been removed
+ and was unused by both the server and the library.
+
+ Field converted into a padding field, wire layout stays the same.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 1a7eb6de82bd61fc16f2a3f000d4d3b9d418dcd0
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Aug 4 10:43:52 2009 +1000
+
+ inputproto 1.9.99.901 (RC 1)
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit d8a1c1b1aba92e60d2fcad7cdf5abe77f3c9ae10
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Wed Aug 5 14:52:45 2009 +1000
+
+ Revert "XI2proto.txt: grabbing a slave does not detach it anymore."
+
+ Detaching a slave device during an explicit grab makes sense from a UI
+ perspective. It allows a client to get exclusive access to a device without
+ that device's events also feeding into the respective master device.
+
+ Thanks to Thomas Jaeger for his contribution.
+
+ This reverts commit d0b1e55b876a29a7c820ec12d7b9cb5e081e1944.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit b31776bb5b416ffa15235611954e68d386edf674
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Jul 31 08:52:43 2009 +1000
+
+ XI2proto.txt: document ClientPointer in more detail.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 221aed39ac45ce4bf3b28c7956bc00ea3c9dbf57
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Jul 28 11:15:12 2009 +1000
+
+ XI2proto.txt: don't put field names in quotes.
+
+ This was done inconsistently anyway so get rid of it alltogether.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 5e76f4ca69fedab770280854ab238587eb5e10fb
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Jul 28 10:12:06 2009 +1000
+
+ XI2proto.txt: typo fixes and minor clarifications.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 26f244fadc188cc76f53c82c10bc3b308964f20c
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Jul 28 11:12:50 2009 +1000
+
+ XI2proto.txt: sourceid on DeviceChanged is the device.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit b877309713930f92f04e2485bc40e1b6730d7e77
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Jul 28 11:12:26 2009 +1000
+
+ XI2proto.txt: passive grabs can take XIAll{Master}Devices.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit d0b1e55b876a29a7c820ec12d7b9cb5e081e1944
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Jul 28 10:53:08 2009 +1000
+
+ XI2proto.txt: grabbing a slave does not detach it anymore.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 9f5d450fda41f936a8e12863aec544d69b30132f
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Jul 28 10:38:21 2009 +1000
+
+ XIproto.txt: clarify that the ClientPointer is set, even if implicitly.
+
+ It is indistinguishable for the client whether the the server chooses a
+ ClientPointer or whether the CP was set through an XISetClientPointer
+ request. The only thing that matters is that a device was actually assigned
+ and will be used in the future.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 7b988fcae5135d064388084ef190966c3e38702c
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Jul 28 10:10:10 2009 +1000
+
+ XI2proto.txt: padding bytes must be zero.
+
+ Padding bytes zeroed out ensures that future versions of the XI2 protcol may
+ use these padding bytes with a defined state. The server should ignore
+ padding bytes depending on the client's version anyway but better safe than
+ sorry.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 4b414dcdbb5641ea528ccc212584f9dac816b571
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon Jul 27 15:51:17 2009 +1000
+
+ XI2proto.h: Remove special doxygen tags.
+
+ The protocol header does not include enough documentation to make the use of
+ doxygen really worthwile. Special doxygen tags beyond the very simple use of
+ /** and /**< contribute too much to the noise and make it hard to actually
+ read the code itself.
+
+ While no extra tags are added now, a run of doxygen over XI2proto and XI.h
+ still produces an acceptable output.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 0542581edcef2795c613921e66736871b44408d7
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon Jul 27 14:29:00 2009 +1000
+
+ XI2proto.txt: Add some XI1 vs. XI2 interoperability descriptions.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 7cf46d64e0f2816f76ff3e23a77e5414a8625d10
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon Jul 27 14:20:38 2009 +1000
+
+ XI2proto.txt: update list of XI2 event types.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 0e7af09fcedc3f6f86306dbf2c683d065fc41f29
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Wed Jul 22 12:11:13 2009 +1000
+
+ inputproto 1.9.99.15
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 006afb766ac1d01ad9d57035af56a5b48c6ec5d3
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon Jul 20 16:25:08 2009 +1000
+
+ XI2: remove Keysym grabs, use Keycode grabs instead.
+
+ Keysym grabs are tricky to get right for applications that are more
+ complicated than demo applications. otoh, we know keycode grabs are working.
+ So let's go with keycode grabs for now and add keysym grabs later when we've
+ sorted out the details.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit aaefb1e12229cc7bed40f6aaec3641db840aa4f2
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon Jul 13 16:05:07 2009 +1000
+
+ inputproto 1.9.99.14
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 1357361d6b2a72a3decd9307ca59cc7678ba3063
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Jul 14 16:15:19 2009 +1000
+
+ Add the enter/leave detail defines, same as the core protocol ones.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 2a3dc6c47145356a7c9e1cef59165a7ed2f2e9e2
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Jul 14 16:15:06 2009 +1000
+
+ Formatting fix, s/tabs/spaces/
+
+commit 51244a1a4f7165d995c139ba1f0d03d8a1140015
+Author: Daniel Stone <daniel@fooishbar.org>
+Date: Mon Jul 13 16:49:33 2009 +1000
+
+ Device{,Raw}Event: Add flags field.
+
+ Add a flags member to DeviceEvent and DeviceKeyEvent; the only currently
+ defined flag is KeyRepeat, indicating a repeat event (a la XKB detectable
+ autorepeat), which is only valid for key events.
+
+ Signed-off-by: Daniel Stone <daniel@fooishbar.org>
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit c455db2c251770a729d2747e6f05d53c2563b428
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon Jul 13 15:30:50 2009 +1000
+
+ XI2: Split up raw events into multiple event types.
+
+ Instead of a single XI_RawEvent type with subtypes to represent the actual
+ event, split up the event into XI_RawButtonPress, XI_RawButtonRelease, etc.
+ This way clients can select for specific raw events only instead of all of
+ them at once.
+
+ Note that raw events may be selected on master devices too, the server will
+ route them through master devices.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit f345258bf44e018e04643ccc6f02f5e40267d78c
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon Jul 13 14:37:13 2009 +1000
+
+ Fix XIMaskLen macro.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 6280b53cdbb750ef2363f5b55346a4271678ddef
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Sun Jul 12 16:19:19 2009 +1000
+
+ inputproto 1.9.99.13
+
+commit 2367e52404761ab14e0f908432f736cfc0813f8b
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Jun 23 21:01:27 2009 +1000
+
+ Add effective group and modifiers to XIGroupInfo/XIModifierInfo.
+
+ Effective modifiers are easy to calculate but let's send them down the wire
+ nonetheless. Effective group is slightly more complicated since group
+ wrapping must be taken into account - sending it down the wire simplifies
+ clients.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 3f0067b45e66ef8db785b67a36f015fd4e6a9f6c
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Thu Jun 18 00:29:44 2009 +1000
+
+ XIDeviceChangedEvents may occur on master devices too.
+
+ Prime example is a change in the number of buttons due to the availability
+ of a new slave device.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit b40f48b15e3362cc7b5aeb800b7de072ce20e4aa
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Wed Jun 17 09:09:56 2009 +1000
+
+ inputproto 1.9.99.12
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit a6edd59c440cae9cd8ac775bb4d67ab433f2aae3
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Wed Jun 17 08:53:26 2009 +1000
+
+ Use the term 'labels' to refer to button and axes labels.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit b0f7e24d210cb6d0a1c47cae39b54e56a5e996d8
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Jun 16 13:14:47 2009 +1000
+
+ Include valuator value in XIValuatorClasses
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit b2fb9f81a2a7af8656309420facd58ab610d5da1
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Sun Jun 14 08:23:56 2009 +1000
+
+ Include button state in XIButtonClasses.
+
+ Without including the state in a button class, it is impossible to know the
+ state of a device until this device has pressed or released another button
+ (and thus sends an event).
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit db98b817355ed12609cff077c4a12948ac41f88d
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Sun Jun 7 17:51:04 2009 +1000
+
+ Add a source field to the class information.
+
+ In some cases it is required to know the source device of a particular
+ device class. In the future we might also do lazy copying of classes,
+ meaning that for a given device, each class may come from a different
+ source. Hence the source id should be included for each class.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 48cf9a56066c4b5a2136310da3cd6846dcf3b607
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Wed Jun 10 15:13:03 2009 +1000
+
+ Add note that bumping XI_LASTEVENT requires changes to the server.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit bac0e02889392534138e8b98e516a0ea3c76847a
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Wed Jun 10 15:12:39 2009 +1000
+
+ Ensure XIAnyModifier is an unsigned int.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 1d59de593c5aac8e109fcb3c1173d4dc14742dee
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Jun 12 15:50:26 2009 +1000
+
+ XISelectEventsReq should use win (not window), like all requests.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit f711dfae6872371ec41aeeecda9570a57d0a746c
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Jun 12 15:50:07 2009 +1000
+
+ XI2proto: document XSetClientPointer behaviour on None window, etc.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 17a6ad094266cc14efb75cca36de0b8adff9d35b
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon Jun 8 15:40:21 2009 +1000
+
+ inputproto 1.9.99.11
+
+commit 03309cfbc19fc16b5ae25f8511b3ef28fcd66818
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon Jun 8 14:23:27 2009 +1000
+
+ xXIHierarchyEvent should list num_info, not num_devices.
+
+ The structures following the request are referred to as "info", having a
+ name of "num_devices" is misleading as the number of info structs does not
+ always reflect the number of devices (e.g. if a device got removed).
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 751f2d6c0fa88a6bfc380b57d72ae41ec790249d
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon Jun 8 13:31:28 2009 +1000
+
+ Rename XICreateMaster to XIAddMaster for consistency.
+
+ We use add/remove for slave devices, add/remove for the hierarchy changed
+ flags, so let's use add/remove to create a new device as well.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 44f2419e56b006b8f182ea5746e9b6eef205ff37
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon Jun 8 12:35:29 2009 +1000
+
+ Update comment referring to an old naming scheme.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 6e20d1fc2517e68b17f9da2e94f78e9d64a8c408
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon Jun 8 09:51:53 2009 +1000
+
+ Document BadValue error for XIHierarchyEvents selection on devices.
+
+ These events may only be selected on the XIAllDevices fake device.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 56da196866d8c883b9b25b04dd584fbcb159ffd3
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Thu Jun 4 13:35:42 2009 +1000
+
+ XIQueryVersion may return a BadValue for major_version less than 2.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 0d75208a554577d652ca9e2856a4f12b0d720a1f
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon Jun 1 09:12:42 2009 +1000
+
+ Move the XI2 index into versions[] over to XI2.h
+
+commit 8aff0836afaef4397f9df273cc90edeca1ab9641
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri May 29 13:25:32 2009 +1000
+
+ Specify modifier interactions with attached slave devices on passive grabs.
+
+commit e102c504ec58e6bc4620e7cd01ea34de665e5fd9
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Wed May 27 14:12:58 2009 +1000
+
+ inputproto 1.9.99.10
+
+commit 6b61bef5da91ca24d1bfcf9d314b8b8587c3e4fc
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Thu May 28 08:20:37 2009 +1000
+
+ Mirror the core enter/focus modes and add the passive grab mode.
+
+ If an enter/focus grabs activates (or deactivates), send an extra set of
+ enter/focus in (or leave/focus out) events to the grabbing client with mode
+ XIPassiveGrabNotify.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 1b2dc24bf51a325ea3fafb46768467675b00be52
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon May 25 15:48:25 2009 +1000
+
+ Add Enter/FocusIn passive grabs.
+
+ Same behaviour as button/keysym grabs but triggered on enter/leave and
+ focus in/out events.
+
+commit d0c6633f7bc2519c0b6c662a1f39a8ce56ab768a
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Wed May 27 13:11:49 2009 +1000
+
+ XI2proto.txt: remove one more keycode mentioning, fix typo
+
+commit 31f492bf9471fc593275fb95f97312db21439641
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon May 25 12:14:12 2009 +1000
+
+ Add XIGetSelectedEvents request and reply.
+
+ Counterpart to XISelectEvents, used to retrieve event masks from the server.
+
+commit f065f6c12aa5c2e79f1af38908e86d20a2efdc86
+Author: Benjamin Close <Benjamin.Close@clearchain.com>
+Date: Tue May 19 11:27:03 2009 +1000
+
+ XI2proto.h: fix two comments referring to the old naming scheme.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 3aca2d6ba53c8ddf5c40ae4b1411e50134b404a5
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri May 15 20:14:16 2009 +1000
+
+ inputproto 1.9.99.9
+
+commit 8c2872367765170c37f829d635c97dc3d68861b7
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Sat May 16 11:49:21 2009 +1000
+
+ Document naming conventions for XI2proto.h.
+
+commit b32e5830c0acbdba4798fad107bf8404c978753c
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Sat May 16 11:46:44 2009 +1000
+
+ XI2proto: define Window, Cursor, Atom and Time as uint32_t.
+
+ Since we're using stdint in the rest of the file, might as well ignore
+ CARD32 here.
+
+commit f4f09d40e0fd94d267b280f2a82385dca1141347
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Sat May 16 11:31:03 2009 +1000
+
+ XI2.h: remove XI2Mask, add XISetMask and friends.
+
+ XISetMask, XIClearMask, XIMaskIsSet serve to set, clear or check a bit in
+ the provided array.
+ XIMaskLen is a macro to get the minimum length of a mask for a given event
+ type.
+
+ They are expected to be common ways to deal with event masks, i.e. clients
+ will do:
+
+ unsigned char mask[XIMaskLen(XI_ButtonRelease)] = {0};
+ XISetMask(mask, XI_ButtonPress)
+ XISetMask(mask, XI_ButtonRelease)
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 0ae6581bc62b3b734c84b12e9a92d945d3e98aa7
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Sat May 16 11:25:49 2009 +1000
+
+ Add XIAnyButton and XIAnyKeysym.
+
+commit 4cc6992b08b6c7aed0d1242e3382fb53d51a0fe2
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Thu May 14 12:09:38 2009 +1000
+
+ XIQueryPointer needs to include sensible button/modifier state.
+
+ This includes shuffling the xXIModifierInfo and xXIGroupInfo structs to the
+ common structs section.
+
+commit d041f30777c09f07ac79fface61bfbfa654306f2
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Thu May 14 10:29:49 2009 +1000
+
+ Add an introduction to XI2proto.txt
+
+commit e1138da90235797248f38d7f613566fb8418c396
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue May 12 19:24:31 2009 +1000
+
+ XI2proto.txt: remove more mentioning of keycode grabs
+
+commit 7aba20ed4c404b80112a0bb28220a2c646f319e4
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue May 12 16:51:05 2009 +1000
+
+ Remove superfluous "Device" from protocol requests and events.
+
+ Anything with prefix XI is per-device anyway.
+
+commit 12635cbd4aea0ba3b38b96682d63bb71ba8c737e
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue May 12 16:14:01 2009 +1000
+
+ Add per-device flags to XIDeviceHierarchyEvents
+
+commit 886d2aceb77070292e984ed2b25e31ac9c82aba7
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue May 12 13:45:48 2009 +1000
+
+ Define Cursor as CARD32.
+
+ Reported-by: Benjamin Close <benjamin.close@clearchain.com>
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 32277164bcff6b18a498f12886828187e1f96249
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon May 11 14:35:35 2009 +1000
+
+ XI2proto.h: doxygen-ify
+
+commit e9dfa4015520abd49779e96e7d54da763a54484b
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon May 11 13:46:53 2009 +1000
+
+ XI2proto.h: s/uint32_t/Time/ where appropriate
+
+commit a47a2b50845499e3f9144739db5644952faf8ea2
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Thu May 7 16:19:47 2009 +1000
+
+ Prefix all XI2 constants with "XI" -> inputproto 1.99.9.8
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 2edc35c032c2792d9528a396f596d466d4f10764
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Wed May 6 16:33:34 2009 +1000
+
+ Add XI2 property requests.
+
+ Basically the same as XI 1.5, save the 16 bit deviceids.
+
+commit 504b480c946fe4c4a96500ef8c5da100b787ab32
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Sat Apr 25 11:08:21 2009 +1000
+
+ XI2: add passive grabs.
+
+ Most notably XI2 provides keysym grabs instead of keycode grabs.
+
+commit 5d60550fdeb375a88ac9da42bcad4ee69b0df64a
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Sat Apr 25 10:43:43 2009 +1000
+
+ XI2 spec: Add some more Grab/Ungrab/AllowEvents documentation.
+
+commit 6d28cb22ada7a1abb6ab11863c82c9834d1a4b00
+Author: Benjamin Close <Benjamin.Close@clearchain.com>
+Date: Wed Apr 22 13:10:50 2009 +0930
+
+ Define the Cursor datasize correctly
+
+ On 64 bit machines, without Cursor defined Xlib would allocate 64 bits
+ rather than 32 to any structs using Cursor. This led to data not
+ correctly being available on the wire hence the Xserver would do strange
+ things. We hence define Cursor to what it should be and make sure
+ we undefine it after we've finished to users of XIproto.h aren't affected
- XIproto.h
+ Fix-by: Peter Hutterer <peter.hutterer@who-t.net>
+ Signed-off-by: Benjamin Close <Benjamin.Close@clearchain.com>
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-commit 6ee1ad8951ff811dc2618c9bd26cd42096ab2ecc
+commit 589dc6ffa509c1c7da2d94dc89b2246c3dfdc81d
+Author: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
+Date: Wed Apr 22 09:00:14 2009 +1000
+
+ Fix typo in XI2proto.txt
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 3380ae0ac0220c7f8fea9df855113819b472a233
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Thu Apr 16 11:37:20 2009 +1000
+
+ Add XIAllowEvents.
+
+ Basically the same as the core protocol AllowEvents.
+
+commit 3c273d7145ed5f53b54d2812ad2ac8430d449555
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Sun Apr 19 21:33:42 2009 +1000
+
+ Change FP1616 into a single int32_t.
+
+commit 8914a9a2a99e334f66d6040d05b3d5f5b603780f
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Apr 10 17:31:05 2009 +1000
+
+ Add GrabDevice and UngrabDevice XI2 requests.
+
+commit 1956df7e45a49464dee2d7beff36f38ea00e9cb8
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Apr 10 14:56:20 2009 +1000
+
+ Revert "Add major/minor version as supported by client to GetExtensionVersionReq."
+
+ This reverts commit f6e41306f76de966884d4b72c5fb5e5d6d534ce4.
+ Sending the supported version hidden in another request is potentially
+ dangerous, so let's not do it.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 55ee1f97d446403b9c2ed2e3c321afa4d683c93f
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Apr 10 14:35:00 2009 +1000
+
+ XI2proto.txt: fix typo
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit d5105dc8516dd89cad0cd841081ff85d0a672bae
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Apr 10 14:17:51 2009 +1000
+
+ We don't need to define KeyCode and Mask.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 75daa0db2c87d065e80afdf248965f34f7073cd5
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Apr 10 14:17:02 2009 +1000
+
+ Undef Window, Time, etc. after usage again to avoid pollution.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 6c9785ea2581924fc748f61160a2faa4ab8eded0
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Mar 3 15:15:50 2009 +1000
+
+ Remove IsFloating - we don't need this in XI 1.x anymore.
+
+commit 069880638b1c2af821c6d84fde4119668c533063
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Mar 3 15:13:22 2009 +1000
+
+ Move XI_2_Major/Minor to XI2.h
+
+commit 2570457174fb951d3f5f725f87e8f7f45059158b
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Mar 3 16:13:05 2009 +1000
+
+ Move AttachToMaster, Floating to XI2.h
+
+commit 1d933800acfa31f0a8f014224c1708f0076f3db0
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Mar 3 15:58:24 2009 +1000
+
+ Move CH_* constants to xi2
+
+commit 5aa07308a10315f9305cd9637c71f98432c75ecf
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Wed Feb 4 14:33:57 2009 +1000
+
+ Remove XI2 requests from XIproto.h
+
+ All requests been moved to XI2proto.h. Only ExtendedGrabDevice is gone for
+ good.
+
+commit 05f997e68921a1443728a9c58050eb82b73eaea8
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Thu Feb 26 15:22:55 2009 +1000
+
+ Bump to 1.9.99.7
+
+commit 7a73c3c64b1affa946deb66dd22042ee12fd747d
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Thu Mar 12 15:43:26 2009 +1000
+
+ Add XISetDeviceFocus and XIGetDeviceFocus requests
+
+commit 0ca1de737aa5cd714a4df3a45422dce415f9df55
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Wed Mar 11 16:32:06 2009 +1000
+
+ Add focus events
+
+commit da74983b7d18ad06fe828040072d4a985ce4d448
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Wed Mar 11 13:32:09 2009 +1000
+
+ Add buttons + modifier/group information to enter/leave events.
+
+commit c9ebfba4a128f0d0eda920a02af013b795adfec5
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Wed Mar 11 12:30:16 2009 +1000
+
+ Define FP1616 as one int16_t, one uint16_t.
+
+commit 2339bc5b0eea89e676ac58a38ac5eb6a8ae6e6f9
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Mar 10 15:42:28 2009 +1000
+
+ ValuatorInfo moved to FP3232
+
+commit cac1bcbf6d544f29c3379bc0462bb237e8ff8399
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Mar 10 15:35:04 2009 +1000
+
+ Add FP3232 typedef.
+
+commit fc7f67959ad72c76e852827963d6a42b7d533b89
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Mar 10 12:26:18 2009 +1000
+
+ XI2: remove button state from the RawEvent.
+
+ A RawEvent is supposed to represent the state posted by the device. If a
+ client needs button state, then the client must keep track of it.
+
+commit d2ba9af0517f54fb58358e41859f5e4ead9b64f2
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Thu Feb 26 15:10:28 2009 +1000
+
+ Split CH_ChangeAttachment into CH_AttachSlave and CH_DetachSlave
+
+ CH_ChangeAttachment is still there, but won't be for long.
+
+commit 69f5b8a3ff8258cc6d50cca7d5382b0fe9fed893
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Thu Feb 5 15:57:56 2009 +1000
+
+ Add XI2.h and XI2proto.h, and a few required defines to XI.h
+
+commit 27dc5a8313d48a78a628563132142a97f7a47843
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Thu Feb 5 14:18:28 2009 +1000
+
+ Add XI2 protocol specification document.
+
+commit f39d3c8d6035fe65ad788987e291b99ad22448dd
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Wed Feb 4 15:21:55 2009 +1000
+
+ Whitespace cleanups.
+
+ Yep. Slow day today.
+
+commit c2d426f232f214f24fba2e30766c94e643716a72
+Author: Paulo Cesar Pereira de Andrade <pcpa@mandriva.com.br>
+Date: Tue Jan 27 20:06:28 2009 -0200
+
+ Janitor: Correct make distcheck and dont distribute autogen.sh
+
+commit 7203036522ba9d4b224d282d6afc2d0b947711ee
Author: Peter Hutterer <peter.hutterer@redhat.com>
-Date: Fri Aug 15 14:21:24 2008 +0930
+Date: Fri Oct 31 16:33:25 2008 +1030
- Remove RCS tags, typo fix.
- (cherry picked from commit c2d47b04c55cf72aef6c13a9e2cc4b41abfca673)
+ Bump to 1.9.99.6.
-commit d81ca85c4bcdcab208e4731a5d0f7d9bffbfab67
+commit f8064629496c6061bedb7a99b788fb9d3a170f11
Author: Peter Hutterer <peter.hutterer@redhat.com>
Date: Fri Oct 31 17:53:39 2008 +1030
@@ -63,43 +884,93 @@ Date: Fri Oct 31 17:53:39 2008 +1030
This way, it can be type-cast to deviceKeyButtonPointer to extract the
deviceid, which is (aside from time) the only thing it has in common with
those anyway.
- (cherry picked from commit f8064629496c6061bedb7a99b788fb9d3a170f11)
-commit e22b0ace88447a87c0b19d062a678880529b1b3b
+commit 90a86701e3b9feafa05f44649a8314f06285fab5
Author: Peter Hutterer <peter.hutterer@redhat.com>
-Date: Mon Aug 25 11:34:47 2008 +0930
+Date: Wed Oct 8 21:39:20 2008 +1030
- Add libXi's property interfaces.
+ Remove window access protocol requests.
- XInput.h was removed from inputproto, hence this commit is not a cherry-pick
- but a copy of the changes to XInput.h in libXi.
+ This is a bad idea. It didn't provide security and you can get the same
+ functionality as you did with normal event registration.
+
+commit 36c8a6f3faf56a8f8ca31455812c9132b379b1b3
+Author: Julien Cristau <jcristau@jazzy.liafa.jussieu.fr>
+Date: Wed Oct 15 10:33:51 2008 +0200
+
+ Undef Atom after we're done so we don't pollute users of XIproto.h
+
+commit c919917e375aefaf473570c1b25b3c22231e858d
+Author: Peter Hutterer <peter.hutterer@redhat.com>
+Date: Wed Oct 15 10:34:21 2008 +1030
+
+ Make sure Atoms are defined as CARD32.
-commit 0a87cb3aac72adbbb81c7ac7ac04551547bf8b56
+commit 2166b77ea60bd9cd87f1311a2e7d461db071cb07
+Author: Peter Hutterer <peter.hutterer@redhat.com>
+Date: Fri Sep 26 10:11:04 2008 +0930
+
+ Bump to 1.9.99.5.
+
+commit 93c1ea035b46614fd907e33303c6a876d32e2c78
+Author: Peter Hutterer <peter.hutterer@redhat.com>
+Date: Fri Sep 26 09:37:48 2008 +0930
+
+ Remove default properties (XI_PROP_MODE, XI_PROP_ENABLED)
+
+ These should be defined by the server, not the protocol.
+
+commit 18ef04f8a2026cca5d2d2b796ec2ea1c949bad36
+Author: Peter Hutterer <peter.hutterer@redhat.com>
+Date: Thu Sep 18 15:00:54 2008 +0930
+
+ Remove Configure/QueryDeviceProperty.
+
+commit c9454a8e84b2dce54bb346ff1aafb32e3c0ac5b9
+Author: Peter Hutterer <peter.hutterer@redhat.com>
+Date: Thu Sep 18 16:28:09 2008 +0930
+
+ Add XI_JOYSTICK type.
+
+commit 20a0c8433ee50ecef1dfdb218674c7729bbacb99
+Author: Peter Hutterer <peter.hutterer@redhat.com>
+Date: Thu Sep 18 15:00:01 2008 +0930
+
+ Don't include Xmd.h.
+
+commit 3e7b663e7d5a40a115eba3cabfc173549ff89357
+Author: Peter Hutterer <peter.hutterer@redhat.com>
+Date: Fri Aug 15 15:01:16 2008 +0930
+
+ inputproto 1.9.99.4
+
+ Backported device properties.
+
+commit fabe087cebb11c6a2600e57c6f7a52fda2efea29
Author: Peter Hutterer <peter.hutterer@redhat.com>
Date: Fri Aug 15 14:50:23 2008 +0930
Protect against C++ includes.
- (cherry picked from commit fabe087cebb11c6a2600e57c6f7a52fda2efea29)
-commit e507aaaa74eeb02896843eb1815b614adf47a24a
+commit c2d47b04c55cf72aef6c13a9e2cc4b41abfca673
+Author: Peter Hutterer <peter.hutterer@redhat.com>
+Date: Fri Aug 15 14:21:24 2008 +0930
+
+ Remove RCS tags, typo fix.
+
+commit 7c9620d8232e5c05115746055a832363a528ac2d
Author: Peter Hutterer <peter.hutterer@redhat.com>
-Date: Mon Aug 25 10:19:37 2008 +0930
+Date: Wed Aug 13 10:00:12 2008 +0930
Back out Device Properties from XI 2, push into XI 1.5.
- (cherry picked from commit 7c9620d8232e5c05115746055a832363a528ac2d)
-
- Conflicts:
-
- XI.h
- XIproto.h
-commit c109e2ddb9cab22f185a877ab7e48002d1087400
-Author: Peter Hutterer <peter.hutterer@who-t.net>
-Date: Tue Jul 29 09:10:09 2008 +0930
+commit 54465c743354dd138f4ccacc196198e36c2ecdba
+Author: Alan Hourihane <alanh@tungstengraphics.com>
+Date: Tue Jul 29 14:15:04 2008 +0100
- inputproto 1.4.4
+ bump to 1.99.9.3
-commit f41d153886c3519ebaf767f9c0d3281b6adce030
+commit 0daf8328cfa90b038753fc409c5eb05ba3fac6d5
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue Jul 29 08:58:53 2008 +0930
@@ -107,7 +978,99 @@ Date: Tue Jul 29 08:58:53 2008 +0930
This value is used for the devchange field in the DevicePresenceNotify event
when a device's control has been modified.
- (cherry picked from commit 0daf8328cfa90b038753fc409c5eb05ba3fac6d5)
+
+commit 0d300ce64c277f4f7c7fe5fd6dca1ed768880af1
+Author: Alan Hourihane <alanh@tungstengraphics.com>
+Date: Mon Jul 21 10:33:47 2008 +0100
+
+ Bump to 1.9.99.2 for inputproto
+
+commit fe74239e93e6562ba6c268b50d6cfb36d2426bef
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Sun Jul 13 20:49:51 2008 +0930
+
+ Add #defines for XI_PROP_ENABLED, XI_PROP_MODE
+
+ These two props are expected to be supported by the server.
+
+commit 5f686651087ac9d1a15b4d8aa631f2d7f2096871
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Wed Jul 9 18:28:26 2008 +0930
+
+ Set IEVENTS back to 18, got set to 8 inadvertantly.
+
+commit bbbe35b3513510afb524e02b8227826dbd5ea87e
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Mon Jul 7 15:38:50 2008 +0930
+
+ Add XI device property requests and replies.
+
+ New requests:
+ ListDeviceProperties ... list all props of a device
+ QueryDeviceProperty ... query meta-information about a property
+ ChangeDeviceProperty ... change the content of a property
+ DeleteDeviceProperty ... delete a property
+ GetDeviceProperty ... retrieve a property
+
+ New event:
+ DevicePropertyChangedNotify ... the given property on the device has changed
+
+commit 9f1f3ef7a36fddacf30ecf867ddad90253103b6a
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Wed May 28 17:13:49 2008 +0930
+
+ Bump to 1.9.99.1.
+
+commit 834c9ba8b4a1746a5d87d793f7c40bb882712656
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Mon May 12 17:30:30 2008 +0930
+
+ Remove a leftover typedef, the code that requires it has since been removed.
+
+ Was part of the FakeDeviceData request, this request does not exist anymore.
+
+commit c6df1392e52b5edf3f25e0198c06a3a1ae3c0356
+Merge: f6e4130 8525689
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Mon May 12 17:30:15 2008 +0930
+
+ Merge branch 'master' into mpx
+
+ Conflicts:
+
+ XI.h
+
+commit f6e41306f76de966884d4b72c5fb5e5d6d534ce4
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Sat Apr 26 10:03:19 2008 +0930
+
+ Add major/minor version as supported by client to GetExtensionVersionReq.
+
+ This sort-of breaks old clients. Behaviour to be assumed is that if nbytes is
+ 0, major/minorVersion is set and specifies the version as supported by the
+ client.
+ If nbytes is non-zero, the request is trailed by the extension name (INAME)
+ and major/minorVersion is undefined. This is the behaviour of pre-MPX clients.
+
+ And then there may be clients who found that no other extension uses this
+ request and supplying a name wasn't actually necessary since it was XI anyway.
+ These clients will break. Tough luck. Read the man pages next time.
+
+commit 746f61a86d1fd37216508a3f913bf2a1d1287478
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Fri Apr 25 18:09:32 2008 +0930
+
+ Remove XInput.h. This file is now part of libXi.
+
+ XInput.h only belongs to libXi and is should not be part of the protocol
+ headers. For future revisions of this file refer to
+ git://anongit.freedesktop.org/git/xorg/lib/libXi
+
+commit b762dad06c33a9bdcdedecb9a20d218aa38d05d6
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Fri Apr 25 10:34:01 2008 +0930
+
+ Add #define IREQUESTS 45. Specifies the number of requests in XI.
commit 852568991b251e9366da167f1b746a0a1db6adf0
Author: Adam Jackson <ajax@redhat.com>
@@ -131,6 +1094,114 @@ Date: Wed Mar 5 22:06:19 2008 -0500
inputproto 1.4.3
+commit 83fe5a31cbba502482ee1f2e720aaed8f4fa86b8
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Tue Mar 4 18:10:00 2008 +1030
+
+ Add deviceid to QueryDevicePointer reply.
+
+ Doesn't hurt, we have padding left over anyway.
+
+commit 52e366d845163cdc1ffa8955d36914cd6b5f21f9
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Mon Feb 25 16:51:31 2008 +1030
+
+ Squash opcode range for MPX XI requests.
+
+ This removes the opcode holes that were left by the excessive request removal
+ of the last weeks.
+
+commit 66ba434bc5c5fd343e558b758a7e0d61dcebb1c4
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Mon Feb 25 16:45:16 2008 +1030
+
+ Remove GetPairedPointer, paired device can be found through ListInputDevices.
+
+commit 1f37b09c99df0890fbf347f3767934cdd4e586c2
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Mon Feb 25 16:28:05 2008 +1030
+
+ Remove "ungrab" from ExtendedGrabDevice request, remove XUngrabExtDevice().
+
+ That's what UngrabDevice is for, it does the same anyway.
+
+commit 1f6d53f553e580757d4c7391838a44b659812ab0
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Mon Feb 18 17:21:37 2008 +1030
+
+ Add WindowAccessAllowAll constant.
+
+ Not surprisingly the inverse of DenyAll.
+
+commit b512f47795bd125f6b04806d8a831f888febb67d
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Thu Feb 14 18:25:24 2008 +1030
+
+ Change XChangeDeviceHieararchy API.
+
+ Single-pointer to changes is enough since we have a union now.
+ Provide array first, then number of elements. This at least gives us
+ consistency within the MPX-related stuff. The rest of Xlib can't seem to make
+ its mind up about that.
+
+commit 330cfbd0ca6e6d1557e08ab0c555fe87acc7be29
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Thu Feb 14 16:33:03 2008 +1030
+
+ Make XAnyDeviceHierarchyChangeInfo a union of the possible types.
+
+ Kinda the same as the XEvent union.
+
+ Some whitespace fixes too.
+
+commit d5245e8b85deec6f76bec2c9599da59516e50cca
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Thu Feb 14 09:17:34 2008 +1030
+
+ Whitespace fixing and sz_RegisterPairedClient removal.
+
+commit 3c24865ad98557a5bc3e12c954eefaffff01bf36
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Thu Feb 14 09:15:11 2008 +1030
+
+ Remove GrabAccessControl and FakeDeviceData.
+
+ Both aren't thought out enough to justify their inclusion in the first version
+ of MPX.
+
+commit 6a91ee1bd1d4751d09f2e4aa832913bc66ae4602
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Tue Feb 12 19:19:58 2008 +1030
+
+ Remove RawDeviceEvent - for now anyway.
+
+ Wasn't quite as thought-out as it should be. Throwing it out for now, to get
+ the rest of MPX more stable.
+
+commit 1d097c26264b657689d74f3f0a77cd1aa4f7e576
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Tue Feb 12 19:17:51 2008 +1030
+
+ Remove pairingChangedNotify event.
+
+ I swear I already removed that before... Anyway, we don't need it anymore,
+ since pairings can't be changed anyway. Hooray for the device hierarchy.
+
+commit be9e285258b8ea90628bbb5ae65bf74bdc59338b
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Tue Feb 12 15:04:24 2008 +1030
+
+ Remove "shared" field from QueryDevicePointer.
+
+ If it's a slave device, it's shared, if it's a master device it has its own
+ cursor. No need for this field.
+
+commit bd20f0ebd5e71fd03b3140960c3960bc50bd4273
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Wed Jan 23 15:47:56 2008 +1030
+
+ Add a device id to XiSelectEvent.
+
commit 096b20bf5492d248b5c8ff0c1c28e221d59db724
Author: Jesse Barnes <jesse.barnes@intel.com>
Date: Mon Jan 21 15:28:49 2008 -0800
@@ -140,12 +1211,74 @@ Date: Mon Jan 21 15:28:49 2008 -0800
On 64 bit hosts, CARD32 may be undefined unless we use Xmd.h to define it for
us. Apparently X.h is no longer sufficient.
+commit 640a97d321cdc5fd2f34265cba86da40463f8e48
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Tue Dec 18 15:47:01 2007 +1030
+
+ Move deviceid in XDeviceCrossingEvent up to follow window.
+
+ This makes XDeviceCrossingEvents in line with the other events who have the
+ same initial ordering of things.
+
commit 9359e625787761e6b3df15f29bbf842c67a9516d
Author: James Cloos <cloos@jhcloos.com>
Date: Thu Dec 6 16:39:02 2007 -0500
Replace static ChangeLog with dist-hook to generate from git log
+commit 92f083437f3129bb67cd4599ad776b8b691f0b56
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Tue Nov 13 17:22:21 2007 +1030
+
+ Remove RegisterPairingClient, deprecated with the device hierarchy now.
+
+commit 14e6e7bad06a560ec943654b94e05d4293709f2c
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Tue Nov 13 11:29:06 2007 +1030
+
+ Add DeviceClassesChangedEvent.
+
+commit 685a2dd32736956f5175afb9bc5773c829725fea
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Thu Nov 8 17:26:35 2007 +1030
+
+ Add DeviceHierarchyChangedEvent.
+
+ Uses same event type as the now removed PointerKeyboardPairingChangedNotify.
+
+ (removing the RandomStringEvent too, should have been gone a while ago)
+
+commit 6037b37a5bf03f0b38db6a83fe1bc48551b8363c
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Fri Oct 19 10:22:51 2007 +0930
+
+ Add XChangeDeviceHierarchy and its components.
+
+commit 52e2f24b3a21741d2fb0614642fd5b12b72c0d3d
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Thu Oct 18 12:23:34 2007 +0930
+
+ Create new XAttachInfo class for attachment info (slave devices).
+
+ Thanks to XLibs design we can't just change XDeviceInfo without breaking the
+ ABI. So here's a new class that isn't actually a class on the wire.
+
+commit 3c5555544e06f1be70e6981446e2a92dc1e2aecd
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Thu Oct 18 10:39:40 2007 +0930
+
+ Add XI version 2 defines.
+
+commit 6a0ffc2f461bd41a223732551e0ea1f05c293028
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Wed Oct 17 12:38:38 2007 +0930
+
+ xDeviceInfo: add "attached" field (replace previous padding).
+
+ If use is set to IsXExtensionPointer/Keyboard/Devices, attached indicates the
+ device ID of the master device it is attached to. If the device is floating,
+ attached is set to IsFloating.
+
commit 4b22047f347d8fd65a36b2fc90e1a87dff8e93e3
Author: Eamon Walsh <ewalsh@tycho.nsa.gov>
Date: Thu Sep 27 12:27:19 2007 -0400
@@ -153,7 +1286,7 @@ Date: Thu Sep 27 12:27:19 2007 -0400
XI.h needs X.h for CARD32 on 64-bit systems.
commit f033750780b74d72056da93fd9a91140a978891b
-Merge: 369dd28... 96b0c13...
+Merge: 369dd28 96b0c13
Author: James Cloos <cloos@jhcloos.com>
Date: Mon Sep 3 06:17:20 2007 -0400
@@ -173,6 +1306,55 @@ Date: Fri Aug 31 17:58:27 2007 +0930
No source changes, the 1.4.2 tarball had a busted configure script.
+commit 0e9f8468ba15a55ddba7fb8c263a80091e9decde
+Author: Paulo Ricardo Zanoni <prz05@c3sl.ufpr.br>
+Date: Tue Jul 10 10:16:06 2007 +0930
+
+ Change some calls to use XID* instead of char* for device id lists.
+
+commit 5e4ff6bf4590d856966f151529d27be0eb070804
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Thu May 17 20:19:29 2007 +0930
+
+ Move deviceid around in deviceEnterNotify, make room for detail field.
+
+commit 3d164140845c2ff65d84b56977b1722e95882f1c
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Thu May 17 20:19:02 2007 +0930
+
+ Add event_type to RawDeviceEvent to store matching core event type.
+
+commit 42a6b9b643d22ca8df64757cf497d2c7ac2dee65
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Mon May 14 18:03:53 2007 +0930
+
+ Add ExtendedGrabRequest and the matching reply.
+
+commit ccbe2e63123c58041a3c32ae6a21b05bd8c72b04
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Wed May 2 18:19:11 2007 +0930
+
+ Add xFakeDeviceDataReq
+
+commit b12514254cb1d2b91381b59251440b22e36052fb
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Wed May 2 09:43:48 2007 +0930
+
+ Providing a device id for a RawDeviceEvent may not be a bad idea.
+
+commit ce7bbfb7e0ecaf977c4ec8e760c634cebf8ac167
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Tue May 1 22:31:09 2007 +0930
+
+ Add XGE support and event types for RawDeviceEvent and PairingChanged event.
+
+commit 02c50062d357bc5d43ab4440eb195a33df0ec8b9
+Merge: f0baffd 310a93f
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Fri Apr 27 14:43:43 2007 +0930
+
+ Merge branch 'master' into mpx
+
commit 310a93f8e194aa070b0f1d40c8fd5ae941908dbe
Author: Peter Hutterer <peter@cs.unisa.edu.au>
Date: Thu Apr 26 11:06:18 2007 +0930
@@ -185,18 +1367,107 @@ Date: Tue Apr 24 22:53:27 2007 +0930
Add flags to be used for DevicePrensence's devchange field.
+commit f0baffd3a04dfe8a09b59667e5dcaa0216a94e65
+Merge: a928365 c608d82
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Mon Apr 2 16:42:46 2007 +0930
+
+ Merge branch 'master' into mpx
+
+commit a928365b91a2e25d02291844e430db9a9a62673d
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Thu Mar 22 21:14:11 2007 +1030
+
+ Change XSetClientPointer API to use an XDevice instead of deviceid.
+
+commit 4ed9be75a5d3d75782351269481db5856f7e3f60
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Thu Mar 22 17:27:32 2007 +1030
+
+ add GetClientPointer request and reply.
+ add GetPairedPointer request and reply.
+ move declaration of _XiGetDevicePresenceNotifyEvent out of the macro and wrap
+ it between extern "C". Otherwise C++ code won't be able to find it.
+
+commit 9dd8dcfa7e084d94cf3b7429eae65c93416159e3
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Fri Mar 9 15:51:07 2007 +1030
+
+ add SetClientPointer request.
+ fix typos and wrong names for access function declarations.
+
+commit de6f3fcaffe204e8f7c811f8a1599e9ed0999f9c
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Thu Feb 22 20:03:36 2007 +1030
+
+ add access control requests.
+ fix wrong field lengths for RegisterPairing request and reply.
+
+commit bb5c144c53fcb03c56b247b439915d72ad284856
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Wed Feb 21 10:03:24 2007 +1030
+
+ add xRegisterPairingClient request and reply
+
commit c608d82c6b5b87ddc8d14862f528bdd69f5f5b72
Author: Daniel Stone <daniel@fooishbar.org>
Date: Thu Feb 15 16:33:07 2007 +0200
bump to 1.4.1
+commit 157a7984f1d2e2630191b6d392bc15975a3786db
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Fri Feb 9 11:37:54 2007 +1030
+
+ add missing XWarpDevicePointer declaration
+
+commit 025e4cdde8267d678dc5105e11c7cd66e2ad89b5
+Merge: 328cd82 ad2edb6
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Thu Feb 8 10:55:55 2007 +1030
+
+ Merge branch 'master'
+
+commit 328cd827e89424292ca020d0b828154f8e4f2c17
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Thu Feb 8 10:54:34 2007 +1030
+
+ add flags field to deviceEnterNotify struct
+ add same_screen, focus to XDeviceCrossingEvent struct
+
+commit 4ab02ccbdad477a0d7a0bee79c947f50826f1a36
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Mon Jan 29 18:18:56 2007 +1030
+
+ add ChangePointerKeyboardPairing request
+ add pairingChangedNotify event
+
+commit b50c4424020d1b2b641ce15ee3ffea41a287a160
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Wed Jan 10 14:53:01 2007 +1030
+
+ add deviceEnterNotify event, DeviceEnterNotify, DeviceLeaveNotify support
+ add MPX Major/Minor version numbers
+
commit ad2edb61ffd8baf87b9ab249aa36b0c04a765f79
Author: Peter Hutterer <peter@cs.unisa.edu.au>
Date: Tue Jan 9 13:32:39 2007 +1030
Fix typo in DevicePresence() macro
+commit 3b84ea85ace4dc9fe1caf7d7c45c0c51ee35b4b2
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Mon Jan 8 12:33:41 2007 +1030
+
+ add ChangeDeviceCursor request
+
+commit cc055ae804f4dfd8b09b8993673b4670e5cf61ce
+Author: Peter Hutterer <peter@cs.unisa.edu.au>
+Date: Wed Dec 20 13:36:06 2006 +1030
+
+ add QueryDevicePointer request + reply
+ add WarpDevicePointer request
+
commit a0be30da79e35e7d503c6eeb9021c2f63beb2176
Author: Daniel Stone <daniel@fooishbar.org>
Date: Sun Oct 22 16:40:11 2006 +0300
diff --git a/proto/inputproto/Makefile b/proto/inputproto/Makefile
index b444fafbb..9bb67e263 100644
--- a/proto/inputproto/Makefile
+++ b/proto/inputproto/Makefile
@@ -1,7 +1,7 @@
-# $OpenBSD: Makefile,v 1.1 2008/03/25 23:28:19 matthieu Exp $
+# $OpenBSD: Makefile,v 1.2 2010/05/18 19:25:28 matthieu Exp $
HEADERS_SUBDIR= X11/extensions/
-HEADERS= XI.h XInput.h XIproto.h
+HEADERS= XI.h XIproto.h XI2.h XI2proto.h
PKGCONFIG= inputproto.pc
.include <bsd.xorg.mk>
diff --git a/proto/inputproto/Makefile.am b/proto/inputproto/Makefile.am
index f8d4a3207..85ca02fac 100644
--- a/proto/inputproto/Makefile.am
+++ b/proto/inputproto/Makefile.am
@@ -1,20 +1,21 @@
inputdir = $(includedir)/X11/extensions
input_HEADERS = \
XI.h \
- XInput.h \
- XIproto.h
+ XIproto.h \
+ XI2.h \
+ XI2proto.h
pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = inputproto.pc
-EXTRA_DIST = autogen.sh inputproto.pc.in
+EXTRA_DIST = inputproto.pc.in
-EXTRA_DIST += ChangeLog
+EXTRA_DIST += ChangeLog XI2proto.txt XIproto.txt
MAINTAINERCLEANFILES = ChangeLog
.PHONY: ChangeLog
ChangeLog:
- (GIT_DIR=$(top_srcdir)/.git git-log > .changelog.tmp && mv .changelog.tmp ChangeLog; rm -f .changelog.tmp) || (touch ChangeLog; echo 'git directory not found: installing possibly empty changelog.' >&2)
+ $(CHANGELOG_CMD)
dist-hook: ChangeLog
diff --git a/proto/inputproto/XI.h b/proto/inputproto/XI.h
index 7c8c111bd..7b443997c 100644
--- a/proto/inputproto/XI.h
+++ b/proto/inputproto/XI.h
@@ -113,7 +113,7 @@ SOFTWARE.
#define sz_xGetDevicePropertyReq 24
#define sz_xGetDevicePropertyReply 32
-#define INAME "XInputExtension"
+#define INAME "XInputExtension"
#define XI_KEYBOARD "KEYBOARD"
#define XI_MOUSE "MOUSE"
@@ -135,6 +135,8 @@ SOFTWARE.
#define XI_FOOTMOUSE "FOOTMOUSE"
#define XI_JOYSTICK "JOYSTICK"
+/* Indices into the versions[] array (XExtInt.c). Used as a index to
+ * retrieve the minimum version of XI from _XiCheckExtInit */
#define Dont_Check 0
#define XInput_Initial_Release 1
#define XInput_Add_XDeviceBell 2
@@ -142,6 +144,7 @@ SOFTWARE.
#define XInput_Add_XChangeDeviceControl 4
#define XInput_Add_DevicePresenceNotify 5
#define XInput_Add_DeviceProperties 6
+/* DO NOT ADD TO HERE -> XI2 */
#define XI_Absent 0
#define XI_Present 1
@@ -236,6 +239,7 @@ SOFTWARE.
#define ProximityClass 4
#define FocusClass 5
#define OtherClass 6
+#define AttachClass 7
#define KbdFeedbackClass 0
#define PtrFeedbackClass 1
@@ -257,6 +261,10 @@ SOFTWARE.
#define _devicePresence 0
+#define _deviceEnter 0
+#define _deviceLeave 1
+
+/* Device presence notify states */
#define DeviceAdded 0
#define DeviceRemoved 1
#define DeviceEnabled 2
@@ -264,6 +272,7 @@ SOFTWARE.
#define DeviceUnrecoverable 4
#define DeviceControlChanged 5
+/* XI Errors */
#define XI_BadDevice 0
#define XI_BadEvent 1
#define XI_BadMode 2
@@ -279,7 +288,7 @@ SOFTWARE.
* without polluting the namespace.
*/
#ifdef _XSERVER64
-typedef unsigned int XEventClass;
+typedef unsigned int XEventClass;
#else
typedef unsigned long XEventClass;
#endif
diff --git a/proto/inputproto/XI2.h b/proto/inputproto/XI2.h
new file mode 100644
index 000000000..6ba1377aa
--- /dev/null
+++ b/proto/inputproto/XI2.h
@@ -0,0 +1,181 @@
+/*
+ * Copyright © 2009 Red Hat, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#ifndef _XI2_H_
+#define _XI2_H_
+
+/* Indices into the versions[] array (XExtInt.c). Used as a index to
+ * retrieve the minimum version of XI from _XiCheckExtInit.
+ * For indices 0 to 6 see XI.h */
+#ifndef Dont_Check /* defined in XI.h */
+#define Dont_Check 0
+#endif
+#define XInput_2_0 7
+
+
+#define XI_2_Major 2
+#define XI_2_Minor 0
+
+/* Property event flags */
+#define XIPropertyDeleted 0
+#define XIPropertyCreated 1
+#define XIPropertyModified 2
+
+/* Enter/Leave and Focus In/Out modes */
+#define XINotifyNormal 0
+#define XINotifyGrab 1
+#define XINotifyUngrab 2
+#define XINotifyWhileGrabbed 3
+#define XINotifyPassiveGrab 4
+#define XINotifyPassiveUngrab 5
+
+/* Enter/Leave and focus In/out detail */
+#define XINotifyAncestor 0
+#define XINotifyVirtual 1
+#define XINotifyInferior 2
+#define XINotifyNonlinear 3
+#define XINotifyNonlinearVirtual 4
+#define XINotifyPointer 5
+#define XINotifyPointerRoot 6
+#define XINotifyDetailNone 7
+
+/* Passive grab types */
+#define XIGrabtypeButton 0
+#define XIGrabtypeKeycode 1
+#define XIGrabtypeEnter 2
+#define XIGrabtypeFocusIn 3
+
+/* Passive grab modifier */
+#define XIAnyModifier (1U << 31)
+#define XIAnyButton 0
+#define XIAnyKeycode 0
+
+/* XIAllowEvents event-modes */
+#define XIAsyncDevice 0
+#define XISyncDevice 1
+#define XIReplayDevice 2
+#define XIAsyncPairedDevice 3
+#define XIAsyncPair 4
+#define XISyncPair 5
+
+/* DeviceChangedEvent change reasons */
+#define XISlaveSwitch 1
+#define XIDeviceChange 2
+
+/* Hierarchy flags */
+#define XIMasterAdded (1 << 0)
+#define XIMasterRemoved (1 << 1)
+#define XISlaveAdded (1 << 2)
+#define XISlaveRemoved (1 << 3)
+#define XISlaveAttached (1 << 4)
+#define XISlaveDetached (1 << 5)
+#define XIDeviceEnabled (1 << 6)
+#define XIDeviceDisabled (1 << 7)
+
+/* ChangeHierarchy constants */
+#define XIAddMaster 1
+#define XIRemoveMaster 2
+#define XIAttachSlave 3
+#define XIDetachSlave 4
+
+#define XIAttachToMaster 1
+#define XIFloating 2
+
+/* Valuator modes */
+#define XIModeRelative 0
+#define XIModeAbsolute 1
+
+/* Device types */
+#define XIMasterPointer 1
+#define XIMasterKeyboard 2
+#define XISlavePointer 3
+#define XISlaveKeyboard 4
+#define XIFloatingSlave 5
+
+/* Device classes */
+#define XIKeyClass 0
+#define XIButtonClass 1
+#define XIValuatorClass 2
+
+/* Device event flags (common) */
+/* Device event flags (key events only) */
+#define XIKeyRepeat (1 << 16)
+/* Device event flags (pointer events only) */
+
+/* XI2 event mask macros */
+#define XISetMask(ptr, event) (((unsigned char*)(ptr))[(event)>>3] |= (1 << ((event) & 7)))
+#define XIClearMask(ptr, event) (((unsigned char*)(ptr))[(event)>>3] &= ~(1 << ((event) & 7)))
+#define XIMaskIsSet(ptr, event) (((unsigned char*)(ptr))[(event)>>3] & (1 << ((event) & 7)))
+#define XIMaskLen(event) (((event + 7) >> 3))
+
+/* Fake device ID's for event selection */
+#define XIAllDevices 0
+#define XIAllMasterDevices 1
+
+/* Event types */
+#define XI_DeviceChanged 1
+#define XI_KeyPress 2
+#define XI_KeyRelease 3
+#define XI_ButtonPress 4
+#define XI_ButtonRelease 5
+#define XI_Motion 6
+#define XI_Enter 7
+#define XI_Leave 8
+#define XI_FocusIn 9
+#define XI_FocusOut 10
+#define XI_HierarchyChanged 11
+#define XI_PropertyEvent 12
+#define XI_RawKeyPress 13
+#define XI_RawKeyRelease 14
+#define XI_RawButtonPress 15
+#define XI_RawButtonRelease 16
+#define XI_RawMotion 17
+#define XI_LASTEVENT XI_RawMotion
+/* NOTE: XI2LASTEVENT in xserver/include/inputstr.h must be the same value
+ * as XI_LASTEVENT if the server is supposed to handle masks etc. for this
+ * type of event. */
+
+/* Event masks.
+ * Note: the protocol spec defines a mask to be of (1 << type). Clients are
+ * free to create masks by bitshifting instead of using these defines.
+ */
+#define XI_DeviceChangedMask (1 << XI_DeviceChanged)
+#define XI_KeyPressMask (1 << XI_KeyPress)
+#define XI_KeyReleaseMask (1 << XI_KeyRelease)
+#define XI_ButtonPressMask (1 << XI_ButtonPress)
+#define XI_ButtonReleaseMask (1 << XI_ButtonRelease)
+#define XI_MotionMask (1 << XI_Motion)
+#define XI_EnterMask (1 << XI_Enter)
+#define XI_LeaveMask (1 << XI_Leave)
+#define XI_FocusInMask (1 << XI_FocusIn)
+#define XI_FocusOutMask (1 << XI_FocusOut)
+#define XI_HierarchyChangedMask (1 << XI_HierarchyChanged)
+#define XI_PropertyEventMask (1 << XI_PropertyEvent)
+#define XI_RawKeyPressMask (1 << XI_RawKeyPress)
+#define XI_RawKeyReleaseMask (1 << XI_RawKeyRelease)
+#define XI_RawButtonPressMask (1 << XI_RawButtonPress)
+#define XI_RawButtonReleaseMask (1 << XI_RawButtonRelease)
+#define XI_RawMotionMask (1 << XI_RawMotion)
+
+#endif /* _XI2_H_ */
diff --git a/proto/inputproto/XI2proto.h b/proto/inputproto/XI2proto.h
new file mode 100644
index 000000000..2fd91ebf1
--- /dev/null
+++ b/proto/inputproto/XI2proto.h
@@ -0,0 +1,976 @@
+/*
+ * Copyright © 2009 Red Hat, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+/* Conventions for this file:
+ * Names:
+ * structs: always typedef'd, prefixed with xXI, CamelCase
+ * struct members: lower_case_with_underscores
+ * Exceptions: reqType, ReqType, repType, RepType, sequenceNumber are
+ * named as such for historical reasons.
+ * request opcodes: X_XIRequestName as CamelCase
+ * defines: defines used in client applications must go in XI2.h
+ * defines used only in protocol handling: XISOMENAME
+ *
+ * Data types: unless there is a historical name for a datatype (e.g.
+ * Window), use stdint types specifying the size of the datatype.
+ * historical data type names must be defined and undefined at the top and
+ * end of the file.
+ *
+ * General:
+ * spaces, not tabs.
+ * structs specific to a request or reply added before the request
+ * definition. structs used in more than one request, reply or event
+ * appended to the common structs section before the definition of the
+ * first request.
+ * members of structs vertically aligned on column 16 if datatypes permit.
+ * otherwise alingned on next available 8n column.
+ */
+
+/**
+ * Protocol definitions for the XI2 protocol.
+ * This file should not be included by clients that merely use XI2, but do not
+ * need the wire protocol. Such clients should include XI2.h, or the matching
+ * header from the library.
+ *
+ */
+#ifndef _XI2PROTO_H_
+#define _XI2PROTO_H_
+
+#include <X11/Xproto.h>
+#include <X11/X.h>
+#include <X11/extensions/XI2.h>
+
+/* make sure types have right sizes for protocol structures. */
+#define Window uint32_t
+#define Time uint32_t
+#define Atom uint32_t
+#define Cursor uint32_t
+
+/**
+ * XI2 Request opcodes
+ */
+#define X_XIQueryPointer 40
+#define X_XIWarpPointer 41
+#define X_XIChangeCursor 42
+#define X_XIChangeHierarchy 43
+#define X_XISetClientPointer 44
+#define X_XIGetClientPointer 45
+#define X_XISelectEvents 46
+#define X_XIQueryVersion 47
+#define X_XIQueryDevice 48
+#define X_XISetFocus 49
+#define X_XIGetFocus 50
+#define X_XIGrabDevice 51
+#define X_XIUngrabDevice 52
+#define X_XIAllowEvents 53
+#define X_XIPassiveGrabDevice 54
+#define X_XIPassiveUngrabDevice 55
+#define X_XIListProperties 56
+#define X_XIChangeProperty 57
+#define X_XIDeleteProperty 58
+#define X_XIGetProperty 59
+#define X_XIGetSelectedEvents 60
+
+/** Number of XI requests */
+#define XI2REQUESTS (X_XIGetSelectedEvents - X_XIQueryPointer + 1)
+/** Number of XI2 events */
+#define XI2EVENTS (XI_LASTEVENT + 1)
+
+/*************************************************************************************
+ * *
+ * COMMON STRUCTS *
+ * *
+ *************************************************************************************/
+/** Fixed point 16.16 */
+typedef int32_t FP1616;
+
+/** Fixed point 32.32 */
+typedef struct {
+ int32_t integral;
+ uint32_t frac;
+} FP3232;
+
+/**
+ * Struct to describe a device.
+ *
+ * For a MasterPointer or a MasterKeyboard, 'attachment' specifies the
+ * paired master device.
+ * For a SlaveKeyboard or SlavePointer, 'attachment' specifies the master
+ * device this device is attached to.
+ * For a FloatingSlave, 'attachment' is undefined.
+ */
+typedef struct {
+ uint16_t deviceid;
+ uint16_t use; /**< ::XIMasterPointer, ::XIMasterKeyboard,
+ ::XISlavePointer, ::XISlaveKeyboard,
+ ::XIFloatingSlave */
+ uint16_t attachment; /**< Current attachment or pairing.*/
+ uint16_t num_classes; /**< Number of classes following this struct. */
+ uint16_t name_len; /**< Length of name in bytes. */
+ uint8_t enabled; /**< TRUE if device is enabled. */
+ uint8_t pad;
+} xXIDeviceInfo;
+
+/**
+ * Default template for a device class.
+ * A device class is equivalent to a device's capabilities. Multiple classes
+ * are supported per device.
+ */
+typedef struct {
+ uint16_t type; /**< One of *class */
+ uint16_t length; /**< Length in 4 byte units */
+ uint16_t sourceid; /**< source device for this class */
+ uint16_t pad;
+} xXIAnyInfo;
+
+/**
+ * Denotes button capability on a device.
+ * Struct is followed by num_buttons * Atom that names the buttons in the
+ * device-native setup (i.e. ignoring button mappings).
+ */
+typedef struct {
+ uint16_t type; /**< Always ButtonClass */
+ uint16_t length; /**< Length in 4 byte units */
+ uint16_t sourceid; /**< source device for this class */
+ uint16_t num_buttons; /**< Number of buttons provide */
+} xXIButtonInfo;
+
+/**
+ * Denotes key capability on a device.
+ * Struct is followed by num_keys * CARD32 that lists the keycodes available
+ * on the device.
+ */
+typedef struct {
+ uint16_t type; /**< Always KeyClass */
+ uint16_t length; /**< Length in 4 byte units */
+ uint16_t sourceid; /**< source device for this class */
+ uint16_t num_keycodes; /**< Number of keys provided */
+} xXIKeyInfo;
+
+/**
+ * Denotes an valuator capability on a device.
+ * One XIValuatorInfo describes exactly one valuator (axis) on the device.
+ */
+typedef struct {
+ uint16_t type; /**< Always ValuatorClass */
+ uint16_t length; /**< Length in 4 byte units */
+ uint16_t sourceid; /**< source device for this class */
+ uint16_t number; /**< Valuator number */
+ Atom label; /**< Axis label */
+ FP3232 min; /**< Min value */
+ FP3232 max; /**< Max value */
+ FP3232 value; /**< Last published value */
+ uint32_t resolution; /**< Resolutions in units/m */
+ uint8_t mode; /**< ModeRelative or ModeAbsolute */
+ uint8_t pad1;
+ uint16_t pad2;
+} xXIValuatorInfo;
+
+
+/**
+ * Used to select for events on a given window.
+ * Struct is followed by (mask_len * CARD8), with each bit set representing
+ * the event mask for the given type. A mask bit represents an event type if
+ * (mask == (1 << type)).
+ */
+typedef struct {
+ uint16_t deviceid; /**< Device id to select for */
+ uint16_t mask_len; /**< Length of mask in 4 byte units */
+} xXIEventMask;
+
+/**
+ * XKB modifier information.
+ * The effective modifier is a binary mask of base, latched, and locked
+ * modifiers.
+ */
+typedef struct
+{
+ uint32_t base_mods; /**< Logically pressed modifiers */
+ uint32_t latched_mods; /**< Logically latched modifiers */
+ uint32_t locked_mods; /**< Logically locked modifiers */
+ uint32_t effective_mods; /**< Effective modifiers */
+} xXIModifierInfo;
+
+/**
+ * XKB group information.
+ * The effective group is the mathematical sum of base, latched, and locked
+ * group after group wrapping is taken into account.
+ */
+typedef struct
+{
+ uint8_t base_group; /**< Logically "pressed" group */
+ uint8_t latched_group; /**< Logically latched group */
+ uint8_t locked_group; /**< Logically locked group */
+ uint8_t effective_group; /**< Effective group */
+} xXIGroupInfo;
+
+
+/*************************************************************************************
+ * *
+ * REQUESTS *
+ * *
+ *************************************************************************************/
+
+/**
+ * Query the server for the supported X Input extension version.
+ */
+
+typedef struct {
+ uint8_t reqType; /**< Input extension major code */
+ uint8_t ReqType; /**< Always ::X_XIQueryVersion */
+ uint16_t length; /**< Length in 4 byte units */
+ uint16_t major_version;
+ uint16_t minor_version;
+} xXIQueryVersionReq;
+#define sz_xXIQueryVersionReq 8
+
+typedef struct {
+ uint8_t repType; /**< ::X_Reply */
+ uint8_t RepType; /**< Always ::X_XIQueryVersion */
+ uint16_t sequenceNumber;
+ uint32_t length;
+ uint16_t major_version;
+ uint16_t minor_version;
+ uint32_t pad1;
+ uint32_t pad2;
+ uint32_t pad3;
+ uint32_t pad4;
+ uint32_t pad5;
+} xXIQueryVersionReply;
+#define sz_xXIQueryVersionReply 32
+
+/**
+ * Query the server for information about a specific device or all input
+ * devices.
+ */
+typedef struct {
+ uint8_t reqType; /**< Input extension major code */
+ uint8_t ReqType; /**< Always ::X_XIQueryDevice */
+ uint16_t length; /**< Length in 4 byte units */
+ uint16_t deviceid;
+ uint16_t pad;
+} xXIQueryDeviceReq;
+#define sz_xXIQueryDeviceReq 8
+
+typedef struct {
+ uint8_t repType; /**< ::X_Reply */
+ uint8_t RepType; /**< Always ::X_XIQueryDevice */
+ uint16_t sequenceNumber;
+ uint32_t length;
+ uint16_t num_devices;
+ uint16_t pad0;
+ uint32_t pad1;
+ uint32_t pad2;
+ uint32_t pad3;
+ uint32_t pad4;
+ uint32_t pad5;
+} xXIQueryDeviceReply;
+#define sz_xXIQueryDeviceReply 32
+
+/**
+ * Select for events on a given window.
+ */
+typedef struct {
+ uint8_t reqType; /**< Input extension major code */
+ uint8_t ReqType; /**< Always ::X_XISelectEvents */
+ uint16_t length; /**< Length in 4 byte units */
+ Window win;
+ uint16_t num_masks;
+ uint16_t pad;
+} xXISelectEventsReq;
+#define sz_xXISelectEventsReq 12
+
+/**
+ * Query for selected events on a given window.
+ */
+typedef struct {
+ uint8_t reqType; /**< Input extension major code */
+ uint8_t ReqType; /**< Always ::X_XIGetSelectedEvents */
+ uint16_t length; /**< Length in 4 byte units */
+ Window win;
+} xXIGetSelectedEventsReq;
+#define sz_xXIGetSelectedEventsReq 8
+
+typedef struct {
+ uint8_t repType; /**< Input extension major opcode */
+ uint8_t RepType; /**< Always ::X_XIGetSelectedEvents */
+ uint16_t sequenceNumber;
+ uint32_t length;
+ uint16_t num_masks; /**< Number of xXIEventMask structs
+ trailing the reply */
+ uint16_t pad0;
+ uint32_t pad1;
+ uint32_t pad2;
+ uint32_t pad3;
+ uint32_t pad4;
+ uint32_t pad5;
+} xXIGetSelectedEventsReply;
+#define sz_xXIGetSelectedEventsReply 32
+
+/**
+ * Query the given device's screen/window coordinates.
+ */
+
+typedef struct {
+ uint8_t reqType; /**< Input extension major code */
+ uint8_t ReqType; /**< Always ::X_XIQueryPointer */
+ uint16_t length; /**< Length in 4 byte units */
+ Window win;
+ uint16_t deviceid;
+ uint16_t pad1;
+} xXIQueryPointerReq;
+#define sz_xXIQueryPointerReq 12
+
+
+typedef struct {
+ uint8_t repType; /**< Input extension major opcode */
+ uint8_t RepType; /**< Always ::X_XIQueryPointer */
+ uint16_t sequenceNumber;
+ uint32_t length;
+ Window root;
+ Window child;
+ FP1616 root_x;
+ FP1616 root_y;
+ FP1616 win_x;
+ FP1616 win_y;
+ uint8_t same_screen;
+ uint8_t pad0;
+ uint16_t buttons_len;
+ xXIModifierInfo mods;
+ xXIGroupInfo group;
+} xXIQueryPointerReply;
+#define sz_xXIQueryPointerReply 56
+
+/**
+ * Warp the given device's pointer to the specified position.
+ */
+
+typedef struct {
+ uint8_t reqType; /**< Input extension major code */
+ uint8_t ReqType; /**< Always ::X_XIWarpPointer */
+ uint16_t length; /**< Length in 4 byte units */
+ Window src_win;
+ Window dst_win;
+ FP1616 src_x;
+ FP1616 src_y;
+ uint16_t src_width;
+ uint16_t src_height;
+ FP1616 dst_x;
+ FP1616 dst_y;
+ uint16_t deviceid;
+ uint16_t pad1;
+} xXIWarpPointerReq;
+#define sz_xXIWarpPointerReq 36
+
+/**
+ * Change the given device's sprite to the given cursor.
+ */
+
+typedef struct {
+ uint8_t reqType; /**< Input extension major code */
+ uint8_t ReqType; /**< Always ::X_XIChangeCursor */
+ uint16_t length; /**< Length in 4 byte units */
+ Window win;
+ Cursor cursor;
+ uint16_t deviceid;
+ uint16_t pad1;
+} xXIChangeCursorReq;
+#define sz_xXIChangeCursorReq 16
+
+/**
+ * Modify the device hierarchy.
+ */
+
+typedef struct {
+ uint8_t reqType; /**< Input extension major code */
+ uint8_t ReqType; /**< Always ::X_XIChangeHierarchy */
+ uint16_t length; /**< Length in 4 byte units */
+ uint8_t num_changes;
+ uint8_t pad0;
+ uint16_t pad1;
+} xXIChangeHierarchyReq;
+#define sz_xXIChangeHierarchyReq 8
+
+/**
+ * Generic header for any hierarchy change.
+ */
+typedef struct {
+ uint16_t type;
+ uint16_t length; /**< Length in 4 byte units */
+} xXIAnyHierarchyChangeInfo;
+
+/**
+ * Create a new master device.
+ * Name of new master follows struct (4-byte padded)
+ */
+typedef struct {
+ uint16_t type; /**< Always ::XIAddMaster */
+ uint16_t length; /**< 2 + (namelen + padding)/4 */
+ uint16_t name_len;
+ uint8_t send_core;
+ uint8_t enable;
+} xXIAddMasterInfo;
+
+/**
+ * Delete a master device. Will automatically delete the master device paired
+ * with the given master device.
+ */
+typedef struct {
+ uint16_t type; /**< Always ::XIRemoveMaster */
+ uint16_t length; /**< 3 */
+ uint16_t deviceid;
+ uint8_t return_mode; /**< ::XIAttachToMaster, ::XIFloating */
+ uint8_t pad;
+ uint16_t return_pointer; /**< Pointer to attach slave ptr devices to */
+ uint16_t return_keyboard; /**< keyboard to attach slave keybd devices to*/
+} xXIRemoveMasterInfo;
+
+/**
+ * Attach an SD to a new device.
+ * NewMaster has to be of same type (pointer->pointer, keyboard->keyboard);
+ */
+typedef struct {
+ uint16_t type; /**< Always ::XIAttachSlave */
+ uint16_t length; /**< 2 */
+ uint16_t deviceid;
+ uint16_t new_master; /**< id of new master device */
+} xXIAttachSlaveInfo;
+
+/**
+ * Detach an SD from its current master device.
+ */
+typedef struct {
+ uint16_t type; /**< Always ::XIDetachSlave */
+ uint16_t length; /**< 2 */
+ uint16_t deviceid;
+ uint16_t pad;
+} xXIDetachSlaveInfo;
+
+
+/**
+ * Set the window/client's ClientPointer.
+ */
+typedef struct {
+ uint8_t reqType;
+ uint8_t ReqType; /**< Always ::X_XISetClientPointer */
+ uint16_t length; /**< Length in 4 byte units */
+ Window win;
+ uint16_t deviceid;
+ uint16_t pad1;
+} xXISetClientPointerReq;
+#define sz_xXISetClientPointerReq 12
+
+/**
+ * Query the given window/client's ClientPointer setting.
+ */
+typedef struct {
+ uint8_t reqType;
+ uint8_t ReqType; /**< Always ::X_GetClientPointer */
+ uint16_t length; /**< Length in 4 byte units */
+ Window win;
+} xXIGetClientPointerReq;
+#define sz_xXIGetClientPointerReq 8
+
+typedef struct {
+ uint8_t repType; /**< Input extension major opcode */
+ uint8_t RepType; /**< Always ::X_GetClientPointer */
+ uint16_t sequenceNumber;
+ uint32_t length;
+ BOOL set; /**< client pointer is set? */
+ uint8_t pad0;
+ uint16_t deviceid;
+ uint32_t pad1;
+ uint32_t pad2;
+ uint32_t pad3;
+ uint32_t pad4;
+ uint32_t pad5;
+} xXIGetClientPointerReply;
+#define sz_xXIGetClientPointerReply 32
+
+/**
+ * Set the input focus to the specified window.
+ */
+typedef struct {
+ uint8_t reqType;
+ uint8_t ReqType; /**< Always ::X_XISetFocus */
+ uint16_t length; /**< Length in 4 byte units */
+ Window focus;
+ Time time;
+ uint16_t deviceid;
+ uint16_t pad0;
+} xXISetFocusReq;
+#define sz_xXISetFocusReq 16
+
+/**
+ * Query the current input focus.
+ */
+typedef struct {
+ uint8_t reqType;
+ uint8_t ReqType; /**< Always ::X_XIGetDeviceFocus */
+ uint16_t length; /**< Length in 4 byte units */
+ uint16_t deviceid;
+ uint16_t pad0;
+} xXIGetFocusReq;
+#define sz_xXIGetFocusReq 8
+
+typedef struct {
+ uint8_t repType; /**< Input extension major opcode */
+ uint8_t RepType; /**< Always ::X_XIGetFocus */
+ uint16_t sequenceNumber;
+ uint32_t length;
+ Window focus;
+ uint32_t pad1;
+ uint32_t pad2;
+ uint32_t pad3;
+ uint32_t pad4;
+ uint32_t pad5;
+} xXIGetFocusReply;
+#define sz_xXIGetFocusReply 32
+
+
+/**
+ * Grab the given device.
+ */
+typedef struct {
+ uint8_t reqType;
+ uint8_t ReqType; /**< Always ::X_XIGrabDevice */
+ uint16_t length; /**< Length in 4 byte units */
+ Window grab_window;
+ Time time;
+ Cursor cursor;
+ uint16_t deviceid;
+ uint8_t grab_mode;
+ uint8_t paired_device_mode;
+ uint8_t owner_events;
+ uint8_t pad;
+ uint16_t mask_len;
+} xXIGrabDeviceReq;
+#define sz_xXIGrabDeviceReq 24
+
+/**
+ * Return codes from a XIPassiveGrabDevice request.
+ */
+typedef struct {
+ uint32_t modifiers; /**< Modifier state */
+ uint8_t status; /**< Grab status code */
+ uint8_t pad0;
+ uint16_t pad1;
+} xXIGrabModifierInfo;
+
+typedef struct {
+ uint8_t repType; /**< Input extension major opcode */
+ uint8_t RepType; /**< Always ::X_XIGrabDevice */
+ uint16_t sequenceNumber;
+ uint32_t length;
+ uint8_t status;
+ uint8_t pad0;
+ uint16_t pad1;
+ uint32_t pad2;
+ uint32_t pad3;
+ uint32_t pad4;
+ uint32_t pad5;
+ uint32_t pad6;
+} xXIGrabDeviceReply;
+#define sz_xXIGrabDeviceReply 32
+
+/**
+ * Ungrab the specified device.
+ *
+ */
+typedef struct {
+ uint8_t reqType;
+ uint8_t ReqType; /**< Always ::X_XIUngrabDevice */
+ uint16_t length; /**< Length in 4 byte units */
+ Time time;
+ uint16_t deviceid;
+ uint16_t pad;
+} xXIUngrabDeviceReq;
+#define sz_xXIUngrabDeviceReq 12
+
+
+/**
+ * Allow or replay events on the specified grabbed device.
+ */
+typedef struct {
+ uint8_t reqType;
+ uint8_t ReqType; /**< Always ::X_XIAllowEvents */
+ uint16_t length; /**< Length in 4 byte units */
+ Time time;
+ uint16_t deviceid;
+ uint8_t mode;
+ uint8_t pad;
+} xXIAllowEventsReq;
+#define sz_xXIAllowEventsReq 12
+
+
+/**
+ * Passively grab the device.
+ */
+typedef struct {
+ uint8_t reqType;
+ uint8_t ReqType; /**< Always ::X_XIPassiveGrabDevice */
+ uint16_t length; /**< Length in 4 byte units */
+ Time time;
+ Window grab_window;
+ Cursor cursor;
+ uint32_t detail;
+ uint16_t deviceid;
+ uint16_t num_modifiers;
+ uint16_t mask_len;
+ uint8_t grab_type;
+ uint8_t grab_mode;
+ uint8_t paired_device_mode;
+ uint8_t owner_events;
+ uint16_t pad1;
+} xXIPassiveGrabDeviceReq;
+#define sz_xXIPassiveGrabDeviceReq 32
+
+typedef struct {
+ uint8_t repType; /**< Input extension major opcode */
+ uint8_t RepType; /**< Always ::X_XIPassiveGrabDevice */
+ uint16_t sequenceNumber;
+ uint32_t length;
+ uint16_t num_modifiers;
+ uint16_t pad1;
+ uint32_t pad2;
+ uint32_t pad3;
+ uint32_t pad4;
+ uint32_t pad5;
+ uint32_t pad6;
+} xXIPassiveGrabDeviceReply;
+#define sz_xXIPassiveGrabDeviceReply 32
+
+/**
+ * Delete a passive grab for the given device.
+ */
+typedef struct {
+ uint8_t reqType;
+ uint8_t ReqType; /**< Always ::X_XIPassiveUngrabDevice */
+ uint16_t length; /**< Length in 4 byte units */
+ Window grab_window;
+ uint32_t detail;
+ uint16_t deviceid;
+ uint16_t num_modifiers;
+ uint8_t grab_type;
+ uint8_t pad0;
+ uint16_t pad1;
+} xXIPassiveUngrabDeviceReq;
+#define sz_xXIPassiveUngrabDeviceReq 20
+
+/**
+ * List all device properties on the specified device.
+ */
+typedef struct {
+ uint8_t reqType;
+ uint8_t ReqType; /**< Always ::X_XIListProperties */
+ uint16_t length; /**< Length in 4 byte units */
+ uint16_t deviceid;
+ uint16_t pad;
+} xXIListPropertiesReq;
+#define sz_xXIListPropertiesReq 8
+
+typedef struct {
+ uint8_t repType; /**< Input extension major opcode */
+ uint8_t RepType; /**< Always ::X_XIListProperties */
+ uint16_t sequenceNumber;
+ uint32_t length;
+ uint16_t num_properties;
+ uint16_t pad0;
+ uint32_t pad1;
+ uint32_t pad2;
+ uint32_t pad3;
+ uint32_t pad4;
+ uint32_t pad5;
+} xXIListPropertiesReply;
+#define sz_xXIListPropertiesReply 32
+
+/**
+ * Change a property on the specified device.
+ */
+typedef struct {
+ uint8_t reqType;
+ uint8_t ReqType; /**< Always ::X_XIChangeProperty */
+ uint16_t length; /**< Length in 4 byte units */
+ uint16_t deviceid;
+ uint8_t mode;
+ uint8_t format;
+ Atom property;
+ Atom type;
+ uint32_t num_items;
+} xXIChangePropertyReq;
+#define sz_xXIChangePropertyReq 20
+
+/**
+ * Delete the specified property.
+ */
+typedef struct {
+ uint8_t reqType;
+ uint8_t ReqType; /**< Always X_XIDeleteProperty */
+ uint16_t length; /**< Length in 4 byte units */
+ uint16_t deviceid;
+ uint16_t pad0;
+ Atom property;
+} xXIDeletePropertyReq;
+#define sz_xXIDeletePropertyReq 12
+
+/**
+ * Query the specified property's values.
+ */
+typedef struct {
+ uint8_t reqType;
+ uint8_t ReqType; /**< Always X_XIGetProperty */
+ uint16_t length; /**< Length in 4 byte units */
+ uint16_t deviceid;
+#if defined(__cplusplus) || defined(c_plusplus)
+ uint8_t c_delete;
+#else
+ uint8_t delete;
+#endif
+ uint8_t pad0;
+ Atom property;
+ Atom type;
+ uint32_t offset;
+ uint32_t len;
+} xXIGetPropertyReq;
+#define sz_xXIGetPropertyReq 24
+
+typedef struct {
+ uint8_t repType; /**< Input extension major opcode */
+ uint8_t RepType; /**< Always X_XIGetProperty */
+ uint16_t sequenceNumber;
+ uint32_t length;
+ Atom type;
+ uint32_t bytes_after;
+ uint32_t num_items;
+ uint8_t format;
+ uint8_t pad0;
+ uint16_t pad1;
+ uint32_t pad2;
+ uint32_t pad3;
+} xXIGetPropertyReply;
+#define sz_xXIGetPropertyReply 32
+
+/*************************************************************************************
+ * *
+ * EVENTS *
+ * *
+ *************************************************************************************/
+
+/**
+ * Generic XI2 event header. All XI2 events use the same header.
+ */
+typedef struct
+{
+ uint8_t type;
+ uint8_t extension; /**< XI extension offset */
+ uint16_t sequenceNumber;
+ uint32_t length;
+ uint16_t evtype;
+ uint16_t deviceid;
+ Time time;
+} xXIGenericDeviceEvent;
+
+/**
+ * Device hierarchy information.
+ */
+typedef struct
+{
+ uint16_t deviceid;
+ uint16_t attachment; /**< ID of master or paired device */
+ uint8_t use; /**< ::XIMasterKeyboard,
+ ::XIMasterPointer,
+ ::XISlaveKeyboard,
+ ::XISlavePointer,
+ ::XIFloatingSlave */
+ BOOL enabled; /**< TRUE if the device is enabled */
+ uint16_t pad;
+ uint32_t flags; /**< ::XIMasterAdded, ::XIMasterRemoved,
+ ::XISlaveAttached, ::XISlaveDetached,
+ ::XISlaveAdded, ::XISlaveRemoved,
+ ::XIDeviceEnabled, ::XIDeviceDisabled */
+} xXIHierarchyInfo;
+
+/**
+ * The device hierarchy has been modified. This event includes the device
+ * hierarchy after the modification has been applied.
+ */
+typedef struct
+{
+ uint8_t type; /**< Always GenericEvent */
+ uint8_t extension; /**< XI extension offset */
+ uint16_t sequenceNumber;
+ uint32_t length; /**< Length in 4 byte units */
+ uint16_t evtype; /**< ::XI_Hierarchy */
+ uint16_t deviceid;
+ Time time;
+ uint32_t flags; /**< ::XIMasterAdded, ::XIMasterDeleted,
+ ::XISlaveAttached, ::XISlaveDetached,
+ ::XISlaveAdded, ::XISlaveRemoved,
+ ::XIDeviceEnabled, ::XIDeviceDisabled */
+ uint16_t num_info;
+ uint16_t pad0;
+ uint32_t pad1;
+ uint32_t pad2;
+} xXIHierarchyEvent;
+
+/**
+ * A device has changed capabilities.
+ */
+typedef struct
+{
+ uint8_t type; /**< Always GenericEvent */
+ uint8_t extension; /**< XI extension offset */
+ uint16_t sequenceNumber;
+ uint32_t length; /**< Length in 4 byte units */
+ uint16_t evtype; /**< XI_DeviceChanged */
+ uint16_t deviceid; /**< Device that has changed */
+ Time time;
+ uint16_t num_classes; /**< Number of classes that have changed */
+ uint16_t sourceid; /**< Source of the new classes */
+ uint8_t reason; /**< ::XISlaveSwitch, ::XIDeviceChange */
+ uint8_t pad0;
+ uint16_t pad1;
+ uint32_t pad2;
+ uint32_t pad3;
+} xXIDeviceChangedEvent;
+
+/**
+ * Default input event for pointer or keyboard input.
+ */
+typedef struct
+{
+ uint8_t type; /**< Always GenericEvent */
+ uint8_t extension; /**< XI extension offset */
+ uint16_t sequenceNumber;
+ uint32_t length; /**< Length in 4 byte uints */
+ uint16_t evtype;
+ uint16_t deviceid;
+ Time time;
+ uint32_t detail; /**< Keycode or button */
+ Window root;
+ Window event;
+ Window child;
+/* └──────── 32 byte boundary ────────┘ */
+ FP1616 root_x; /**< Always screen coords, 16.16 fixed point */
+ FP1616 root_y;
+ FP1616 event_x; /**< Always screen coords, 16.16 fixed point */
+ FP1616 event_y;
+ uint16_t buttons_len; /**< Len of button flags in 4 b units */
+ uint16_t valuators_len; /**< Len of val. flags in 4 b units */
+ uint16_t sourceid; /**< The source device */
+ uint16_t pad0;
+ uint32_t flags; /**< ::XIKeyRepeat */
+ xXIModifierInfo mods;
+ xXIGroupInfo group;
+} xXIDeviceEvent;
+
+
+/**
+ * Sent when an input event is generated. RawEvents include valuator
+ * information in both device-specific data (i.e. unaccelerated) and
+ * processed data (i.e. accelerated, if applicable).
+ */
+typedef struct
+{
+ uint8_t type; /**< Always GenericEvent */
+ uint8_t extension; /**< XI extension offset */
+ uint16_t sequenceNumber;
+ uint32_t length; /**< Length in 4 byte uints */
+ uint16_t evtype; /**< ::XI_RawEvent */
+ uint16_t deviceid;
+ Time time;
+ uint32_t detail;
+ uint16_t pad0;
+ uint16_t valuators_len; /**< Length of trailing valuator
+ mask in 4 byte units */
+ uint32_t flags; /**< ::XIKeyRepeat */
+ uint32_t pad2;
+} xXIRawEvent;
+
+/**
+ * Note that the layout of root, event, child, root_x, root_y, event_x,
+ * event_y must be identical to the xXIDeviceEvent.
+ */
+typedef struct
+{
+ uint8_t type; /**< Always GenericEvent */
+ uint8_t extension; /**< XI extension offset */
+ uint16_t sequenceNumber;
+ uint32_t length; /**< Length in 4 byte uints */
+ uint16_t evtype; /**< ::XI_Enter */
+ uint16_t deviceid;
+ Time time;
+ uint16_t sourceid;
+ uint8_t mode;
+ uint8_t detail;
+ Window root;
+ Window event;
+ Window child;
+/* └──────── 32 byte boundary ────────┘ */
+ FP1616 root_x;
+ FP1616 root_y;
+ FP1616 event_x;
+ FP1616 event_y;
+ BOOL same_screen;
+ BOOL focus;
+ uint16_t buttons_len; /**< Length of trailing button mask
+ in 4 byte units */
+ xXIModifierInfo mods;
+ xXIGroupInfo group;
+} xXIEnterEvent;
+
+typedef xXIEnterEvent xXILeaveEvent;
+typedef xXIEnterEvent xXIFocusInEvent;
+typedef xXIEnterEvent xXIFocusOutEvent;
+
+/**
+ * Sent when a device property is created, modified or deleted. Does not
+ * include property data, the client is required to query the data.
+ */
+typedef struct
+{
+ uint8_t type; /**< Always GenericEvent */
+ uint8_t extension; /**< XI extension offset */
+ uint16_t sequenceNumber;
+ uint32_t length; /**< Length in 4 byte uints */
+ uint16_t evtype; /**< ::XI_PropertyEvent */
+ uint16_t deviceid;
+ Time time;
+ Atom property;
+ uint8_t what; /**< ::XIPropertyDeleted,
+ ::XIPropertyCreated,
+ ::XIPropertyMotified */
+ uint8_t pad0;
+ uint16_t pad1;
+ uint32_t pad2;
+ uint32_t pad3;
+} xXIPropertyEvent;
+
+
+#undef Window
+#undef Time
+#undef Atom
+#undef Cursor
+
+#endif /* _XI2PROTO_H_ */
diff --git a/proto/inputproto/XI2proto.txt b/proto/inputproto/XI2proto.txt
new file mode 100644
index 000000000..706f50a03
--- /dev/null
+++ b/proto/inputproto/XI2proto.txt
@@ -0,0 +1,1677 @@
+
+ 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 }
+
+ XIQueryDevices details information about the requested input devices.
+
+ devices
+ The device to list. If devices is AllDevices, all enabled and
+ disabled devices are listed. If devices is AllMasterDevices, all
+ enabled and disabled master devices are listed. If devices is a
+ valid DEVICE, only this DEVICE is listed and num_devices is 1.
+ num_devices
+ The number of deviceinfos returned.
+
+ Each deviceinfo is detailed as follows:
+ deviceid
+ The unique ID of the device. Device IDs may get re-used when a device
+ is removed.
+ use
+ If the device is a master pointer, use is MasterPointer.
+ If the device is a master keyboard, use is MasterKeyboard.
+ If the device is a slave pointer, use is SlavePointer.
+ If the device is a slave keyboard, use is SlaveKeyboard.
+ If the device is a floating slave, use is FloatingSlave.
+ attachment
+ If the device is a master pointer or a master keyboard, attachment
+ specifies the paired master keyboard, or the paired master pointer,
+ respectively. If the device is a non-floating slave device
+ attachment specifies the master device this device is attached to.
+ If the device is a floating slave, attachment is undefined.
+ enabled
+ Zero if the device is disabled, non-zero otherwise.
+ num_classes
+ Number of classes provided.
+ name_len
+ Length of the name in bytes 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, XIGrabDeviceKey or XIGrabDeviceButton) and
+ releases any queued events. If any devices were frozen by the grab,
+ XIUngrabDevice thaws them.
+
+ deviceid
+ The device to grab.
+ time
+ A valid server time or CurrentTime.
+
+ The request has no effect if the specified time is earlier than the
+ last-device-grab time or is later than the current server time.
+ This request generates 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 XIDeleteDeviceProperty.
+
+ This request generates an XIPropertyEvent.
+
+ ┌───
+ XIDeleteProperty
+ deviceid: DEVICEID
+ property: ATOM
+ └───
+
+ Deletes the given property on the given device.
+
+ deviceid
+ The device to delete the property on.
+ property
+ The property to delete.
+
+ If the property is deleted, an XIPropertyEvent is generated on the device.
+ If the property does not exist, this request does nothing.
+
+ ┌───
+ XIGetProperty
+ deviceid: DEVICEID
+ property: ATOM
+ type: Atom or AnyPropertyType
+ offset: CARD32
+ len: CARD32
+ delete: BOOL
+ ▶
+ type: Atom
+ bytes_after: CARD32
+ num_items: CARD32
+ format: { 8, 16, 32 }
+ data: LISTofINT8, or LISTofINT16, or LISTofINT32
+ └───
+
+ Get the data for the given property on the given device.
+
+ deviceid
+ The device to retrieve the property data from.
+ property
+ The property to retrieve the data from..
+ type
+ The property type to retrieve or AnyPropertyType
+ offset
+ The offset in 4-byte units.
+ len
+ Number of bytes to receive in 4-byte units.
+ delete
+ Delete the property after retrieving the data.
+ bytes_after
+ Number of unread bytes in the stored property
+ num_items
+ Number of items in data
+ format
+ 8, 16, or 32
+ data
+ Property data (nitems * format/8 bytes)
+
+ If the specified property does not exist for the specified device, then
+ the return type is None, the format and bytes-after are zero, and the value is
+ empty. The delete argument is ignored in this case. If the specified property
+ exists but its type does not match the specified type, then the return
+ type is the actual type of the property, the format is the actual format of the
+ property (never zero), the bytes-after is the length of the property in bytes
+ (even if the format is 16 or 32), and the value is empty. The delete
+ argument is ignored in this case. If the specified property exists and
+ either AnyPropertyType is specified or the specified type matches the actual
+ type of the property, then the return type is the actual type of the property,
+ the format is the actual format of the property
+ (never zero), and the bytes-after and value are as follows, given:
+ N = actual length of the stored property in bytes
+ (even if the format is 16 or 32)
+ I = 4 * long-offset
+ T = N−I
+ L = MINIMUM(T, 4 * long-length)
+ A = N − (I + L)
+ The returned value starts at byte index I in the property (indexing
+ from 0), and its length in bytes is L. However, it is a Value error if
+ offset is given such that L is negative. The value of bytes_after is A,
+ giving the number of trailing unread bytes in the stored property. If
+ delete is True and the bytes_after is zero, the property is also
+ deleted from the device, and a XIPropertyNotify event is generated on
+ the device.
+
+
+8. Events:
+
+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 XQueryInputDevice
+ request.
+
+ ┌───
+ DeviceEvent:
+ EVENTHEADER
+ detail: CARD32
+ root: Window
+ event: Window
+ child: Window
+ root_x: FP1616
+ root_y: FP1616
+ event_x: FP1616
+ event_y: FP1616
+ buttons_len: CARD16
+ valuators_len: CARD16
+ sourceid: DEVICEID
+ mods: MODIFIERINFO
+ group: GROUPINFO
+ 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.
+
+ 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 RawDevice event provides the information provided by the driver to the
+ client. RawDevice provide both the raw data as supplied by the driver and
+ transformed data as used in the server. Transformations include, but are
+ not limited to, axis clipping and acceleration.
+ Transformed valuator data may be equivalent to raw data. In this case,
+ both raw and transformed valuator data is provided.
+ RawEvents are sent exclusively to all root windows or to the client
+ 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/proto/inputproto/XInput.h b/proto/inputproto/XInput.h
deleted file mode 100644
index 702706d18..000000000
--- a/proto/inputproto/XInput.h
+++ /dev/null
@@ -1,1273 +0,0 @@
-/* $Xorg: XInput.h,v 1.4 2001/02/09 02:03:23 xorgcvs Exp $ */
-
-/************************************************************
-
-Copyright 1989, 1998 The Open Group
-
-Permission to use, copy, modify, distribute, and sell this software and its
-documentation for any purpose is hereby granted without fee, provided that
-the above copyright notice appear in all copies and that both that
-copyright notice and this permission notice appear in supporting
-documentation.
-
-The above copyright notice and this permission notice shall be included in
-all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
-AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
-CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-
-Except as contained in this notice, the name of The Open Group shall not be
-used in advertising or otherwise to promote the sale, use or other dealings
-in this Software without prior written authorization from The Open Group.
-
-Copyright 1989 by Hewlett-Packard Company, Palo Alto, California.
-
- All Rights Reserved
-
-Permission to use, copy, modify, and distribute this software and its
-documentation for any purpose and without fee is hereby granted,
-provided that the above copyright notice appear in all copies and that
-both that copyright notice and this permission notice appear in
-supporting documentation, and that the name of Hewlett-Packard not be
-used in advertising or publicity pertaining to distribution of the
-software without specific, written prior permission.
-
-HEWLETT-PACKARD DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING
-ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL
-HEWLETT-PACKARD BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR
-ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
-WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
-ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
-SOFTWARE.
-
-********************************************************/
-/* $XFree86: xc/include/extensions/XInput.h,v 1.3 2001/12/14 19:53:28 dawes Exp $ */
-
-/* Definitions used by the library and client */
-
-#ifndef _XINPUT_H_
-#define _XINPUT_H_
-
-#include <X11/Xlib.h>
-#include <X11/extensions/XI.h>
-
-#define _deviceKeyPress 0
-#define _deviceKeyRelease 1
-
-#define _deviceButtonPress 0
-#define _deviceButtonRelease 1
-
-#define _deviceMotionNotify 0
-
-#define _deviceFocusIn 0
-#define _deviceFocusOut 1
-
-#define _proximityIn 0
-#define _proximityOut 1
-
-#define _deviceStateNotify 0
-#define _deviceMappingNotify 1
-#define _changeDeviceNotify 2
-/* Space of 3 between is necessary! Reserved for DeviceKeyStateNotify,
- DeviceButtonStateNotify, DevicePresenceNotify (essentially unused). This
- code has to be in sync with FixExtensionEvents() in xserver/Xi/extinit.c */
-#define _propertyNotify 6
-
-#define FindTypeAndClass(d,type,_class,classid,offset) \
- { int _i; XInputClassInfo *_ip; \
- type = 0; _class = 0; \
- for (_i=0, _ip= ((XDevice *) d)->classes; \
- _i< ((XDevice *) d)->num_classes; \
- _i++, _ip++) \
- if (_ip->input_class == classid) \
- {type = _ip->event_type_base + offset; \
- _class = ((XDevice *) d)->device_id << 8 | type;}}
-
-#define DeviceKeyPress(d,type,_class) \
- FindTypeAndClass(d, type, _class, KeyClass, _deviceKeyPress)
-
-#define DeviceKeyRelease(d,type,_class) \
- FindTypeAndClass(d, type, _class, KeyClass, _deviceKeyRelease)
-
-#define DeviceButtonPress(d,type,_class) \
- FindTypeAndClass(d, type, _class, ButtonClass, _deviceButtonPress)
-
-#define DeviceButtonRelease(d,type,_class) \
- FindTypeAndClass(d, type, _class, ButtonClass, _deviceButtonRelease)
-
-#define DeviceMotionNotify(d,type,_class) \
- FindTypeAndClass(d, type, _class, ValuatorClass, _deviceMotionNotify)
-
-#define DeviceFocusIn(d,type,_class) \
- FindTypeAndClass(d, type, _class, FocusClass, _deviceFocusIn)
-
-#define DeviceFocusOut(d,type,_class) \
- FindTypeAndClass(d, type, _class, FocusClass, _deviceFocusOut)
-
-#define ProximityIn(d,type,_class) \
- FindTypeAndClass(d, type, _class, ProximityClass, _proximityIn)
-
-#define ProximityOut(d,type,_class) \
- FindTypeAndClass(d, type, _class, ProximityClass, _proximityOut)
-
-#define DeviceStateNotify(d,type,_class) \
- FindTypeAndClass(d, type, _class, OtherClass, _deviceStateNotify)
-
-#define DeviceMappingNotify(d,type,_class) \
- FindTypeAndClass(d, type, _class, OtherClass, _deviceMappingNotify)
-
-#define ChangeDeviceNotify(d,type,_class) \
- FindTypeAndClass(d, type, _class, OtherClass, _changeDeviceNotify)
-
-#define DevicePropertyNotify(d, type, _class) \
- FindTypeAndClass(d, type, _class, OtherClass, _propertyNotify)
-
-#define DevicePointerMotionHint(d,type,_class) \
- { _class = ((XDevice *) d)->device_id << 8 | _devicePointerMotionHint;}
-
-#define DeviceButton1Motion(d,type,_class) \
- { _class = ((XDevice *) d)->device_id << 8 | _deviceButton1Motion;}
-
-#define DeviceButton2Motion(d,type,_class) \
- { _class = ((XDevice *) d)->device_id << 8 | _deviceButton2Motion;}
-
-#define DeviceButton3Motion(d,type,_class) \
- { _class = ((XDevice *) d)->device_id << 8 | _deviceButton3Motion;}
-
-#define DeviceButton4Motion(d,type, _class) \
- { _class = ((XDevice *) d)->device_id << 8 | _deviceButton4Motion;}
-
-#define DeviceButton5Motion(d,type,_class) \
- { _class = ((XDevice *) d)->device_id << 8 | _deviceButton5Motion;}
-
-#define DeviceButtonMotion(d,type, _class) \
- { _class = ((XDevice *) d)->device_id << 8 | _deviceButtonMotion;}
-
-#define DeviceOwnerGrabButton(d,type,_class) \
- { _class = ((XDevice *) d)->device_id << 8 | _deviceOwnerGrabButton;}
-
-#define DeviceButtonPressGrab(d,type,_class) \
- { _class = ((XDevice *) d)->device_id << 8 | _deviceButtonGrab;}
-
-#define NoExtensionEvent(d,type,_class) \
- { _class = ((XDevice *) d)->device_id << 8 | _noExtensionEvent;}
-
-#define DevicePresence(dpy, type, _class) \
- { \
- extern int _XiGetDevicePresenceNotifyEvent(Display *); \
- type = _XiGetDevicePresenceNotifyEvent(dpy); \
- _class = (0x10000 | _devicePresence); \
- }
-
-#define BadDevice(dpy,error) _xibaddevice(dpy, &error)
-
-#define BadClass(dpy,error) _xibadclass(dpy, &error)
-
-#define BadEvent(dpy,error) _xibadevent(dpy, &error)
-
-#define BadMode(dpy,error) _xibadmode(dpy, &error)
-
-#define DeviceBusy(dpy,error) _xidevicebusy(dpy, &error)
-
-/***************************************************************
- *
- * DeviceKey events. These events are sent by input devices that
- * support input class Keys.
- * The location of the X pointer is reported in the coordinate
- * fields of the x,y and x_root,y_root fields.
- *
- */
-
-typedef struct
- {
- int type; /* of event */
- unsigned long serial; /* # of last request processed */
- Bool send_event; /* true if from SendEvent request */
- Display *display; /* Display the event was read from */
- Window window; /* "event" window reported relative to */
- XID deviceid;
- Window root; /* root window event occured on */
- Window subwindow; /* child window */
- Time time; /* milliseconds */
- int x, y; /* x, y coordinates in event window */
- int x_root; /* coordinates relative to root */
- int y_root; /* coordinates relative to root */
- unsigned int state; /* key or button mask */
- unsigned int keycode; /* detail */
- Bool same_screen; /* same screen flag */
- unsigned int device_state; /* device key or button mask */
- unsigned char axes_count;
- unsigned char first_axis;
- int axis_data[6];
- } XDeviceKeyEvent;
-
-typedef XDeviceKeyEvent XDeviceKeyPressedEvent;
-typedef XDeviceKeyEvent XDeviceKeyReleasedEvent;
-
-/*******************************************************************
- *
- * DeviceButton events. These events are sent by extension devices
- * that support input class Buttons.
- *
- */
-
-typedef struct {
- int type; /* of event */
- unsigned long serial; /* # of last request processed by server */
- Bool send_event; /* true if from a SendEvent request */
- Display *display; /* Display the event was read from */
- Window window; /* "event" window reported relative to */
- XID deviceid;
- Window root; /* root window that the event occured on */
- Window subwindow; /* child window */
- Time time; /* milliseconds */
- int x, y; /* x, y coordinates in event window */
- int x_root; /* coordinates relative to root */
- int y_root; /* coordinates relative to root */
- unsigned int state; /* key or button mask */
- unsigned int button; /* detail */
- Bool same_screen; /* same screen flag */
- unsigned int device_state; /* device key or button mask */
- unsigned char axes_count;
- unsigned char first_axis;
- int axis_data[6];
- } XDeviceButtonEvent;
-
-typedef XDeviceButtonEvent XDeviceButtonPressedEvent;
-typedef XDeviceButtonEvent XDeviceButtonReleasedEvent;
-
-/*******************************************************************
- *
- * DeviceMotionNotify event. These events are sent by extension devices
- * that support input class Valuators.
- *
- */
-
-typedef struct
- {
- int type; /* of event */
- unsigned long serial; /* # of last request processed by server */
- Bool send_event; /* true if from a SendEvent request */
- Display *display; /* Display the event was read from */
- Window window; /* "event" window reported relative to */
- XID deviceid;
- Window root; /* root window that the event occured on */
- Window subwindow; /* child window */
- Time time; /* milliseconds */
- int x, y; /* x, y coordinates in event window */
- int x_root; /* coordinates relative to root */
- int y_root; /* coordinates relative to root */
- unsigned int state; /* key or button mask */
- char is_hint; /* detail */
- Bool same_screen; /* same screen flag */
- unsigned int device_state; /* device key or button mask */
- unsigned char axes_count;
- unsigned char first_axis;
- int axis_data[6];
- } XDeviceMotionEvent;
-
-/*******************************************************************
- *
- * DeviceFocusChange events. These events are sent when the focus
- * of an extension device that can be focused is changed.
- *
- */
-
-typedef struct
- {
- int type; /* of event */
- unsigned long serial; /* # of last request processed by server */
- Bool send_event; /* true if from a SendEvent request */
- Display *display; /* Display the event was read from */
- Window window; /* "event" window reported relative to */
- XID deviceid;
- int mode; /* NotifyNormal, NotifyGrab, NotifyUngrab */
- int detail;
- /*
- * NotifyAncestor, NotifyVirtual, NotifyInferior,
- * NotifyNonLinear,NotifyNonLinearVirtual, NotifyPointer,
- * NotifyPointerRoot, NotifyDetailNone
- */
- Time time;
- } XDeviceFocusChangeEvent;
-
-typedef XDeviceFocusChangeEvent XDeviceFocusInEvent;
-typedef XDeviceFocusChangeEvent XDeviceFocusOutEvent;
-
-/*******************************************************************
- *
- * ProximityNotify events. These events are sent by those absolute
- * positioning devices that are capable of generating proximity information.
- *
- */
-
-typedef struct
- {
- int type; /* ProximityIn or ProximityOut */
- unsigned long serial; /* # of last request processed by server */
- Bool send_event; /* true if this came from a SendEvent request */
- Display *display; /* Display the event was read from */
- Window window;
- XID deviceid;
- Window root;
- Window subwindow;
- Time time;
- int x, y;
- int x_root, y_root;
- unsigned int state;
- Bool same_screen;
- unsigned int device_state; /* device key or button mask */
- unsigned char axes_count;
- unsigned char first_axis;
- int axis_data[6];
- } XProximityNotifyEvent;
-typedef XProximityNotifyEvent XProximityInEvent;
-typedef XProximityNotifyEvent XProximityOutEvent;
-
-/*******************************************************************
- *
- * DeviceStateNotify events are generated on EnterWindow and FocusIn
- * for those clients who have selected DeviceState.
- *
- */
-
-typedef struct
- {
-#if defined(__cplusplus) || defined(c_plusplus)
- unsigned char c_class;
-#else
- unsigned char class;
-#endif
- unsigned char length;
- } XInputClass;
-
-typedef struct {
- int type;
- unsigned long serial; /* # of last request processed by server */
- Bool send_event; /* true if this came from a SendEvent request */
- Display *display; /* Display the event was read from */
- Window window;
- XID deviceid;
- Time time;
- int num_classes;
- char data[64];
-} XDeviceStateNotifyEvent;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- unsigned char c_class;
-#else
- unsigned char class;
-#endif
- unsigned char length;
- unsigned char num_valuators;
- unsigned char mode;
- int valuators[6];
-} XValuatorStatus;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- unsigned char c_class;
-#else
- unsigned char class;
-#endif
- unsigned char length;
- short num_keys;
- char keys[32];
-} XKeyStatus;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- unsigned char c_class;
-#else
- unsigned char class;
-#endif
- unsigned char length;
- short num_buttons;
- char buttons[32];
-} XButtonStatus;
-
-/*******************************************************************
- *
- * DeviceMappingNotify event. This event is sent when the key mapping,
- * modifier mapping, or button mapping of an extension device is changed.
- *
- */
-
-typedef struct {
- int type;
- unsigned long serial; /* # of last request processed by server */
- Bool send_event; /* true if this came from a SendEvent request */
- Display *display; /* Display the event was read from */
- Window window; /* unused */
- XID deviceid;
- Time time;
- int request; /* one of MappingModifier, MappingKeyboard,
- MappingPointer */
- int first_keycode;/* first keycode */
- int count; /* defines range of change w. first_keycode*/
-} XDeviceMappingEvent;
-
-/*******************************************************************
- *
- * ChangeDeviceNotify event. This event is sent when an
- * XChangeKeyboard or XChangePointer request is made.
- *
- */
-
-typedef struct {
- int type;
- unsigned long serial; /* # of last request processed by server */
- Bool send_event; /* true if this came from a SendEvent request */
- Display *display; /* Display the event was read from */
- Window window; /* unused */
- XID deviceid;
- Time time;
- int request; /* NewPointer or NewKeyboard */
-} XChangeDeviceNotifyEvent;
-
-/*******************************************************************
- *
- * DevicePresenceNotify event. This event is sent when the list of
- * input devices changes, in which case devchange will be false, and
- * no information about the change will be contained in the event;
- * the client should use XListInputDevices() to learn what has changed.
- *
- * If devchange is true, an attribute that the server believes is
- * important has changed on a device, and the client should use
- * XGetDeviceControl to examine the device. If control is non-zero,
- * then that control has changed meaningfully.
- */
-
-typedef struct {
- int type;
- unsigned long serial; /* # of last request processed by server */
- Bool send_event; /* true if this came from a SendEvent request */
- Display *display; /* Display the event was read from */
- Window window; /* unused */
- Time time;
- Bool devchange;
- XID deviceid;
- XID control;
-} XDevicePresenceNotifyEvent;
-
-/*
- * Notifies the client that a property on a device has changed value. The
- * client is expected to query the server for updated value of the property.
- */
-typedef struct {
- int type;
- unsigned long serial; /* # of last request processed by server */
- Bool send_event; /* true if this came from a SendEvent request */
- Display *display; /* Display the event was read from */
- Window window; /* unused */
- Time time;
- XID deviceid; /* id of the device that changed */
- Atom atom; /* the property that changed */
- int state; /* PropertyNewValue or PropertyDeleted */
-} XDevicePropertyNotifyEvent;
-
-/*******************************************************************
- *
- * Control structures for input devices that support input class
- * Feedback. These are used by the XGetFeedbackControl and
- * XChangeFeedbackControl functions.
- *
- */
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- XID id;
-} XFeedbackState;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- XID id;
- int click;
- int percent;
- int pitch;
- int duration;
- int led_mask;
- int global_auto_repeat;
- char auto_repeats[32];
-} XKbdFeedbackState;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- XID id;
- int accelNum;
- int accelDenom;
- int threshold;
-} XPtrFeedbackState;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- XID id;
- int resolution;
- int minVal;
- int maxVal;
-} XIntegerFeedbackState;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- XID id;
- int max_symbols;
- int num_syms_supported;
- KeySym *syms_supported;
-} XStringFeedbackState;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- XID id;
- int percent;
- int pitch;
- int duration;
-} XBellFeedbackState;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- XID id;
- int led_values;
- int led_mask;
-} XLedFeedbackState;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- XID id;
-} XFeedbackControl;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- XID id;
- int accelNum;
- int accelDenom;
- int threshold;
-} XPtrFeedbackControl;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- XID id;
- int click;
- int percent;
- int pitch;
- int duration;
- int led_mask;
- int led_value;
- int key;
- int auto_repeat_mode;
-} XKbdFeedbackControl;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- XID id;
- int num_keysyms;
- KeySym *syms_to_display;
-} XStringFeedbackControl;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- XID id;
- int int_to_display;
-} XIntegerFeedbackControl;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- XID id;
- int percent;
- int pitch;
- int duration;
-} XBellFeedbackControl;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- XID id;
- int led_mask;
- int led_values;
-} XLedFeedbackControl;
-
-/*******************************************************************
- *
- * Device control structures.
- *
- */
-
-typedef struct {
- XID control;
- int length;
-} XDeviceControl;
-
-typedef struct {
- XID control;
- int length;
- int first_valuator;
- int num_valuators;
- int *resolutions;
-} XDeviceResolutionControl;
-
-typedef struct {
- XID control;
- int length;
- int num_valuators;
- int *resolutions;
- int *min_resolutions;
- int *max_resolutions;
-} XDeviceResolutionState;
-
-typedef struct {
- XID control;
- int length;
- int min_x;
- int max_x;
- int min_y;
- int max_y;
- int flip_x;
- int flip_y;
- int rotation;
- int button_threshold;
-} XDeviceAbsCalibControl, XDeviceAbsCalibState;
-
-typedef struct {
- XID control;
- int length;
- int offset_x;
- int offset_y;
- int width;
- int height;
- int screen;
- XID following;
-} XDeviceAbsAreaControl, XDeviceAbsAreaState;
-
-typedef struct {
- XID control;
- int length;
- int status;
-} XDeviceCoreControl;
-
-typedef struct {
- XID control;
- int length;
- int status;
- int iscore;
-} XDeviceCoreState;
-
-typedef struct {
- XID control;
- int length;
- int enable;
-} XDeviceEnableControl, XDeviceEnableState;
-
-/*******************************************************************
- *
- * An array of XDeviceList structures is returned by the
- * XListInputDevices function. Each entry contains information
- * about one input device. Among that information is an array of
- * pointers to structures that describe the characteristics of
- * the input device.
- *
- */
-
-typedef struct _XAnyClassinfo *XAnyClassPtr;
-
-typedef struct _XAnyClassinfo {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- } XAnyClassInfo;
-
-typedef struct _XDeviceInfo *XDeviceInfoPtr;
-
-typedef struct _XDeviceInfo
- {
- XID id;
- Atom type;
- char *name;
- int num_classes;
- int use;
- XAnyClassPtr inputclassinfo;
- } XDeviceInfo;
-
-typedef struct _XKeyInfo *XKeyInfoPtr;
-
-typedef struct _XKeyInfo
- {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- unsigned short min_keycode;
- unsigned short max_keycode;
- unsigned short num_keys;
- } XKeyInfo;
-
-typedef struct _XButtonInfo *XButtonInfoPtr;
-
-typedef struct _XButtonInfo {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- short num_buttons;
- } XButtonInfo;
-
-typedef struct _XAxisInfo *XAxisInfoPtr;
-
-typedef struct _XAxisInfo {
- int resolution;
- int min_value;
- int max_value;
- } XAxisInfo;
-
-typedef struct _XValuatorInfo *XValuatorInfoPtr;
-
-typedef struct _XValuatorInfo
- {
-#if defined(__cplusplus) || defined(c_plusplus)
- XID c_class;
-#else
- XID class;
-#endif
- int length;
- unsigned char num_axes;
- unsigned char mode;
- unsigned long motion_buffer;
- XAxisInfoPtr axes;
- } XValuatorInfo;
-
-
-/*******************************************************************
- *
- * An XDevice structure is returned by the XOpenDevice function.
- * It contains an array of pointers to XInputClassInfo structures.
- * Each contains information about a class of input supported by the
- * device, including a pointer to an array of data for each type of event
- * the device reports.
- *
- */
-
-
-typedef struct {
- unsigned char input_class;
- unsigned char event_type_base;
-} XInputClassInfo;
-
-typedef struct {
- XID device_id;
- int num_classes;
- XInputClassInfo *classes;
-} XDevice;
-
-
-/*******************************************************************
- *
- * The following structure is used to return information for the
- * XGetSelectedExtensionEvents function.
- *
- */
-
-typedef struct {
- XEventClass event_type;
- XID device;
-} XEventList;
-
-/*******************************************************************
- *
- * The following structure is used to return motion history data from
- * an input device that supports the input class Valuators.
- * This information is returned by the XGetDeviceMotionEvents function.
- *
- */
-
-typedef struct {
- Time time;
- int *data;
-} XDeviceTimeCoord;
-
-
-/*******************************************************************
- *
- * Device state structure.
- * This is returned by the XQueryDeviceState request.
- *
- */
-
-typedef struct {
- XID device_id;
- int num_classes;
- XInputClass *data;
-} XDeviceState;
-
-/*******************************************************************
- *
- * Note that the mode field is a bitfield that reports the Proximity
- * status of the device as well as the mode. The mode field should
- * be OR'd with the mask DeviceMode and compared with the values
- * Absolute and Relative to determine the mode, and should be OR'd
- * with the mask ProximityState and compared with the values InProximity
- * and OutOfProximity to determine the proximity state.
- *
- */
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- unsigned char c_class;
-#else
- unsigned char class;
-#endif
- unsigned char length;
- unsigned char num_valuators;
- unsigned char mode;
- int *valuators;
-} XValuatorState;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- unsigned char c_class;
-#else
- unsigned char class;
-#endif
- unsigned char length;
- short num_keys;
- char keys[32];
-} XKeyState;
-
-typedef struct {
-#if defined(__cplusplus) || defined(c_plusplus)
- unsigned char c_class;
-#else
- unsigned char class;
-#endif
- unsigned char length;
- short num_buttons;
- char buttons[32];
-} XButtonState;
-
-/*******************************************************************
- *
- * Function definitions.
- *
- */
-
-_XFUNCPROTOBEGIN
-
-extern int XChangeKeyboardDevice(
- Display* /* display */,
- XDevice* /* device */
-);
-
-extern int XChangePointerDevice(
- Display* /* display */,
- XDevice* /* device */,
- int /* xaxis */,
- int /* yaxis */
-);
-
-extern int XGrabDevice(
- Display* /* display */,
- XDevice* /* device */,
- Window /* grab_window */,
- Bool /* ownerEvents */,
- int /* event count */,
- XEventClass* /* event_list */,
- int /* this_device_mode */,
- int /* other_devices_mode */,
- Time /* time */
-);
-
-extern int XUngrabDevice(
- Display* /* display */,
- XDevice* /* device */,
- Time /* time */
-);
-
-extern int XGrabDeviceKey(
- Display* /* display */,
- XDevice* /* device */,
- unsigned int /* key */,
- unsigned int /* modifiers */,
- XDevice* /* modifier_device */,
- Window /* grab_window */,
- Bool /* owner_events */,
- unsigned int /* event_count */,
- XEventClass* /* event_list */,
- int /* this_device_mode */,
- int /* other_devices_mode */
-);
-
-extern int XUngrabDeviceKey(
- Display* /* display */,
- XDevice* /* device */,
- unsigned int /* key */,
- unsigned int /* modifiers */,
- XDevice* /* modifier_dev */,
- Window /* grab_window */
-);
-
-extern int XGrabDeviceButton(
- Display* /* display */,
- XDevice* /* device */,
- unsigned int /* button */,
- unsigned int /* modifiers */,
- XDevice* /* modifier_device */,
- Window /* grab_window */,
- Bool /* owner_events */,
- unsigned int /* event_count */,
- XEventClass* /* event_list */,
- int /* this_device_mode */,
- int /* other_devices_mode */
-);
-
-extern int XUngrabDeviceButton(
- Display* /* display */,
- XDevice* /* device */,
- unsigned int /* button */,
- unsigned int /* modifiers */,
- XDevice* /* modifier_dev */,
- Window /* grab_window */
-);
-
-extern int XAllowDeviceEvents(
- Display* /* display */,
- XDevice* /* device */,
- int /* event_mode */,
- Time /* time */
-);
-
-extern int XGetDeviceFocus(
- Display* /* display */,
- XDevice* /* device */,
- Window* /* focus */,
- int* /* revert_to */,
- Time* /* time */
-);
-
-extern int XSetDeviceFocus(
- Display* /* display */,
- XDevice* /* device */,
- Window /* focus */,
- int /* revert_to */,
- Time /* time */
-);
-
-extern XFeedbackState *XGetFeedbackControl(
- Display* /* display */,
- XDevice* /* device */,
- int* /* num_feedbacks */
-);
-
-extern void XFreeFeedbackList(
- XFeedbackState* /* list */
-);
-
-extern int XChangeFeedbackControl(
- Display* /* display */,
- XDevice* /* device */,
- unsigned long /* mask */,
- XFeedbackControl* /* f */
-);
-
-extern int XDeviceBell(
- Display* /* display */,
- XDevice* /* device */,
- XID /* feedbackclass */,
- XID /* feedbackid */,
- int /* percent */
-);
-
-extern KeySym *XGetDeviceKeyMapping(
- Display* /* display */,
- XDevice* /* device */,
-#if NeedWidePrototypes
- unsigned int /* first */,
-#else
- KeyCode /* first */,
-#endif
- int /* keycount */,
- int* /* syms_per_code */
-);
-
-extern int XChangeDeviceKeyMapping(
- Display* /* display */,
- XDevice* /* device */,
- int /* first */,
- int /* syms_per_code */,
- KeySym* /* keysyms */,
- int /* count */
-);
-
-extern XModifierKeymap *XGetDeviceModifierMapping(
- Display* /* display */,
- XDevice* /* device */
-);
-
-extern int XSetDeviceModifierMapping(
- Display* /* display */,
- XDevice* /* device */,
- XModifierKeymap* /* modmap */
-);
-
-extern int XSetDeviceButtonMapping(
- Display* /* display */,
- XDevice* /* device */,
- unsigned char* /* map[] */,
- int /* nmap */
-);
-
-extern int XGetDeviceButtonMapping(
- Display* /* display */,
- XDevice* /* device */,
- unsigned char* /* map[] */,
- unsigned int /* nmap */
-);
-
-extern XDeviceState *XQueryDeviceState(
- Display* /* display */,
- XDevice* /* device */
-);
-
-extern void XFreeDeviceState(
- XDeviceState* /* list */
-);
-
-extern XExtensionVersion *XGetExtensionVersion(
- Display* /* display */,
- _Xconst char* /* name */
-);
-
-extern XDeviceInfo *XListInputDevices(
- Display* /* display */,
- int* /* ndevices */
-);
-
-extern void XFreeDeviceList(
- XDeviceInfo* /* list */
-);
-
-extern XDevice *XOpenDevice(
- Display* /* display */,
- XID /* id */
-);
-
-extern int XCloseDevice(
- Display* /* display */,
- XDevice* /* device */
-);
-
-extern int XSetDeviceMode(
- Display* /* display */,
- XDevice* /* device */,
- int /* mode */
-);
-
-extern int XSetDeviceValuators(
- Display* /* display */,
- XDevice* /* device */,
- int* /* valuators */,
- int /* first_valuator */,
- int /* num_valuators */
-);
-
-extern XDeviceControl *XGetDeviceControl(
- Display* /* display */,
- XDevice* /* device */,
- int /* control */
-);
-
-extern int XChangeDeviceControl(
- Display* /* display */,
- XDevice* /* device */,
- int /* control */,
- XDeviceControl* /* d */
-);
-
-extern int XSelectExtensionEvent(
- Display* /* display */,
- Window /* w */,
- XEventClass* /* event_list */,
- int /* count */
-);
-
-extern int XGetSelectedExtensionEvents(
- Display* /* display */,
- Window /* w */,
- int* /* this_client_count */,
- XEventClass** /* this_client_list */,
- int* /* all_clients_count */,
- XEventClass** /* all_clients_list */
-);
-
-extern int XChangeDeviceDontPropagateList(
- Display* /* display */,
- Window /* window */,
- int /* count */,
- XEventClass* /* events */,
- int /* mode */
-);
-
-extern XEventClass *XGetDeviceDontPropagateList(
- Display* /* display */,
- Window /* window */,
- int* /* count */
-);
-
-extern Status XSendExtensionEvent(
- Display* /* display */,
- XDevice* /* device */,
- Window /* dest */,
- Bool /* prop */,
- int /* count */,
- XEventClass* /* list */,
- XEvent* /* event */
-);
-
-extern XDeviceTimeCoord *XGetDeviceMotionEvents(
- Display* /* display */,
- XDevice* /* device */,
- Time /* start */,
- Time /* stop */,
- int* /* nEvents */,
- int* /* mode */,
- int* /* axis_count */
-);
-
-extern void XFreeDeviceMotionEvents(
- XDeviceTimeCoord* /* events */
-);
-
-extern void XFreeDeviceControl(
- XDeviceControl* /* control */
-);
-
-typedef struct {
- Bool pending;
- Bool range;
- Bool immutable;
- Bool fromClient;
- int num_values;
- long *values;
-} XIPropertyInfo;
-
-extern Atom* XListDeviceProperties(
- Display* /* dpy */,
- XDevice* /* dev */,
- int* /* nprops_return */
-);
-
-extern void XChangeDeviceProperty(
- Display* /* dpy */,
- XDevice* /* dev */,
- Atom /* property */,
- Atom /* type */,
- int /* format */,
- int /* mode */,
- _Xconst unsigned char * /*data */,
- int /* nelements */
-);
-
-extern void
-XDeleteDeviceProperty(
- Display* /* dpy */,
- XDevice* /* dev */,
- Atom /* property */
-);
-
-extern Status
-XGetDeviceProperty(
- Display* /* dpy*/,
- XDevice* /* dev*/,
- Atom /* property*/,
- long /* offset*/,
- long /* length*/,
- Bool /* delete*/,
- Atom /* req_type*/,
- Atom* /* actual_type*/,
- int* /* actual_format*/,
- unsigned long* /* nitems*/,
- unsigned long* /* bytes_after*/,
- unsigned char** /* prop*/
-);
-
-
-_XFUNCPROTOEND
-
-#endif /* _XINPUT_H_ */
diff --git a/proto/inputproto/XIproto.h b/proto/inputproto/XIproto.h
index eef3ee8f8..e00ab61dc 100644
--- a/proto/inputproto/XIproto.h
+++ b/proto/inputproto/XIproto.h
@@ -54,7 +54,9 @@ SOFTWARE.
#define Window CARD32
#define Time CARD32
#define KeyCode CARD8
+#define Mask CARD32
#define Atom CARD32
+#define Cursor CARD32
/*********************************************************
*
@@ -70,16 +72,16 @@ SOFTWARE.
#define numInputClasses 7
-#define IEVENTS 17
-#define IERRORS 5
-#define IREQUESTS 41
+#define IEVENTS 17 /* does NOT include generic events */
+#define IERRORS 5
+#define IREQUESTS 39
-#define CLIENT_REQ 1
+#define CLIENT_REQ 1
typedef struct _XExtEventInfo
{
Mask mask;
- BYTE type;
+ BYTE type;
BYTE word;
} XExtEventInfo;
@@ -115,7 +117,6 @@ struct tmask
#define XI_DevicePresenceNotify 15
#define XI_DevicePropertyNotify 16
-
/*********************************************************
*
* Protocol request constants
@@ -127,15 +128,15 @@ struct tmask
#define X_OpenDevice 3
#define X_CloseDevice 4
#define X_SetDeviceMode 5
-#define X_SelectExtensionEvent 6
+#define X_SelectExtensionEvent 6
#define X_GetSelectedExtensionEvents 7
#define X_ChangeDeviceDontPropagateList 8
-#define X_GetDeviceDontPropagateList 9
-#define X_GetDeviceMotionEvents 10
+#define X_GetDeviceDontPropagateList 9
+#define X_GetDeviceMotionEvents 10
#define X_ChangeKeyboardDevice 11
#define X_ChangePointerDevice 12
-#define X_GrabDevice 13
-#define X_UngrabDevice 14
+#define X_GrabDevice 13
+#define X_UngrabDevice 14
#define X_GrabDeviceKey 15
#define X_UngrabDeviceKey 16
#define X_GrabDeviceButton 17
@@ -151,8 +152,8 @@ struct tmask
#define X_SetDeviceModifierMapping 27
#define X_GetDeviceButtonMapping 28
#define X_SetDeviceButtonMapping 29
-#define X_QueryDeviceState 30
-#define X_SendExtensionEvent 31
+#define X_QueryDeviceState 30
+#define X_SendExtensionEvent 31
#define X_DeviceBell 32
#define X_SetDeviceValuators 33
#define X_GetDeviceControl 34
@@ -172,26 +173,26 @@ struct tmask
*/
typedef struct {
- CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_GetExtensionVersion */
- CARD16 length B16;
- CARD16 nbytes B16;
- CARD8 pad1, pad2;
+ CARD8 reqType; /* input extension major code */
+ CARD8 ReqType; /* always X_GetExtensionVersion */
+ CARD16 length B16;
+ CARD16 nbytes B16;
+ CARD8 pad1, pad2;
} xGetExtensionVersionReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_GetExtensionVersion */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD16 major_version B16;
- CARD16 minor_version B16;
- BOOL present;
- CARD8 pad1, pad2, pad3;
- CARD32 pad01 B32;
- CARD32 pad02 B32;
- CARD32 pad03 B32;
- CARD32 pad04 B32;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_GetExtensionVersion */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD16 major_version B16;
+ CARD16 minor_version B16;
+ BOOL present;
+ CARD8 pad1, pad2, pad3;
+ CARD32 pad01 B32;
+ CARD32 pad02 B32;
+ CARD32 pad03 B32;
+ CARD32 pad04 B32;
} xGetExtensionVersionReply;
/*********************************************************
@@ -201,23 +202,23 @@ typedef struct {
*/
typedef struct {
- CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_ListInputDevices */
- CARD16 length B16;
+ CARD8 reqType; /* input extension major code */
+ CARD8 ReqType; /* always X_ListInputDevices */
+ CARD16 length B16;
} xListInputDevicesReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_ListInputDevices */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD8 ndevices;
- CARD8 pad1, pad2, pad3;
- CARD32 pad01 B32;
- CARD32 pad02 B32;
- CARD32 pad03 B32;
- CARD32 pad04 B32;
- CARD32 pad05 B32;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_ListInputDevices */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD8 ndevices;
+ CARD8 pad1, pad2, pad3;
+ CARD32 pad01 B32;
+ CARD32 pad02 B32;
+ CARD32 pad03 B32;
+ CARD32 pad04 B32;
+ CARD32 pad05 B32;
} xListInputDevicesReply;
typedef struct _xDeviceInfo *xDeviceInfoPtr;
@@ -226,68 +227,68 @@ typedef struct _xAnyClassinfo *xAnyClassPtr;
typedef struct _xAnyClassinfo {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class;
+ CARD8 c_class;
#else
- CARD8 class;
+ CARD8 class;
#endif
- CARD8 length;
+ CARD8 length;
} xAnyClassInfo;
typedef struct _xDeviceInfo {
CARD32 type B32;
CARD8 id;
- CARD8 num_classes;
- CARD8 use;
- CARD8 pad1;
+ CARD8 num_classes;
+ CARD8 use; /* IsXPointer | IsXKeyboard | IsXExtension... */
+ CARD8 attached; /* id of master dev (if IsXExtension..) */
} xDeviceInfo;
typedef struct _xKeyInfo *xKeyInfoPtr;
typedef struct _xKeyInfo {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class;
+ CARD8 c_class;
#else
- CARD8 class;
+ CARD8 class;
#endif
- CARD8 length;
- KeyCode min_keycode;
- KeyCode max_keycode;
- CARD16 num_keys B16;
- CARD8 pad1,pad2;
+ CARD8 length;
+ KeyCode min_keycode;
+ KeyCode max_keycode;
+ CARD16 num_keys B16;
+ CARD8 pad1,pad2;
} xKeyInfo;
typedef struct _xButtonInfo *xButtonInfoPtr;
typedef struct _xButtonInfo {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class;
+ CARD8 c_class;
#else
- CARD8 class;
+ CARD8 class;
#endif
- CARD8 length;
- CARD16 num_buttons B16;
+ CARD8 length;
+ CARD16 num_buttons B16;
} xButtonInfo;
typedef struct _xValuatorInfo *xValuatorInfoPtr;
typedef struct _xValuatorInfo {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class;
+ CARD8 c_class;
#else
- CARD8 class;
+ CARD8 class;
#endif
- CARD8 length;
- CARD8 num_axes;
- CARD8 mode;
- CARD32 motion_buffer_size B32;
+ CARD8 length;
+ CARD8 num_axes;
+ CARD8 mode;
+ CARD32 motion_buffer_size B32;
} xValuatorInfo;
typedef struct _xAxisInfo *xAxisInfoPtr;
typedef struct _xAxisInfo {
- CARD32 resolution B32;
- CARD32 min_value B32;
- CARD32 max_value B32;
+ CARD32 resolution B32;
+ CARD32 min_value B32;
+ CARD32 max_value B32;
} xAxisInfo;
/*********************************************************
@@ -298,33 +299,33 @@ typedef struct _xAxisInfo {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_OpenDevice */
- CARD16 length B16;
+ CARD8 ReqType; /* always X_OpenDevice */
+ CARD16 length B16;
CARD8 deviceid;
BYTE pad1, pad2, pad3;
} xOpenDeviceReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_OpenDevice */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD8 num_classes;
- BYTE pad1, pad2, pad3;
- CARD32 pad00 B32;
- CARD32 pad01 B32;
- CARD32 pad02 B32;
- CARD32 pad03 B32;
- CARD32 pad04 B32;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_OpenDevice */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD8 num_classes;
+ BYTE pad1, pad2, pad3;
+ CARD32 pad00 B32;
+ CARD32 pad01 B32;
+ CARD32 pad02 B32;
+ CARD32 pad03 B32;
+ CARD32 pad04 B32;
} xOpenDeviceReply;
typedef struct {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class;
+ CARD8 c_class;
#else
- CARD8 class;
+ CARD8 class;
#endif
- CARD8 event_type_base;
+ CARD8 event_type_base;
} xInputClassInfo;
/*********************************************************
@@ -335,8 +336,8 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_CloseDevice */
- CARD16 length B16;
+ CARD8 ReqType; /* always X_CloseDevice */
+ CARD16 length B16;
CARD8 deviceid;
BYTE pad1, pad2, pad3;
} xCloseDeviceReq;
@@ -348,26 +349,26 @@ typedef struct {
*/
typedef struct {
- CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_SetDeviceMode */
- CARD16 length B16;
+ CARD8 reqType; /* input extension major code */
+ CARD8 ReqType; /* always X_SetDeviceMode */
+ CARD16 length B16;
CARD8 deviceid;
CARD8 mode;
- BYTE pad1, pad2;
+ BYTE pad1, pad2;
} xSetDeviceModeReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_SetDeviceMode */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD8 status;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_SetDeviceMode */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD8 status;
BYTE pad1, pad2, pad3;
- CARD32 pad01 B32;
- CARD32 pad02 B32;
- CARD32 pad03 B32;
- CARD32 pad04 B32;
- CARD32 pad05 B32;
+ CARD32 pad01 B32;
+ CARD32 pad02 B32;
+ CARD32 pad03 B32;
+ CARD32 pad04 B32;
+ CARD32 pad05 B32;
} xSetDeviceModeReply;
/*********************************************************
@@ -378,9 +379,9 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_SelectExtensionEvent */
- CARD16 length B16;
- Window window B32;
+ CARD8 ReqType; /* always X_SelectExtensionEvent */
+ CARD16 length B16;
+ Window window B32;
CARD16 count B16;
CARD16 pad00 B16;
} xSelectExtensionEventReq;
@@ -393,23 +394,23 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* X_GetSelectedExtensionEvents */
- CARD16 length B16;
+ CARD8 ReqType; /* X_GetSelectedExtensionEvents */
+ CARD16 length B16;
Window window B32;
} xGetSelectedExtensionEventsReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* GetSelectedExtensionEvents */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD16 this_client_count B16;
- CARD16 all_clients_count B16;
- CARD32 pad01 B32;
- CARD32 pad02 B32;
- CARD32 pad03 B32;
- CARD32 pad04 B32;
- CARD32 pad05 B32;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* GetSelectedExtensionEvents */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD16 this_client_count B16;
+ CARD16 all_clients_count B16;
+ CARD32 pad01 B32;
+ CARD32 pad02 B32;
+ CARD32 pad03 B32;
+ CARD32 pad04 B32;
+ CARD32 pad05 B32;
} xGetSelectedExtensionEventsReply;
/*********************************************************
@@ -420,11 +421,11 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* X_ChangeDeviceDontPropagateList */
- CARD16 length B16;
+ CARD8 ReqType; /* X_ChangeDeviceDontPropagateList */
+ CARD16 length B16;
Window window B32;
- CARD16 count B16;
- CARD8 mode;
+ CARD16 count B16;
+ CARD8 mode;
BYTE pad;
} xChangeDeviceDontPropagateListReq;
@@ -436,23 +437,23 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* X_GetDeviceDontPropagateList */
- CARD16 length B16;
+ CARD8 ReqType; /* X_GetDeviceDontPropagateList */
+ CARD16 length B16;
Window window B32;
} xGetDeviceDontPropagateListReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* GetDeviceDontPropagateList */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD16 count B16;
- CARD16 pad00 B16;
- CARD32 pad01 B32;
- CARD32 pad02 B32;
- CARD32 pad03 B32;
- CARD32 pad04 B32;
- CARD32 pad05 B32;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* GetDeviceDontPropagateList */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD16 count B16;
+ CARD16 pad00 B16;
+ CARD32 pad01 B32;
+ CARD32 pad02 B32;
+ CARD32 pad03 B32;
+ CARD32 pad04 B32;
+ CARD32 pad05 B32;
} xGetDeviceDontPropagateListReply;
/*********************************************************
@@ -462,28 +463,28 @@ typedef struct {
*/
typedef struct {
- CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_GetDeviceMotionEvents*/
- CARD16 length B16;
- Time start B32;
+ CARD8 reqType; /* input extension major code */
+ CARD8 ReqType; /* always X_GetDeviceMotionEvents*/
+ CARD16 length B16;
+ Time start B32;
Time stop B32;
CARD8 deviceid;
BYTE pad1, pad2, pad3;
} xGetDeviceMotionEventsReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_GetDeviceMotionEvents */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD32 nEvents B32;
- CARD8 axes;
- CARD8 mode;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_GetDeviceMotionEvents */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD32 nEvents B32;
+ CARD8 axes;
+ CARD8 mode;
BYTE pad1, pad2;
- CARD32 pad01 B32;
- CARD32 pad02 B32;
- CARD32 pad03 B32;
- CARD32 pad04 B32;
+ CARD32 pad01 B32;
+ CARD32 pad02 B32;
+ CARD32 pad03 B32;
+ CARD32 pad04 B32;
} xGetDeviceMotionEventsReply;
/*********************************************************
@@ -494,24 +495,24 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* X_ChangeKeyboardDevice */
- CARD16 length B16;
- CARD8 deviceid;
+ CARD8 ReqType; /* X_ChangeKeyboardDevice */
+ CARD16 length B16;
+ CARD8 deviceid;
BYTE pad1, pad2, pad3;
} xChangeKeyboardDeviceReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_ChangeKeyboardDevice*/
- CARD16 sequenceNumber B16;
- CARD32 length B32; /* 0 */
- CARD8 status;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_ChangeKeyboardDevice*/
+ CARD16 sequenceNumber B16;
+ CARD32 length B32; /* 0 */
+ CARD8 status;
BYTE pad1, pad2, pad3;
- CARD32 pad01 B32;
- CARD32 pad02 B32;
- CARD32 pad03 B32;
- CARD32 pad04 B32;
- CARD32 pad05 B32;
+ CARD32 pad01 B32;
+ CARD32 pad02 B32;
+ CARD32 pad03 B32;
+ CARD32 pad04 B32;
+ CARD32 pad05 B32;
} xChangeKeyboardDeviceReply;
/*********************************************************
@@ -522,26 +523,26 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* X_ChangePointerDevice */
- CARD16 length B16;
- CARD8 xaxis;
- CARD8 yaxis;
- CARD8 deviceid;
+ CARD8 ReqType; /* X_ChangePointerDevice */
+ CARD16 length B16;
+ CARD8 xaxis;
+ CARD8 yaxis;
+ CARD8 deviceid;
BYTE pad1;
} xChangePointerDeviceReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_ChangePointerDevice */
- CARD16 sequenceNumber B16;
- CARD32 length B32; /* 0 */
- CARD8 status;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_ChangePointerDevice */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32; /* 0 */
+ CARD8 status;
BYTE pad1, pad2, pad3;
- CARD32 pad01 B32;
- CARD32 pad02 B32;
- CARD32 pad03 B32;
- CARD32 pad04 B32;
- CARD32 pad05 B32;
+ CARD32 pad01 B32;
+ CARD32 pad02 B32;
+ CARD32 pad03 B32;
+ CARD32 pad04 B32;
+ CARD32 pad05 B32;
} xChangePointerDeviceReply;
/*********************************************************
@@ -552,30 +553,30 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_GrabDevice */
- CARD16 length B16;
- Window grabWindow B32;
- Time time B32;
+ CARD8 ReqType; /* always X_GrabDevice */
+ CARD16 length B16;
+ Window grabWindow B32;
+ Time time B32;
CARD16 event_count B16;
CARD8 this_device_mode;
CARD8 other_devices_mode;
- BOOL ownerEvents;
- CARD8 deviceid;
- CARD16 pad01 B16;
+ BOOL ownerEvents;
+ CARD8 deviceid;
+ CARD16 pad01 B16;
} xGrabDeviceReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_GrabDevice */
- CARD16 sequenceNumber B16;
- CARD32 length B32; /* 0 */
- CARD8 status;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_GrabDevice */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32; /* 0 */
+ CARD8 status;
BYTE pad1, pad2, pad3;
- CARD32 pad01 B32;
- CARD32 pad02 B32;
- CARD32 pad03 B32;
- CARD32 pad04 B32;
- CARD32 pad05 B32;
+ CARD32 pad01 B32;
+ CARD32 pad02 B32;
+ CARD32 pad03 B32;
+ CARD32 pad04 B32;
+ CARD32 pad05 B32;
} xGrabDeviceReply;
/*********************************************************
@@ -586,10 +587,10 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_UnGrabDevice */
- CARD16 length B16;
- Time time B32;
- CARD8 deviceid;
+ CARD8 ReqType; /* always X_UnGrabDevice */
+ CARD16 length B16;
+ Time time B32;
+ CARD8 deviceid;
BYTE pad1, pad2, pad3;
} xUngrabDeviceReq;
@@ -601,17 +602,17 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_GrabDeviceKey */
- CARD16 length B16;
- Window grabWindow B32;
+ CARD8 ReqType; /* always X_GrabDeviceKey */
+ CARD16 length B16;
+ Window grabWindow B32;
CARD16 event_count B16;
- CARD16 modifiers B16;
+ CARD16 modifiers B16;
CARD8 modifier_device;
CARD8 grabbed_device;
CARD8 key;
- BYTE this_device_mode;
- BYTE other_devices_mode;
- BOOL ownerEvents;
+ BYTE this_device_mode;
+ BYTE other_devices_mode;
+ BOOL ownerEvents;
BYTE pad1, pad2;
} xGrabDeviceKeyReq;
@@ -623,11 +624,11 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_UngrabDeviceKey */
- CARD16 length B16;
- Window grabWindow B32;
+ CARD8 ReqType; /* always X_UngrabDeviceKey */
+ CARD16 length B16;
+ Window grabWindow B32;
CARD16 modifiers B16;
- CARD8 modifier_device;
+ CARD8 modifier_device;
CARD8 key;
CARD8 grabbed_device;
BYTE pad1, pad2, pad3;
@@ -641,17 +642,17 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_GrabDeviceButton */
- CARD16 length B16;
- Window grabWindow B32;
+ CARD8 ReqType; /* always X_GrabDeviceButton */
+ CARD16 length B16;
+ Window grabWindow B32;
CARD8 grabbed_device;
CARD8 modifier_device;
- CARD16 event_count B16;
- CARD16 modifiers B16;
- BYTE this_device_mode;
- BYTE other_devices_mode;
- CARD8 button;
- BOOL ownerEvents;
+ CARD16 event_count B16;
+ CARD16 modifiers B16;
+ BYTE this_device_mode;
+ BYTE other_devices_mode;
+ CARD8 button;
+ BOOL ownerEvents;
BYTE pad1, pad2;
} xGrabDeviceButtonReq;
@@ -663,13 +664,13 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_UngrabDeviceButton */
- CARD16 length B16;
- Window grabWindow B32;
- CARD16 modifiers B16;
- CARD8 modifier_device;
- CARD8 button;
- CARD8 grabbed_device;
+ CARD8 ReqType; /* always X_UngrabDeviceButton */
+ CARD16 length B16;
+ Window grabWindow B32;
+ CARD16 modifiers B16;
+ CARD8 modifier_device;
+ CARD8 button;
+ CARD8 grabbed_device;
BYTE pad1, pad2, pad3;
} xUngrabDeviceButtonReq;
@@ -681,11 +682,11 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_AllowDeviceEvents */
- CARD16 length B16;
- Time time B32;
+ CARD8 ReqType; /* always X_AllowDeviceEvents */
+ CARD16 length B16;
+ Time time B32;
CARD8 mode;
- CARD8 deviceid;
+ CARD8 deviceid;
BYTE pad1, pad2;
} xAllowDeviceEventsReq;
@@ -696,25 +697,25 @@ typedef struct {
*/
typedef struct {
- CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_GetDeviceFocus */
- CARD16 length B16;
- CARD8 deviceid;
- BYTE pad1, pad2, pad3;
+ CARD8 reqType; /* input extension major code */
+ CARD8 ReqType; /* always X_GetDeviceFocus */
+ CARD16 length B16;
+ CARD8 deviceid;
+ BYTE pad1, pad2, pad3;
} xGetDeviceFocusReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_GetDeviceFocus */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD32 focus B32;
- Time time B32;
- CARD8 revertTo;
- BYTE pad1, pad2, pad3;
- CARD32 pad01 B32;
- CARD32 pad02 B32;
- CARD32 pad03 B32;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_GetDeviceFocus */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD32 focus B32;
+ Time time B32;
+ CARD8 revertTo;
+ BYTE pad1, pad2, pad3;
+ CARD32 pad01 B32;
+ CARD32 pad02 B32;
+ CARD32 pad03 B32;
} xGetDeviceFocusReply;
/*********************************************************
@@ -724,14 +725,14 @@ typedef struct {
*/
typedef struct {
- CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_SetDeviceFocus */
- CARD16 length B16;
- Window focus B32;
- Time time B32;
- CARD8 revertTo;
- CARD8 device;
- CARD16 pad01 B16;
+ CARD8 reqType; /* input extension major code */
+ CARD8 ReqType; /* always X_SetDeviceFocus */
+ CARD16 length B16;
+ Window focus B32;
+ Time time B32;
+ CARD8 revertTo;
+ CARD8 device;
+ CARD16 pad01 B16;
} xSetDeviceFocusReq;
/*********************************************************
@@ -742,17 +743,17 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* X_GetFeedbackControl */
- CARD16 length B16;
- CARD8 deviceid;
+ CARD8 ReqType; /* X_GetFeedbackControl */
+ CARD16 length B16;
+ CARD8 deviceid;
BYTE pad1, pad2, pad3;
} xGetFeedbackControlReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_GetFeedbackControl */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_GetFeedbackControl */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
CARD16 num_feedbacks B16;
CARD16 pad01 B16;
CARD32 pad02 B32;
@@ -764,12 +765,12 @@ typedef struct {
typedef struct {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class; /* feedback class */
+ CARD8 c_class; /* feedback class */
#else
- CARD8 class; /* feedback class */
+ CARD8 class; /* feedback class */
#endif
- CARD8 id; /* feedback id */
- CARD16 length B16; /* feedback length */
+ CARD8 id; /* feedback id */
+ CARD16 length B16; /* feedback length */
} xFeedbackState;
typedef struct {
@@ -807,12 +808,12 @@ typedef struct {
typedef struct {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class; /* feedback class id */
+ CARD8 c_class; /* feedback class id */
#else
- CARD8 class; /* feedback class id */
+ CARD8 class; /* feedback class id */
#endif
- CARD8 id;
- CARD16 length B16; /* feedback length */
+ CARD8 id;
+ CARD16 length B16; /* feedback length */
CARD32 resolution B32;
INT32 min_value B32;
INT32 max_value B32;
@@ -820,24 +821,24 @@ typedef struct {
typedef struct {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class; /* feedback class id */
+ CARD8 c_class; /* feedback class id */
#else
- CARD8 class; /* feedback class id */
+ CARD8 class; /* feedback class id */
#endif
- CARD8 id;
- CARD16 length B16; /* feedback length */
+ CARD8 id;
+ CARD16 length B16; /* feedback length */
CARD16 max_symbols B16;
CARD16 num_syms_supported B16;
} xStringFeedbackState;
typedef struct {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class; /* feedback class id */
+ CARD8 c_class; /* feedback class id */
#else
- CARD8 class; /* feedback class id */
+ CARD8 class; /* feedback class id */
#endif
CARD8 id;
- CARD16 length B16; /* feedback length */
+ CARD16 length B16; /* feedback length */
CARD8 percent;
BYTE pad1, pad2, pad3;
CARD16 pitch B16;
@@ -846,12 +847,12 @@ typedef struct {
typedef struct {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class; /* feedback class id */
+ CARD8 c_class; /* feedback class id */
#else
- CARD8 class; /* feedback class id */
+ CARD8 class; /* feedback class id */
#endif
CARD8 id;
- CARD16 length B16; /* feedback length */
+ CARD16 length B16; /* feedback length */
CARD32 led_mask B32;
CARD32 led_values B32;
} xLedFeedbackState;
@@ -864,33 +865,33 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* X_ChangeFeedbackControl */
- CARD16 length B16;
+ CARD8 ReqType; /* X_ChangeFeedbackControl */
+ CARD16 length B16;
CARD32 mask B32;
- CARD8 deviceid;
- CARD8 feedbackid;
+ CARD8 deviceid;
+ CARD8 feedbackid;
BYTE pad1, pad2;
} xChangeFeedbackControlReq;
typedef struct {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class; /* feedback class id */
+ CARD8 c_class; /* feedback class id */
#else
- CARD8 class; /* feedback class id */
+ CARD8 class; /* feedback class id */
#endif
- CARD8 id; /* feedback id */
- CARD16 length B16; /* feedback length */
+ CARD8 id; /* feedback id */
+ CARD16 length B16; /* feedback length */
} xFeedbackCtl;
typedef struct {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class; /* feedback class id */
+ CARD8 c_class; /* feedback class id */
#else
- CARD8 class; /* feedback class id */
+ CARD8 class; /* feedback class id */
#endif
- CARD8 id; /* feedback length */
- CARD16 length B16; /* feedback length */
- KeyCode key;
+ CARD8 id; /* feedback length */
+ CARD16 length B16; /* feedback length */
+ KeyCode key;
CARD8 auto_repeat_mode;
INT8 click;
INT8 percent;
@@ -902,13 +903,13 @@ typedef struct {
typedef struct {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class; /* feedback class id */
+ CARD8 c_class; /* feedback class id */
#else
- CARD8 class; /* feedback class id */
+ CARD8 class; /* feedback class id */
#endif
- CARD8 id; /* feedback id */
- CARD16 length B16; /* feedback length */
- CARD8 pad1,pad2;
+ CARD8 id; /* feedback id */
+ CARD16 length B16; /* feedback length */
+ CARD8 pad1,pad2;
INT16 num B16;
INT16 denom B16;
INT16 thresh B16;
@@ -916,35 +917,35 @@ typedef struct {
typedef struct {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class; /* feedback class id */
+ CARD8 c_class; /* feedback class id */
#else
- CARD8 class; /* feedback class id */
+ CARD8 class; /* feedback class id */
#endif
- CARD8 id; /* feedback id */
- CARD16 length B16; /* feedback length */
+ CARD8 id; /* feedback id */
+ CARD16 length B16; /* feedback length */
INT32 int_to_display B32;
} xIntegerFeedbackCtl;
typedef struct {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class; /* feedback class id */
+ CARD8 c_class; /* feedback class id */
#else
- CARD8 class; /* feedback class id */
+ CARD8 class; /* feedback class id */
#endif
- CARD8 id; /* feedback id */
- CARD16 length B16; /* feedback length */
- CARD8 pad1,pad2;
+ CARD8 id; /* feedback id */
+ CARD16 length B16; /* feedback length */
+ CARD8 pad1,pad2;
CARD16 num_keysyms B16;
} xStringFeedbackCtl;
typedef struct {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class; /* feedback class id */
+ CARD8 c_class; /* feedback class id */
#else
- CARD8 class; /* feedback class id */
+ CARD8 class; /* feedback class id */
#endif
- CARD8 id; /* feedback id */
- CARD16 length B16; /* feedback length */
+ CARD8 id; /* feedback id */
+ CARD16 length B16; /* feedback length */
INT8 percent;
BYTE pad1, pad2, pad3;
INT16 pitch B16;
@@ -953,12 +954,12 @@ typedef struct {
typedef struct {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class; /* feedback class id */
+ CARD8 c_class; /* feedback class id */
#else
- CARD8 class; /* feedback class id */
+ CARD8 class; /* feedback class id */
#endif
- CARD8 id; /* feedback id */
- CARD16 length B16; /* feedback length */
+ CARD8 id; /* feedback id */
+ CARD16 length B16; /* feedback length */
CARD32 led_mask B32;
CARD32 led_values B32;
} xLedFeedbackCtl;
@@ -970,28 +971,28 @@ typedef struct {
*/
typedef struct {
- CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_GetDeviceKeyMapping */
- CARD16 length B16;
- CARD8 deviceid;
- KeyCode firstKeyCode;
- CARD8 count;
+ CARD8 reqType; /* input extension major code */
+ CARD8 ReqType; /* always X_GetDeviceKeyMapping */
+ CARD16 length B16;
+ CARD8 deviceid;
+ KeyCode firstKeyCode;
+ CARD8 count;
BYTE pad1;
} xGetDeviceKeyMappingReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_GetDeviceKeyMapping */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD8 keySymsPerKeyCode;
- CARD8 pad0;
- CARD16 pad1 B16;
- CARD32 pad2 B32;
- CARD32 pad3 B32;
- CARD32 pad4 B32;
- CARD32 pad5 B32;
- CARD32 pad6 B32;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_GetDeviceKeyMapping */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD8 keySymsPerKeyCode;
+ CARD8 pad0;
+ CARD16 pad1 B16;
+ CARD32 pad2 B32;
+ CARD32 pad3 B32;
+ CARD32 pad4 B32;
+ CARD32 pad5 B32;
+ CARD32 pad6 B32;
} xGetDeviceKeyMappingReply;
/*********************************************************
@@ -1001,13 +1002,13 @@ typedef struct {
*/
typedef struct {
- CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_ChangeDeviceKeyMapping */
- CARD16 length B16;
- CARD8 deviceid;
- KeyCode firstKeyCode;
- CARD8 keySymsPerKeyCode;
- CARD8 keyCodes;
+ CARD8 reqType; /* input extension major code */
+ CARD8 ReqType; /* always X_ChangeDeviceKeyMapping */
+ CARD16 length B16;
+ CARD8 deviceid;
+ KeyCode firstKeyCode;
+ CARD8 keySymsPerKeyCode;
+ CARD8 keyCodes;
} xChangeDeviceKeyMappingReq;
/*********************************************************
@@ -1017,26 +1018,26 @@ typedef struct {
*/
typedef struct {
- CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_GetDeviceModifierMapping */
- CARD16 length B16;
- CARD8 deviceid;
+ CARD8 reqType; /* input extension major code */
+ CARD8 ReqType; /* always X_GetDeviceModifierMapping */
+ CARD16 length B16;
+ CARD8 deviceid;
BYTE pad1, pad2, pad3;
} xGetDeviceModifierMappingReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_GetDeviceModifierMapping */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD8 numKeyPerModifier;
- CARD8 pad0;
- CARD16 pad1 B16;
- CARD32 pad2 B32;
- CARD32 pad3 B32;
- CARD32 pad4 B32;
- CARD32 pad5 B32;
- CARD32 pad6 B32;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_GetDeviceModifierMapping */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD8 numKeyPerModifier;
+ CARD8 pad0;
+ CARD16 pad1 B16;
+ CARD32 pad2 B32;
+ CARD32 pad3 B32;
+ CARD32 pad4 B32;
+ CARD32 pad5 B32;
+ CARD32 pad6 B32;
} xGetDeviceModifierMappingReply;
/*********************************************************
@@ -1046,27 +1047,27 @@ typedef struct {
*/
typedef struct {
- CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_SetDeviceModifierMapping */
- CARD16 length B16;
- CARD8 deviceid;
- CARD8 numKeyPerModifier;
- CARD16 pad1 B16;
+ CARD8 reqType; /* input extension major code */
+ CARD8 ReqType; /* always X_SetDeviceModifierMapping */
+ CARD16 length B16;
+ CARD8 deviceid;
+ CARD8 numKeyPerModifier;
+ CARD16 pad1 B16;
} xSetDeviceModifierMappingReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_SetDeviceModifierMapping */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD8 success;
- CARD8 pad0;
- CARD16 pad1 B16;
- CARD32 pad2 B32;
- CARD32 pad3 B32;
- CARD32 pad4 B32;
- CARD32 pad5 B32;
- CARD32 pad6 B32;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_SetDeviceModifierMapping */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD8 success;
+ CARD8 pad0;
+ CARD16 pad1 B16;
+ CARD32 pad2 B32;
+ CARD32 pad3 B32;
+ CARD32 pad4 B32;
+ CARD32 pad5 B32;
+ CARD32 pad6 B32;
} xSetDeviceModifierMappingReply;
/*********************************************************
@@ -1077,24 +1078,24 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* X_GetDeviceButtonMapping */
- CARD16 length B16;
- CARD8 deviceid;
+ CARD8 ReqType; /* X_GetDeviceButtonMapping */
+ CARD16 length B16;
+ CARD8 deviceid;
BYTE pad1, pad2, pad3;
} xGetDeviceButtonMappingReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_GetDeviceButtonMapping */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD8 nElts;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_GetDeviceButtonMapping */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD8 nElts;
BYTE pad1, pad2, pad3;
- CARD32 pad01 B32;
- CARD32 pad02 B32;
- CARD32 pad03 B32;
- CARD32 pad04 B32;
- CARD32 pad05 B32;
+ CARD32 pad01 B32;
+ CARD32 pad02 B32;
+ CARD32 pad03 B32;
+ CARD32 pad04 B32;
+ CARD32 pad05 B32;
} xGetDeviceButtonMappingReply;
/*********************************************************
@@ -1105,26 +1106,26 @@ typedef struct {
typedef struct {
CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* X_SetDeviceButtonMapping */
- CARD16 length B16;
- CARD8 deviceid;
- CARD8 map_length;
+ CARD8 ReqType; /* X_SetDeviceButtonMapping */
+ CARD16 length B16;
+ CARD8 deviceid;
+ CARD8 map_length;
BYTE pad1, pad2;
} xSetDeviceButtonMappingReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_SetDeviceButtonMapping */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD8 status;
- BYTE pad0;
- CARD16 pad1 B16;
- CARD32 pad2 B32;
- CARD32 pad3 B32;
- CARD32 pad4 B32;
- CARD32 pad5 B32;
- CARD32 pad6 B32;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_SetDeviceButtonMapping */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD8 status;
+ BYTE pad0;
+ CARD16 pad1 B16;
+ CARD32 pad2 B32;
+ CARD32 pad3 B32;
+ CARD32 pad4 B32;
+ CARD32 pad5 B32;
+ CARD32 pad6 B32;
} xSetDeviceButtonMappingReply;
/*********************************************************
@@ -1135,59 +1136,59 @@ typedef struct {
typedef struct {
CARD8 reqType;
- CARD8 ReqType; /* always X_QueryDeviceState */
- CARD16 length B16;
- CARD8 deviceid;
+ CARD8 ReqType; /* always X_QueryDeviceState */
+ CARD16 length B16;
+ CARD8 deviceid;
BYTE pad1, pad2, pad3;
} xQueryDeviceStateReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_QueryDeviceState */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD8 num_classes;
- BYTE pad0;
- CARD16 pad1 B16;
- CARD32 pad2 B32;
- CARD32 pad3 B32;
- CARD32 pad4 B32;
- CARD32 pad5 B32;
- CARD32 pad6 B32;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_QueryDeviceState */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD8 num_classes;
+ BYTE pad0;
+ CARD16 pad1 B16;
+ CARD32 pad2 B32;
+ CARD32 pad3 B32;
+ CARD32 pad4 B32;
+ CARD32 pad5 B32;
+ CARD32 pad6 B32;
} xQueryDeviceStateReply;
typedef struct {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class;
+ CARD8 c_class;
#else
- CARD8 class;
+ CARD8 class;
#endif
- CARD8 length;
+ CARD8 length;
CARD8 num_keys;
- BYTE pad1;
- CARD8 keys[32];
+ BYTE pad1;
+ CARD8 keys[32];
} xKeyState;
typedef struct {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class;
+ CARD8 c_class;
#else
- CARD8 class;
+ CARD8 class;
#endif
- CARD8 length;
+ CARD8 length;
CARD8 num_buttons;
- BYTE pad1;
- CARD8 buttons[32];
+ BYTE pad1;
+ CARD8 buttons[32];
} xButtonState;
typedef struct {
#if defined(__cplusplus) || defined(c_plusplus)
- CARD8 c_class;
+ CARD8 c_class;
#else
- CARD8 class;
+ CARD8 class;
#endif
- CARD8 length;
- CARD8 num_valuators;
+ CARD8 length;
+ CARD8 num_valuators;
CARD8 mode;
} xValuatorState;
@@ -1201,11 +1202,11 @@ typedef struct {
typedef struct {
CARD8 reqType;
- CARD8 ReqType; /* always X_SendExtensionEvent */
- CARD16 length B16;
+ CARD8 ReqType; /* always X_SendExtensionEvent */
+ CARD16 length B16;
Window destination B32;
- CARD8 deviceid;
- BOOL propagate;
+ CARD8 deviceid;
+ BOOL propagate;
CARD16 count B16;
CARD8 num_events;
BYTE pad1,pad2,pad3;
@@ -1219,9 +1220,9 @@ typedef struct {
typedef struct {
CARD8 reqType;
- CARD8 ReqType; /* always X_DeviceBell */
- CARD16 length B16;
- CARD8 deviceid;
+ CARD8 ReqType; /* always X_DeviceBell */
+ CARD16 length B16;
+ CARD8 deviceid;
CARD8 feedbackid;
CARD8 feedbackclass;
INT8 percent;
@@ -1234,27 +1235,27 @@ typedef struct {
*/
typedef struct {
- CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_SetDeviceValuators */
- CARD16 length B16;
+ CARD8 reqType; /* input extension major code */
+ CARD8 ReqType; /* always X_SetDeviceValuators */
+ CARD16 length B16;
CARD8 deviceid;
CARD8 first_valuator;
CARD8 num_valuators;
- BYTE pad1;
+ BYTE pad1;
} xSetDeviceValuatorsReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_SetDeviceValuators */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD8 status;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_SetDeviceValuators */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD8 status;
BYTE pad1, pad2, pad3;
- CARD32 pad01 B32;
- CARD32 pad02 B32;
- CARD32 pad03 B32;
- CARD32 pad04 B32;
- CARD32 pad05 B32;
+ CARD32 pad01 B32;
+ CARD32 pad02 B32;
+ CARD32 pad03 B32;
+ CARD32 pad04 B32;
+ CARD32 pad05 B32;
} xSetDeviceValuatorsReply;
/*********************************************************
@@ -1264,37 +1265,37 @@ typedef struct {
*/
typedef struct {
- CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_GetDeviceControl */
- CARD16 length B16;
+ CARD8 reqType; /* input extension major code */
+ CARD8 ReqType; /* always X_GetDeviceControl */
+ CARD16 length B16;
CARD16 control B16;
CARD8 deviceid;
- BYTE pad2;
+ BYTE pad2;
} xGetDeviceControlReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_GetDeviceControl */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD8 status;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_GetDeviceControl */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD8 status;
BYTE pad1, pad2, pad3;
- CARD32 pad01 B32;
- CARD32 pad02 B32;
- CARD32 pad03 B32;
- CARD32 pad04 B32;
- CARD32 pad05 B32;
+ CARD32 pad01 B32;
+ CARD32 pad02 B32;
+ CARD32 pad03 B32;
+ CARD32 pad04 B32;
+ CARD32 pad05 B32;
} xGetDeviceControlReply;
typedef struct {
- CARD16 control B16; /* control type */
- CARD16 length B16; /* control length */
+ CARD16 control B16; /* control type */
+ CARD16 length B16; /* control length */
} xDeviceState;
typedef struct {
- CARD16 control B16; /* control type */
- CARD16 length B16; /* control length */
- CARD32 num_valuators B32; /* number of valuators */
+ CARD16 control B16; /* control type */
+ CARD16 length B16; /* control length */
+ CARD32 num_valuators B32; /* number of valuators */
} xDeviceResolutionState;
typedef struct {
@@ -1344,39 +1345,39 @@ typedef struct {
*/
typedef struct {
- CARD8 reqType; /* input extension major code */
- CARD8 ReqType; /* always X_ChangeDeviceControl */
- CARD16 length B16;
+ CARD8 reqType; /* input extension major code */
+ CARD8 ReqType; /* always X_ChangeDeviceControl */
+ CARD16 length B16;
CARD16 control B16;
CARD8 deviceid;
BYTE pad0;
} xChangeDeviceControlReq;
typedef struct {
- CARD8 repType; /* X_Reply */
- CARD8 RepType; /* always X_ChangeDeviceControl */
- CARD16 sequenceNumber B16;
- CARD32 length B32;
- CARD8 status;
+ CARD8 repType; /* X_Reply */
+ CARD8 RepType; /* always X_ChangeDeviceControl */
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ CARD8 status;
BYTE pad1, pad2, pad3;
- CARD32 pad01 B32;
- CARD32 pad02 B32;
- CARD32 pad03 B32;
- CARD32 pad04 B32;
- CARD32 pad05 B32;
+ CARD32 pad01 B32;
+ CARD32 pad02 B32;
+ CARD32 pad03 B32;
+ CARD32 pad04 B32;
+ CARD32 pad05 B32;
} xChangeDeviceControlReply;
typedef struct {
- CARD16 control B16; /* control type */
- CARD16 length B16; /* control length */
+ CARD16 control B16; /* control type */
+ CARD16 length B16; /* control length */
} xDeviceCtl;
typedef struct {
- CARD16 control B16; /* control type */
- CARD16 length B16; /* control length */
- CARD8 first_valuator; /* first valuator to change */
- CARD8 num_valuators; /* number of valuators to change*/
- CARD8 pad1,pad2;
+ CARD16 control B16; /* control type */
+ CARD16 length B16; /* control length */
+ CARD8 first_valuator; /* first valuator to change */
+ CARD8 num_valuators; /* number of valuators to change*/
+ CARD8 pad1,pad2;
} xDeviceResolutionCtl;
typedef struct {
@@ -1523,6 +1524,7 @@ typedef struct {
CARD32 pad3 B32;
} xGetDevicePropertyReply;
+
/**********************************************************
*
* Input extension events.
@@ -1533,18 +1535,18 @@ typedef struct {
typedef struct
{
- BYTE type;
+ BYTE type;
CARD8 deviceid;
- CARD16 sequenceNumber B16;
+ CARD16 sequenceNumber B16;
KeyButMask device_state B16;
CARD8 num_valuators;
CARD8 first_valuator;
- INT32 valuator0 B32;
- INT32 valuator1 B32;
- INT32 valuator2 B32;
- INT32 valuator3 B32;
- INT32 valuator4 B32;
- INT32 valuator5 B32;
+ INT32 valuator0 B32;
+ INT32 valuator1 B32;
+ INT32 valuator2 B32;
+ INT32 valuator3 B32;
+ INT32 valuator4 B32;
+ INT32 valuator5 B32;
} deviceValuator;
/**********************************************************
@@ -1555,14 +1557,14 @@ typedef struct
* DeviceButtonPress, DeviceButtonRelease,
* ProximityIn, ProximityOut
* DeviceMotionNotify,
- *
+ *
*/
typedef struct
{
- BYTE type;
+ BYTE type;
BYTE detail;
- CARD16 sequenceNumber B16;
+ CARD16 sequenceNumber B16;
Time time B32;
Window root B32;
Window event B32;
@@ -1584,9 +1586,9 @@ typedef struct
typedef struct
{
- BYTE type;
+ BYTE type;
BYTE detail;
- CARD16 sequenceNumber B16;
+ CARD16 sequenceNumber B16;
Time time B32;
Window window B32;
BYTE mode;
@@ -1610,9 +1612,9 @@ typedef struct
typedef struct
{
- BYTE type;
+ BYTE type;
BYTE deviceid;
- CARD16 sequenceNumber B16;
+ CARD16 sequenceNumber B16;
Time time B32;
CARD8 num_keys;
CARD8 num_buttons;
@@ -1633,9 +1635,9 @@ typedef struct
typedef struct
{
- BYTE type;
+ BYTE type;
BYTE deviceid;
- CARD16 sequenceNumber B16;
+ CARD16 sequenceNumber B16;
CARD8 keys[28];
} deviceKeyStateNotify;
@@ -1647,9 +1649,9 @@ typedef struct
typedef struct
{
- BYTE type;
+ BYTE type;
BYTE deviceid;
- CARD16 sequenceNumber B16;
+ CARD16 sequenceNumber B16;
CARD8 buttons[28];
} deviceButtonStateNotify;
@@ -1662,9 +1664,9 @@ typedef struct
typedef struct
{
- BYTE type;
+ BYTE type;
BYTE deviceid;
- CARD16 sequenceNumber B16;
+ CARD16 sequenceNumber B16;
CARD8 request;
KeyCode firstKeyCode;
CARD8 count;
@@ -1685,9 +1687,9 @@ typedef struct
typedef struct
{
- BYTE type;
+ BYTE type;
BYTE deviceid;
- CARD16 sequenceNumber B16;
+ CARD16 sequenceNumber B16;
Time time B32;
CARD8 request;
BYTE pad1, pad2, pad3;
@@ -1706,9 +1708,9 @@ typedef struct
typedef struct
{
- BYTE type;
+ BYTE type;
BYTE pad00;
- CARD16 sequenceNumber B16;
+ CARD16 sequenceNumber B16;
Time time B32;
BYTE devchange; /* Device{Added|Removed|Enabled|Disabled|ControlChanged} */
BYTE deviceid;
@@ -1720,6 +1722,7 @@ typedef struct
CARD32 pad06 B32;
} devicePresenceNotify;
+
/*********************************************************
* DevicePropertyNotifyEvent
*
@@ -1743,10 +1746,11 @@ typedef struct
CARD8 deviceid; /* id of device */
} devicePropertyNotify;
-
#undef Window
#undef Time
#undef KeyCode
+#undef Mask
#undef Atom
+#undef Cursor
#endif
diff --git a/proto/inputproto/XIproto.txt b/proto/inputproto/XIproto.txt
new file mode 100644
index 000000000..20cc02a03
--- /dev/null
+++ b/proto/inputproto/XIproto.txt
@@ -0,0 +1,2542 @@
+ X11 Input Extension Protocol Specification
+ Version 1.0
+ X Consortium Standard
+ X Version 11, Release 6.8
+ Mark Patrick, Ardent Computer
+ George Sachs, Hewlett-Packard
+
+ Version 1.5
+ Peter Hutterer
+
+ Copyright © 1989, 1990, 1991 by Hewlett-Packard Company and
+ Ardent Computer
+
+ Permission to use, copy, modify, and distribute this
+ documentation for any purpose and without fee is hereby
+ granted, provided that the above copyright notice and this
+ permission notice appear in all copies. Ardent and
+ Hewlett-Packard make no representations about the suitability
+ for any purpose of the information in this document. It is
+ provided "as is" without express or implied warranty. Copyright
+ © 1989, 1990, 1991, 1992 X Consortium
+
+ Permission is hereby granted, free of charge, to any person
+ obtaining a copy of this software and associated documentation
+ files (the “Software”), to deal in the Software without
+ restriction, including without limitation the rights to use,
+ copy, modify, merge, publish, distribute, sublicense, and/or
+ sell copies of the Software, and to permit persons to whom the
+ Software is furnished to do so, subject to the following
+ conditions:
+
+ The above copyright notice and this permission notice shall be
+ included in all copies or substantial portions of the Software.
+
+ THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND,
+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE
+ FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+ OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ THE SOFTWARE.
+
+ Except as contained in this notice, the name of the X
+ Consortium shall not be used in advertising or otherwise to
+ promote the sale, use or other dealings in this Software
+ without prior written authorization from the X Consortium. X
+ Window System is a trademark of The Open Group.
+
+ Copyright © 2008 by Peter Hutterer
+
+ Permission is hereby granted, free of charge, to any person
+ obtaining a copy of this software and associated documentation
+ files (the "Software"), to deal in the Software without
+ restriction, including without limitation the rights to use,
+ copy, modify, merge, publish, distribute, sublicense, and/or
+ sell copies of the Software, and to permit persons to whom the
+ Software is furnished to do so, subject to the following
+ conditions:
+
+ The above copyright notice and this permission notice
+ (including the next paragraph) shall be included in all copies
+ or substantial portions of the Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ OTHER DEALINGS IN THE SOFTWARE.
+
+1. Input Extension Overview
+
+ This document defines an extension to the X11 protocol to
+ support input devices other than the core X keyboard and
+ pointer. An accompanying document defines a corresponding
+ extension to Xlib (similar extensions for languages other than
+ C are anticipated). This first section gives an overview of the
+ input extension. The next section defines the new protocol
+ requests defined by the extension. We conclude with a
+ description of the new input events generated by the additional
+ input devices.
+
+ This document only describes the behaviour of servers supporting
+ up to the X Input Extension 1.5. For servers supporting the X
+ Input Extensions 2.0, see XI2proto.txt. New clients are discouraged
+ from using this protocol specification. Instead, the use of XI 2.x
+ is recommended.
+
+1.1 Design Approach
+
+ The design approach of the extension is to define requests and
+ events analogous to the core requests and events. This allows
+ extension input devices to be individually distinguishable from
+ each other and from the core input devices. These requests and
+ events make use of a device identifier and support the
+ reporting of n-dimensional motion data as well as other data
+ that is not reportable via the core input events.
+
+1.2 Core Input Devices
+
+ The X server core protocol supports two input devices: a
+ pointer and a keyboard. The pointer device has two major
+ functions. First, it may be used to generate motion information
+ that client programs can detect. Second, it may also be used to
+ indicate the current location and focus of the X keyboard. To
+ accomplish this, the server echoes a cursor at the current
+ position of the X pointer. Unless the X keyboard has been
+ explicitly focused, this cursor also shows the current location
+ and focus of the X keyboard. The X keyboard is used to generate
+ input that client programs can detect.
+
+ In servers supporting XI 1.4 and above, the core pointer and
+ the core keyboard are virtual devices that do not represent a
+ physical device connected to the host computer.
+ In servers supporting XI 2.0 and above, there may be multiple
+ core pointers and keyboards. Refer to XI2proto.txt for more
+ information.
+
+ The X keyboard and X pointer are referred to in this document
+ as the core devices, and the input events they generate
+ (KeyPress, KeyRelease, ButtonPress, ButtonRelease, and
+ MotionNotify) are known as the core input events. All other
+ input devices are referred to as extension input devices and
+ the input events they generate are referred to as extension
+ input events.
+
+ In servers supporting only XI 1.x, this input extension does
+ not change the behavior or functionality of the core input
+ devices, core events, or core protocol requests, with the
+ exception of the core grab requests. These requests may affect
+ the synchronization of events from extension devices. See the
+ explanation in the section titled "Event Synchronization and
+ Core Grabs".
+
+ Selection of the physical devices to be initially used by the
+ server as the core devices is left implementation-dependent.
+ Requests are defined that allow client programs to change which
+ physical devices are used as the core devices.
+
+1.3 Extension Input Devices
+
+ The input extension v1.x controls access to input devices other
+ than the X keyboard and X pointer. It allows client programs to
+ select input from these devices independently from each other
+ and independently from the core devices.
+
+ A client that wishes to access a specific device must first
+ determine whether that device is connected to the X server.
+ This is done through the ListInputDevices request, which will
+ return a list of all devices that can be opened by the X
+ server. A client can then open one or more of these devices
+ using the OpenDevice request, specify what events they are
+ interested in receiving, and receive and process input events
+ from extension devices in the same way as events from the X
+ keyboard and X pointer. Input events from these devices are of
+ extension types ( DeviceKeyPress, DeviceKeyRelease,
+ DeviceButtonPress, DeviceButtonRelease, DeviceMotionNotify,
+ etc.) and contain a device identifier so that events of the
+ same type coming from different input devices can be
+ distinguished.
+
+ Any kind of input device may be used as an extension input
+ device. Extension input devices may have 0 or more keys, 0 or
+ more buttons, and may report 0 or more axes of motion. Motion
+ may be reported as relative movements from a previous position
+ or as an absolute position. All valuators reporting motion
+ information for a given extension input device must report the
+ same kind of motion information (absolute or relative).
+
+ This extension is designed to accommodate new types of input
+ devices that may be added in the future. The protocol requests
+ that refer to specific characteristics of input devices
+ organize that information by input classes. Server implementors
+ may add new classes of input devices without changing the
+ protocol requests. Input classes are unique numbers registered
+ with the X Consortium. Each extension input device may support
+ multiple input classes.
+
+ In XI 1.x, all extension input devices are treated like the
+ core X keyboard in determining their location and focus. The
+ server does not track the location of these devices on an
+ individual basis, and therefore does not echo a cursor to
+ indicate their current location. Instead, their location is
+ determined by the location of the core X pointer. Like the core
+ X keyboard, some may be explicitly focused. If they are not
+ explicitly focused, their focus is determined by the location
+ of the core X pointer.
+
+ Most input events reported by the server to a client are of
+ fixed size (32 bytes). In order to represent the change in
+ state of an input device the extension may need to generate a
+ sequence of input events. A client side library (such as Xlib)
+ will typically take these raw input events and format them into
+ a form more convenient to the client.
+
+1.4 Event Classes
+
+ In the core protocol a client registers interest in receiving
+ certain input events directed to a window by modifying that
+ window's event-mask. Most of the bits in the event mask are
+ already used to specify interest in core X events. The input
+ extension specifies a different mechanism by which a client can
+ express interest in events generated by this extension.
+
+ When a client opens a extension input device via the OpenDevice
+ request, an XDevice structure is returned. Macros are provided
+ that extract 32-bit numbers called event classes from that
+ structure, that a client can use to register interest in
+ extension events via the SelectExtensionEvent request. The
+ event class combines the desired event type and device id, and
+ may be thought of as the equivalent of core event masks.
+
+1.5 Input Classes
+
+ Some of the input extension requests divide input devices into
+ classes based on their functionality. This is intended to allow
+ new classes of input devices to be defined at a later time
+ without changing the semantics of these requests. The following
+ input device classes are currently defined:
+
+ KEY
+ The device reports key events.
+
+ BUTTON
+ The device reports button events.
+
+ VALUATOR
+ The device reports valuator data in motion events.
+
+ PROXIMITY
+ The device reports proximity events.
+
+ FOCUS
+ The device can be focused and reports focus events.
+
+ FEEDBACK
+ The device supports feedbacks.
+
+ OTHER
+ The ChangeDeviceNotify, DeviceMappingNotify, and
+ DeviceStateNotify macros may be invoked passing the
+ XDevice structure returned for this device.
+
+ Each extension input device may support multiple input classes.
+ Additional classes may be added in the future. Requests that
+ support multiple input classes, such as the ListInputDevices
+ function that lists all available input devices, organize the
+ data they return by input class. Client programs that use these
+ requests should not access data unless it matches a class
+ defined at the time those clients were compiled. In this way,
+ new classes can be added without forcing existing clients that
+ use these requests to be recompiled.
+
+2. Requests
+
+ Extension input devices are accessed by client programs through
+ the use of new protocol requests. This section summarizes the
+ new requests defined by this extension. The syntax and type
+ definitions used below follow the notation used for the X11
+ core protocol.
+
+2.1 Getting the Extension Version
+
+ The GetExtensionVersion request returns version information
+ about the input extension.
+
+ GetExtensionVersion
+ name: STRING
+ =>
+ present: BOOL
+ protocol-major-version: CARD16
+ protocol-minor-version: CARD16
+
+ The protocol version numbers returned indicate the version of
+ the input extension supported by the target X server. The
+ version numbers can be compared to constants defined in the
+ header file XI.h. Each version is a superset of the previous
+ versions.
+
+ The name must be the name of the Input Extension as defined
+ in the header file XI.h.
+
+2.2 Listing Available Devices
+
+ A client that wishes to access a specific device must first
+ determine whether that device is connected to the X server.
+ This is done through the ListInputDevices request, which will
+ return a list of all devices that can be opened by the X
+ server.
+
+ ListInputDevices
+ =>
+ input-devices: ListOfDeviceInfo
+
+ where
+
+ DEVICEINFO:
+ [type: ATOM
+ id: CARD8
+ num_classes: CARD8
+ use: {IsXKeyboard, IsXPointer, IsXExtensionPointer,
+ IsXExtensionKeyboard, IsExtensionDevice}
+ info: LISTofINPUTINFO
+ name: STRING8]
+
+ INPUTINFO: {KEYINFO, BUTTONINFO, VALUATORINFO}
+ KEYINFO:
+ [class: CARD8
+ length: CARD8
+ min-keycode: KEYCODE
+ max-keycode: KEYCODE
+ num-keys: CARD16]
+ BUTTONINFO:
+ [class: CARD8
+ length: CARD8
+ num-buttons: CARD16]
+ VALUATORINFO:
+ [class: CARD8
+ length: CARD8
+ num_axes: CARD8
+ mode: SETofDEVICEMODE
+ motion_buffer_size: CARD32
+ axes: LISTofAXISINFO]
+
+ AXISINFO:
+ [resolution: CARD32
+ min-val: CARD32
+ max-val: CARD32]
+ DEVICEMODE: {Absolute, Relative}
+
+ Errors: None
+
+ This request returns a list of all devices that can be opened
+ by the X server, including the core X keyboard and X pointer.
+ Some implementations may open all input devices as part of X
+ initialization, while others may not open an input device until
+ requested to do so by a client program.
+
+ The information returned for each device is as follows:
+
+ type
+ The type field is of type Atom and indicates the nature
+ of the device. Clients may determine device types by
+ invoking the XInternAtom request passing one of the
+ names defined in the header file XI.h. The following
+ names have been defined to date:
+
+ MOUSE
+ TABLET
+ KEYBOARD
+ TOUCHSCREEN
+ TOUCHPAD
+ BUTTONBOX
+ BARCODE
+ KNOB_BOX
+ TRACKBALL
+ QUADRATURE
+ SPACEBALL
+ DATAGLOVE
+ EYETRACKER
+ CURSORKEYS
+ FOOTMOUSE
+ ID_MODULE
+ ONE_KNOB
+ NINE_KNOB
+ JOYSTICK
+
+
+ id
+ The id is a small cardinal value in the range 0-128 that
+ uniquely identifies the device. It is assigned to the
+ device when it is initialized by the server. Some
+ implementations may not open an input device until
+ requested by a client program, and may close the device
+ when the last client accessing it requests that it be
+ closed. If a device is opened by a client program via
+ XOpenDevice, then closed via XCloseDevice, then opened
+ again, it is not guaranteed to have the same id after
+ the second open request.
+
+ num_classes
+ The num_classes field is a small cardinal value in the
+ range 0-255 that specifies the number of input classes
+ supported by the device for which information is
+ returned by ListInputDevices. Some input classes, such
+ as class Focus and class Proximity do not have any
+ information to be returned by ListInputDevices.
+
+ use
+ The use field specifies how the device is currently
+ being used. If the value is IsXKeyboard, the device is
+ currently being used as the X keyboard. If the value is
+ IsXPointer, the device is currently being used as the X
+ pointer. If the value is IsXExtensionPointer, the device
+ is available for use as an extension pointer. If the value
+ is IsXExtensionKeyboard, the device is available for use as
+ and extension keyboard.
+ Older versions of XI report all extension devices as
+ IsXExtensionDevice.
+
+ name
+ The name field contains a pointer to a null-terminated
+ string that corresponds to one of the defined device
+ types.
+
+ InputInfo
+ InputInfo is one of: KeyInfo, ButtonInfo or
+ ValuatorInfo. The first two fields are common to all
+ three:
+
+ class
+ The class field is a cardinal value in the range
+ 0-255. It uniquely identifies the class of input
+ for which information is returned.
+
+ length
+ The length field is a cardinal value in the range
+ 0-255. It specifies the number of bytes of data
+ that are contained in this input class. The length
+ includes the class and length fields.
+
+ The remaining information returned for input class
+ KEYCLASS is as follows:
+
+ min_keycode
+ min_keycode is of type KEYCODE. It specifies the
+ minimum keycode that the device will report. The
+ minimum keycode will not be smaller than 8.
+
+ max_keycode
+ max_keycode is of type KEYCODE. It specifies the
+ maximum keycode that the device will report. The
+ maximum keycode will not be larger than 255.
+
+ num_keys
+ num_keys is a cardinal value that specifies the
+ number of keys that the device has.
+
+ The remaining information returned for input class
+ BUTTONCLASS is as follows:
+
+ num_buttons
+ num_buttons is a cardinal value that specifies the
+ number of buttons that the device has.
+
+ The remaining information returned for input class
+ VALUATORCLASS is as follows:
+
+ mode
+ mode is a constant that has one of the following
+ values: Absolute or Relative. Some devices allow
+ the mode to be changed dynamically via the
+ SetDeviceMode request.
+
+ motion_buffer_size
+ motion_buffer_size is a cardinal number that
+ specifies the number of elements that can be
+ contained in the motion history buffer for the
+ device.
+
+ axes
+ The axes field contains a pointer to an AXISINFO
+ struture.
+
+ The information returned for each axis reported by the
+ device is:
+
+ resolution
+ The resolution is a cardinal value in
+ counts/meter.
+
+ min_val
+ The min_val field is a cardinal value in that
+ contains the minimum value the device reports for
+ this axis. For devices whose mode is Relative, the
+ min_val field will contain 0.
+
+ max_val
+ The max_val field is a cardinal value in that
+ contains the maximum value the device reports for
+ this axis. For devices whose mode is Relative, the
+ max_val field will contain 0.
+
+2.3 Enabling Devices
+
+ Client programs that wish to access an extension device must
+ request that the server open that device. This is done via the
+ OpenDevice request.
+
+ OpenDevice
+ id: CARD8
+ =>
+ DEVICE:
+ [device_id: XID
+ num_classes: INT32
+ classes: LISTofINPUTCLASSINFO]
+ INPUTCLASSINFO:
+ [input_class: CARD8
+ event_type_base: CARD8]
+
+ Errors: Device
+
+ This request returns the event classes to be used by the client
+ to indicate which events the client program wishes to receive.
+ Each input class may report several event classes. For example,
+ input class Keys reports DeviceKeyPress and DeviceKeyRelease
+ event classes. Input classes are unique numbers registered with
+ the X Consortium. Input class Other exists to report event
+ classes that are not specific to any one input class, such as
+ DeviceMappingNotify, ChangeDeviceNotify, and DeviceStateNotify.
+
+ The information returned for each device is as follows:
+
+ device_id
+ The device_id is a number that uniquely identifies the
+ device.
+
+ num_classes
+ The num_classes field contains the number of input
+ classes supported by this device.
+
+ For each class of input supported by the device, the
+ InputClassInfo structure contains the following information:
+
+ input_class
+ The input_class is a small cardinal number that
+ identifies the class of input.
+
+ event_type_base
+ The event_type_base is a small cardinal number that
+ specifies the event type of one of the events reported
+ by this input class. This information is not directly
+ used by client programs. Instead, the Device is used by
+ macros that return extension event types and event
+ classes. This is described in the section of this
+ document entitled "Selecting Extension Device Events".
+
+ The information in the InputClassInfo reflects the state of
+ this device at the time the request was processed.
+
+ Before it exits, the client program should explicitly request
+ that the server close the device. This is done via the
+ CloseDevice request.
+
+ A client may open the same extension device more than once.
+ Requests after the first successful one return an additional
+ XDevice structure with the same information as the first, but
+ otherwise have no effect. A single CloseDevice request will
+ terminate that client's access to the device.
+
+ Closing a device releases any active or passive grabs the
+ requesting client has established. If the device is frozen only
+ by an active grab of the requesting client, the queued events
+ are released when the client terminates.
+
+ If a client program terminates without closing a device, the
+ server will automatically close that device on behalf of the
+ client. This does not affect any other clients that may be
+ accessing that device.
+
+ CloseDevice:
+ device: DEVICE
+
+ Errors: Device
+
+2.4 Changing The Mode Of A Device
+
+ Some devices are capable of reporting either relative or
+ absolute motion data. To change the mode of a device from
+ relative to absolute, use the SetDeviceMode request. The valid
+ values are Absolute or Relative.
+
+ This request will fail and return DeviceBusy if another client
+ already has the device open with a different mode. It will fail
+ and return AlreadyGrabbed if another client has the device
+ grabbed. The request will fail with a BadMatch error if the
+ requested mode is not supported by the device.
+
+ SetDeviceMode
+ device:DEVICE
+ mode: {Absolute, Relative}
+ =>
+ status: {Success, DeviceBusy, AlreadyGrabbed}
+
+ Errors: Device, Match, Mode
+
+2.5 Initializing Valuators on an Input Device
+
+ Some devices that report absolute positional data can be
+ initialized to a starting value. Devices that are capable of
+ reporting relative motion or absolute positional data may
+ require that their valuators be initialized to a starting value
+ after the mode of the device is changed to Absolute. To
+ initialize the valuators on such a device, use the
+ SetDeviceValuators request.
+
+ SetDeviceValuators
+ device: DEVICE
+ first_valuator: CARD8
+ num_valuators: CARD8
+ valuators: LISTOFINT32
+ =>
+ status: {Success, AlreadyGrabbed}
+
+ Errors: Length, Device, Match, Value
+
+ This request initializes the specified valuators on the
+ specified extension input device. Valuators are numbered
+ beginning with zero. Only the valuators in the range specified
+ by first_valuator and num_valuators are set. If the number of
+ valuators supported by the device is less than the expression
+ first_valuator + num_valuators, a Value error will result.
+
+ If the request succeeds, Success is returned. If the specifed
+ device is grabbed by some other client, the request will fail
+ and a status of AlreadyGrabbed will be returned.
+
+2.6 Getting Input Device Controls
+
+ GetDeviceControl
+ device: DEVICE
+ control: XID
+ =>
+ controlState: {DeviceState}
+
+ where
+
+ DeviceState: DeviceResolutionState
+
+ Errors: Length, Device, Match, Value
+
+ This request returns the current state of the specified device
+ control. The device control must be supported by the target
+ server and device or an error will result.
+
+ If the request is successful, a pointer to a generic
+ DeviceState structure will be returned. The information
+ returned varies according to the specified control and is
+ mapped by a structure appropriate for that control.
+
+ GetDeviceControl will fail with a BadValue error if the server
+ does not support the specified control. It will fail with a
+ BadMatch error if the device does not support the specified
+ control.
+
+ Supported device controls and the information returned for them
+ include:
+
+ DEVICE_RESOLUTION:
+ [control: CARD16
+ length: CARD16
+ num_valuators: CARD8
+ resolutions: LISTofCARD32
+ min_resolutions: LISTofCARD32
+ max_resolutions: LISTofCARD32]
+
+ This device control returns a list of valuators and the range
+ of valid resolutions allowed for each. Valuators are numbered
+ beginning with 0. Resolutions for all valuators on the device
+ are returned. For each valuator i on the device, resolutions[i]
+ returns the current setting of the resolution,
+ min_resolutions[i] returns the minimum valid setting, and
+ max_resolutions[i] returns the maximum valid setting.
+
+ When this control is specified, XGetDeviceControl will fail
+ with a BadMatch error if the specified device has no valuators.
+
+ ChangeDeviceControl:
+ device: DEVICE
+ XID: controlId
+ control: DeviceControl
+
+ where
+
+ DeviceControl: DeviceResolutionControl
+ =>
+ status: {Success, DeviceBusy, AlreadyGrabbed}
+
+ Errors: Length, Device, Match, Value
+
+ ChangeDeviceControl changes the specifed device control
+ according to the values specified in the DeviceControl
+ structure. The device control must be supported by the target
+ server and device or an error will result.
+
+ The information passed with this request varies according to
+ the specified control and is mapped by a structure appropriate
+ for that control.
+
+ ChangeDeviceControl will fail with a BadValue error if the
+ server does not support the specified control. It will fail
+ with a BadMatch error if the server supports the specified
+ control, but the requested device does not. The request will
+ fail and return a status of DeviceBusy if another client
+ already has the device open with a device control state that
+ conflicts with the one specified in the request. It will fail
+ with a status of AlreadyGrabbed if some other client has
+ grabbed the specified device. If the request succeeds, Success
+ is returned. If it fails, the device control is left unchanged.
+
+ Supported device controls and the information specified for
+ them include:
+
+ DEVICE_RESOLUTION:
+ [control: CARD16
+ length: CARD16
+ first_valuator: CARD8
+ num_valuators: CARD8
+ resolutions: LISTofCARD32]
+
+ This device control changes the resolution of the specified
+ valuators on the specified extension input device. Valuators
+ are numbered beginning with zero. Only the valuators in the
+ range specified by first_valuator and num_valuators are set. A
+ value of -1 in the resolutions list indicates that the
+ resolution for this valuator is not to be changed.
+ num_valuators specifies the number of valuators in the
+ resolutions list.
+
+ When this control is specified, XChangeDeviceControl will fail
+ with a BadMatch error if the specified device has no valuators.
+ If a resolution is specified that is not within the range of
+ valid values (as returned by XGetDeviceControl) the request
+ will fail with a BadValue error. If the number of valuators
+ supported by the device is less than the expression
+ first_valuator + num_valuators, a BadValue error will result.
+
+ If the request fails for any reason, none of the valuator
+ resolutions will be changed.
+
+ ChangeDeviceControl causes the server to send a DevicePresence
+ event to interested clients.
+
+2.7 Selecting Extension Device Events
+
+ Extension input events are selected using the
+ SelectExtensionEvent request.
+
+ SelectExtensionEvent
+ interest: LISTofEVENTCLASS
+ window: WINDOW
+
+ Errors: Window, Class, Access
+
+ This request specifies to the server the events within the
+ specified window which are of interest to the client. As with
+ the core XSelectInput function, multiple clients can select
+ input on the same window.
+
+ XSelectExtensionEvent requires a list of event classes. An
+ event class is a 32-bit number that combines an event type and
+ device id, and is used to indicate which event a client wishes
+ to receive and from which device it wishes to receive it.
+ Macros are provided to obtain event classes from the data
+ returned by the XOpenDevice request. The names of these macros
+ correspond to the desired events, i.e. the DeviceKeyPress is
+ used to obtain the event class for DeviceKeyPress events. The
+ syntax of the macro invocation is:
+ DeviceKeyPress (device, event_type, event_class);
+ device: DEVICE
+ event_type: INT
+ event_class: INT
+
+ The value returned in event_type is the value that will be
+ contained in the event type field of the XDeviceKeyPressEvent
+ when it is received by the client. The value returned in
+ event_class is the value that should be passed in making an
+ XSelectExtensionEvent request to receive DeviceKeyPress events.
+
+ For DeviceButtonPress events, the client may specify whether or
+ not an implicit passive grab should be done when the button is
+ pressed. If the client wants to guarantee that it will receive
+ a DeviceButtonRelease event for each DeviceButtonPress event it
+ receives, it should specify the DeviceButtonPressGrab event
+ class as well as the DeviceButtonPress event class. This
+ restricts the client in that only one client at a time may
+ request DeviceButtonPress events from the same device and
+ window if any client specifies this class.
+
+ If any client has specified the DeviceButtonPressGrab class,
+ any requests by any other client that specify the same device
+ and window and specify DeviceButtonPress or
+ DeviceButtonPressGrab will cause an Access error to be
+ generated.
+
+ If only the DeviceButtonPress class is specified, no implicit
+ passive grab will be done when a button is pressed on the
+ device. Multiple clients may use this class to specify the same
+ device and window combination.
+
+ A client may also specify the DeviceOwnerGrabButton class. If
+ it has specified both the DeviceButtonPressGrab and the
+ DeviceOwnerGrabButton classes, implicit passive grabs will
+ activate with owner_events set to True. If only the
+ DeviceButtonPressGrab class is specified, implicit passive
+ grabs will activate with owner_events set to False.
+
+ The client may select DeviceMotion events only when a button is
+ down. It does this by specifying the event classes
+ Button1Motion through Button5Motion, or ButtonMotion. An input
+ device will only support as many button motion classes as it
+ has buttons.
+
+2.8 Determining Selected Events
+
+ To determine which extension events are currently selected from
+ a given window, use GetSelectedExtensionEvents.
+
+ GetSelectedExtensionEvents
+ window: WINDOW
+ =>
+ this-client: LISTofEVENTCLASS
+ all-clients: LISTofEVENTCLASS
+
+ Errors: Window
+
+ This request returns two lists specifying the events selected
+ on the specified window. One list gives the extension events
+ selected by this client from the specified window. The other
+ list gives the extension events selected by all clients from
+ the specified window. This information is equivalent to that
+ returned by your-event-mask and all-event-masks in a
+ GetWindowAttributes request.
+
+2.9 Controlling Event Propagation
+
+ Extension events propagate up the window hierarchy in the same
+ manner as core events. If a window is not interested in an
+ extension event, it usually propagates to the closest ancestor
+ that is interested, unless the dont_propagate list prohibits
+ it. Grabs of extension devices may alter the set of windows
+ that receive a particular extension event.
+
+ Client programs may control extension event propagation through
+ the use of the following two requests.
+
+ XChangeDeviceDontPropagateList adds an event to or deletes an
+ event from the do_not_propagate list of extension events for
+ the specified window. This list is maintained for the life of
+ the window, and is not altered if the client terminates.
+
+ ChangeDeviceDontPropagateList
+ window: WINDOW
+ eventclass: LISTofEVENTCLASS
+ mode: {AddToList, DeleteFromList}
+
+ Errors: Window, Class, Mode
+
+ This function modifies the list specifying the events that are
+ not propagated to the ancestors of the specified window. You
+ may use the modes AddToList or DeleteFromList.
+
+ GetDeviceDontPropagateList
+ window: WINDOW
+ Errors: Window
+ =>
+ dont-propagate-list: LISTofEVENTCLASS
+
+ This function returns a list specifying the events that are not
+ propagated to the ancestors of the specified window.
+
+2.10 Sending Extension Events
+
+ One client program may send an event to another via the
+ XSendExtensionEvent function.
+
+ The event in the XEvent structure must be one of the events
+ defined by the input extension, so that the X server can
+ correctly byte swap the contents as necessary. The contents of
+ the event are otherwise unaltered and unchecked by the X server
+ except to force send_event to True in the forwarded event and
+ to set the sequence number in the event correctly.
+
+ XSendExtensionEvent returns zero if the conversion-to-wire
+ protocol failed, otherwise it returns nonzero.
+
+ SendExtensionEvent
+ device: DEVICE
+ destination: WINDOW
+ propagate: BOOL
+ eventclass: LISTofEVENTCLASS
+ event: XEVENT
+
+ Errors: Device, Value, Class, Window
+
+2.11 Getting Motion History
+
+ GetDeviceMotionEvents
+ device: DEVICE
+ start, stop: TIMESTAMP or CurrentTime
+ =>
+ nevents_return: CARD32
+ mode_return: {Absolute, Relative}
+ axis_count_return: CARD8
+ events: LISTofDEVICETIMECOORD
+
+ where
+
+ DEVICETIMECOORD:
+ [data: LISTofINT32
+ time: TIMESTAMP]
+
+ Errors: Device, Match
+
+ This request returns all positions in the device's motion
+ history buffer that fall between the specified start and stop
+ times inclusive. If the start time is in the future, or is
+ later than the stop time, no positions are returned.
+
+ The data field of the DEVICETIMECOORD structure is a sequence
+ of data items. Each item is of type INT32, and there is one
+ data item per axis of motion reported by the device. The number
+ of axes reported by the device is returned in the axis_count
+ variable.
+
+ The value of the data items depends on the mode of the device,
+ which is returned in the mode variable. If the mode is
+ Absolute, the data items are the raw values generated by the
+ device. These may be scaled by the client program using the
+ maximum values that the device can generate for each axis of
+ motion that it reports. The maximum and minimum values for each
+ axis are reported by the ListInputDevices request.
+
+ If the mode is Relative, the data items are the relative values
+ generated by the device. The client program must choose an
+ initial position for the device and maintain a current position
+ by accumulating these relative values.
+
+2.12 Changing The Core Devices
+
+ These requests are provided to change which physical device is
+ used as the X pointer or X keyboard. These requests are
+ deprecated in servers supporting XI 1.4 and above, and will
+ always return a a BadDevice error.
+
+ Using these requests may change the characteristics of the core
+ devices. The new pointer device may have a different number of
+ buttons than the old one did, or the new keyboard device may
+ have a different number of keys or report a different range of
+ keycodes. Client programs may be running that depend on those
+ characteristics. For example, a client program could allocate
+ an array based on the number of buttons on the pointer device,
+ and then use the button numbers received in button events as
+ indicies into that array. Changing the core devices could cause
+ such client programs to behave improperly or abnormally
+ terminate.
+
+ These requests change the X keyboard or X pointer device and
+ generate an ChangeDeviceNotify event and a MappingNotify event.
+ The ChangeDeviceNotify event is sent only to those clients that
+ have expressed an interest in receiving that event via the
+ XSelectExtensionEvent request. The specified device becomes the
+ new X keyboard or X pointer device. The location of the core
+ device does not change as a result of this request.
+
+ These requests fail and return AlreadyGrabbed if either the
+ specified device or the core device it would replace are
+ grabbed by some other client. They fail and return GrabFrozen
+ if either device is frozen by the active grab of another
+ client.
+
+ These requests fail with a BadDevice error if the specified
+ device is invalid, or has not previously been opened via
+ OpenDevice. To change the X keyboard device, use the
+ ChangeKeyboardDevice request. The specified device must support
+ input class Keys (as reported in the ListInputDevices request)
+ or the request will fail with a BadMatch error. Once the device
+ has successfully replaced one of the core devices, it is
+ treated as a core device until it is in turn replaced by
+ another ChangeDevice request, or until the server terminates.
+ The termination of the client that changed the device will not
+ cause it to change back. Attempts to use the CloseDevice
+ request to close the new core device will fail with a BadDevice
+ error.
+
+ The focus state of the new keyboard is the same as the focus
+ state of the old X keyboard. If the new keyboard was not
+ initialized with a FocusRec, one is added by the
+ ChangeKeyboardDevice request. The X keyboard is assumed to have
+ a KbdFeedbackClassRec. If the device was initialized without a
+ KbdFeedbackClassRec, one will be added by this request. The
+ KbdFeedbackClassRec will specify a null routine as the control
+ procedure and the bell procedure.
+
+ ChangeKeyboardDevice
+ device: DEVICE
+ Errors: Device, Match
+ =>
+ status: Success, AlreadyGrabbed, Frozen
+
+ To change the X pointer device, use the ChangePointerDevice
+ request. The specified device must support input class
+ Valuators (as reported in the ListInputDevices request) or the
+ request will fail with a BadMatch error. The valuators to be
+ used as the x- and y-axes of the pointer device must be
+ specified. Data from other valuators on the device will be
+ ignored.
+
+ The X pointer device does not contain a FocusRec. If the new
+ pointer was initialized with a FocusRec, it is freed by the
+ ChangePointerDevice request. The X pointer is assumed to have a
+ ButtonClassRec and a PtrFeedbackClassRec. If the device was
+ initialized without a ButtonClassRec or a PtrFeedbackClassRec,
+ one will be added by this request. The ButtonClassRec added
+ will have no buttons, and the PtrFeedbackClassRec will specify
+ a null routine as the control procedure.
+
+ If the specified device reports absolute positional
+ information, and the server implementation does not allow such
+ a device to be used as the X pointer, the request will fail
+ with a BadDevice error.
+
+ Once the device has successfully replaced one of the core
+ devices, it is treated as a core device until it is in turn
+ replaced by another ChangeDevice request, or until the server
+ terminates. The termination of the client that changed the
+ device will not cause it to change back. Attempts to use the
+ CloseDevice request to close the new core device will fail with
+ a BadDevice error.
+
+ ChangePointerDevice
+ device: DEVICE
+ xaxis: CARD8
+ yaxis: CARD8
+ =>
+ status: Success, AlreadyGrabbed, Frozen
+
+ Errors: Device, Match
+
+2.12 Event Synchronization And Core Grabs
+
+ Implementation of the input extension requires an extension of
+ the meaning of event synchronization for the core grab
+ requests. This is necessary in order to allow window managers
+ to freeze all input devices with a single request.
+
+ The core grab requests require a pointer_mode and keyboard_mode
+ argument. The meaning of these modes is changed by the input
+ extension. For the XGrabPointer and XGrabButton requests,
+ pointer_mode controls synchronization of the pointer device,
+ and keyboard_mode controls the synchronization of all other
+ input devices. For the XGrabKeyboard and XGrabKey requests,
+ pointer_mode controls the synchronization of all input devices
+ except the X keyboard, while keyboard_mode controls the
+ synchronization of the keyboard. When using one of the core
+ grab requests, the synchronization of extension devices is
+ controlled by the mode specified for the device not being
+ grabbed.
+
+2.13 Extension Active Grabs
+
+ Active grabs of extension devices are supported via the
+ GrabDevice request in the same way that core devices are
+ grabbed using the core GrabKeyboard request, except that a
+ Device is passed as a function parameter. A list of events that
+ the client wishes to receive is also passed. The UngrabDevice
+ request allows a previous active grab for an extension device
+ to be released.
+
+ To grab an extension device, use the GrabDevice request. The
+ device must have previously been opened using the OpenDevice
+ request.
+
+ GrabDevice
+ device: DEVICE
+ grab-window: WINDOW
+ owner-events: BOOL
+ event-list: LISTofEVENTCLASS
+ this-device-mode: {Synchronous, Asynchronous}
+ other-device-mode: {Synchronous, Asynchronous}
+ time:TIMESTAMP or CurrentTime
+ =>
+ status: Success, AlreadyGrabbed, Frozen,
+ InvalidTime, NotViewable
+
+ Errors: Device, Window, Value
+
+ This request actively grabs control of the specified input
+ device. Further input events from this device are reported only
+ to the grabbing client. This request overrides any previous
+ active grab by this client for this device.
+
+ The event-list parameter is a pointer to a list of event
+ classes. These are used to indicate which events the client
+ wishes to receive while the device is grabbed. Only event
+ classes obtained from the grabbed device are valid.
+
+ If owner-events is False, input events generated from this
+ device are reported with respect to grab-window, and are only
+ reported if selected by being included in the event-list. If
+ owner-events is True, then if a generated event would normally
+ be reported to this client, it is reported normally, otherwise
+ the event is reported with respect to the grab-window, and is
+ only reported if selected by being included in the event-list.
+ For either value of owner-events, unreported events are
+ discarded.
+
+ If this-device-mode is Asynchronous, device event processing
+ continues normally. If the device is currently frozen by this
+ client, then processing of device events is resumed. If
+ this-device-mode is Synchronous, the state of the grabbed
+ device (as seen by means of the protocol) appears to freeze,
+ and no further device events are generated by the server until
+ the grabbing client issues a releasing AllowDeviceEvents
+ request or until the device grab is released. Actual device
+ input events are not lost while the device is frozen; they are
+ simply queued for later processing.
+
+ If other-device-mode is Asynchronous, event processing is
+ unaffected by activation of the grab. If other-device-mode is
+ Synchronous, the state of all input devices except the grabbed
+ one (as seen by means of the protocol) appears to freeze, and
+ no further events are generated by the server until the
+ grabbing client issues a releasing AllowDeviceEvents request or
+ until the device grab is released. Actual events are not lost
+ while the devices are frozen; they are simply queued for later
+ processing.
+
+ This request generates DeviceFocusIn and DeviceFocusOut events.
+
+ This request fails and returns:
+
+ AlreadyGrabbed
+ If the device is actively grabbed by some other client.
+
+ NotViewable
+ If grab-window is not viewable.
+
+ InvalidTime
+ If the specified time is earlier than the last-grab-time
+ for the specified device or later than the current X
+ server time. Otherwise, the last-grab-time for the
+ specified device is set to the specified time and
+ CurrentTime is replaced by the current X server time.
+
+ Frozen
+ If the device is frozen by an active grab of another
+ client.
+
+ If a grabbed device is closed by a client while an active grab
+ by that client is in effect, that active grab will be released.
+ Any passive grabs established by that client will be released.
+ If the device is frozen only by an active grab of the
+ requesting client, it is thawed.
+
+ To release a grab of an extension device, use UngrabDevice.
+
+ UngrabDevice
+ device: DEVICE
+ time: TIMESTAMP or CurrentTime
+
+ Errors: Device
+
+ This request releases the device if this client has it actively
+ grabbed (from either GrabDevice or GrabDeviceKey) and releases
+ any queued events. If any devices were frozen by the grab,
+ UngrabDevice thaws them. The request has no effect if the
+ specified time is earlier than the last-device-grab time or is
+ later than the current server time.
+
+ This request generates DeviceFocusIn and DeviceFocusOut events.
+
+ An UngrabDevice is performed automatically if the event window
+ for an active device grab becomes not viewable.
+
+2.14 Passively Grabbing A Key
+
+ Passive grabs of buttons and keys on extension devices are
+ supported via the GrabDeviceButton and GrabDeviceKey requests.
+ These passive grabs are released via the UngrabDeviceKey and
+ UngrabDeviceButton requests.
+
+ To passively grab a single key on an extension device, use
+ GrabDeviceKey. That device must have previously been opened
+ using the OpenDevice request.
+
+ GrabDeviceKey
+ device: DEVICE
+ keycode: KEYCODE or AnyKey
+ modifiers: SETofKEYMASK or AnyModifier
+ modifier-device: DEVICE or NULL
+ grab-window: WINDOW
+ owner-events: BOOL
+ event-list: LISTofEVENTCLASS
+ this-device-mode: {Synchronous, Asynchronous}
+ other-device-mode: {Synchronous, Asynchronous}
+
+ Errors: Device, Match, Access, Window, Value
+
+ This request is analogous to the core GrabKey request. It
+ establishes a passive grab on a device. Consequently, in the
+ future:
+ * IF the device is not grabbed and the specified key, which
+ itself can be a modifier key, is logically pressed when the
+ specified modifier keys logically are down on the specified
+ modifier device (and no other keys are down),
+ * AND no other modifier keys logically are down,
+ * AND EITHER the grab window is an ancestor of (or is) the
+ focus window OR the grab window is a descendent of the
+ focus window and contains the pointer,
+ * AND a passive grab on the same device and key combination
+ does not exist on any ancestor of the grab window,
+ * THEN the device is actively grabbed, as for GrabDevice, the
+ last-device-grab time is set to the time at which the key
+ was pressed (as transmitted in the DeviceKeyPress event),
+ and the DeviceKeyPress event is reported.
+
+ The interpretation of the remaining arguments is as for
+ GrabDevice. The active grab is terminated automatically when
+ logical state of the device has the specified key released
+ (independent of the logical state of the modifier keys).
+
+ Note that the logical state of a device (as seen by means of
+ the X protocol) may lag the physical state if device event
+ processing is frozen.
+
+ A modifier of AnyModifier is equivalent to issuing the request
+ for all possible modifier combinations (including the
+ combination of no modifiers). It is not required that all
+ modifiers specified have currently assigned keycodes. A key of
+ AnyKey is equivalent to issuing the request for all possible
+ keycodes. Otherwise, the key must be in the range specified by
+ min-keycode and max-keycode in the ListInputDevices request. If
+ it is not within that range, GrabDeviceKey generates a Value
+ error.
+
+ NULL may be passed for the modifier_device. If the
+ modifier_device is NULL, the core X keyboard is used as the
+ modifier_device.
+
+ An Access error is generated if some other client has issued a
+ GrabDeviceKey with the same device and key combination on the
+ same window. When using AnyModifier or AnyKey, the request
+ fails completely and the X server generates a Access error and
+ no grabs are established if there is a conflicting grab for any
+ combination.
+
+ This request cannot be used to grab a key on the X keyboard
+ device. The core GrabKey request should be used for that
+ purpose.
+
+ To release a passive grab of a single key on an extension
+ device, use UngrabDeviceKey.
+
+ UngrabDeviceKey
+ device: DEVICE
+ keycode: KEYCODE or AnyKey
+ modifiers: SETofKEYMASK or AnyModifier
+ modifier-device: DEVICE or NULL
+ grab-window: WINDOW
+
+ Errors: Device, Match, Window, Value, Alloc
+
+ This request is analogous to the core UngrabKey request. It
+ releases the key combination on the specified window if it was
+ grabbed by this client. A modifier of AnyModifier is equivalent
+ to issuing the request for all possible modifier combinations
+ (including the combination of no modifiers). A key of AnyKey is
+ equivalent to issuing the request for all possible keycodes.
+ This request has no effect on an active grab.
+
+ NULL may be passed for the modifier_device. If the
+ modifier_device is NULL, the core X keyboard is used as the
+ modifier_device.
+
+2.15 Passively Grabbing A Button
+
+ To establish a passive grab for a single button on an extension
+ device, use GrabDeviceButton.
+
+ GrabDeviceButton
+ device: DEVICE
+ button: BUTTON or AnyButton
+ modifiers: SETofKEYMASK or AnyModifier
+ modifier-device: DEVICE or NULL
+ grab-window: WINDOW
+ owner-events: BOOL
+ event-list: LISTofEVENTCLASS
+ this-device-mode: {Synchronous, Asynchr
+ onous}
+ other-device-mode: {Synchronous, Asynch
+ ronous}
+
+ Errors: Device, Match, Window, Access, Value
+
+ This request is analogous to the core GrabButton request. It
+ establishes an explicit passive grab for a button on an
+ extension input device. Since the server does not track
+ extension devices, no cursor is specified with this request.
+ For the same reason, there is no confine-to parameter. The
+ device must have previously been opened using the OpenDevice
+ request.
+
+ The GrabDeviceButton request establishes a passive grab on a
+ device. Consequently, in the future,
+
+ •
+ IF the device is not grabbed and the specified button is
+ logically pressed when the specified modifier keys
+ logically are down (and no other buttons or modifier
+ keys are down),
+
+ •
+ AND the grab window contains the device,
+
+ •
+ AND a passive grab on the same device and button/ key
+ combination does not exist on any ancestor of the grab
+ window,
+
+ •
+ THEN the device is actively grabbed, as for GrabDevice,
+ the last-grab time is set to the time at which the
+ button was pressed (as transmitted in the
+ DeviceButtonPress event), and the DeviceButtonPress
+ event is reported.
+
+ The interpretation of the remaining arguments is as for
+ GrabDevice. The active grab is terminated automatically when
+ logical state of the device has all buttons released
+ (independent of the logical state of the modifier keys).
+
+ Note that the logical state of a device (as seen by means of
+ the X protocol) may lag the physical state if device event
+ processing is frozen.
+
+ A modifier of AnyModifier is equivalent to issuing the request
+ for all possible modifier combinations (including the
+ combination of no modifiers). It is not required that all
+ modifiers specified have currently assigned keycodes. A button
+ of AnyButton is equivalent to issuing the request for all
+ possible buttons. It is not required that the specified button
+ be assigned to a physical button.
+
+ NULL may be passed for the modifier_device. If the
+ modifier_device is NULL, the core X keyboard is used as the
+ modifier_device.
+
+ An Access error is generated if some other client has issued a
+ GrabDeviceButton with the same device and button combination on
+ the same window. When using AnyModifier or AnyButton, the
+ request fails completely and the X server generates a Access
+ error and no grabs are established if there is a conflicting
+ grab for any combination. The request has no effect on an
+ active grab.
+
+ This request cannot be used to grab a button on the X pointer
+ device. The core GrabButton request should be used for that
+ purpose.
+
+ To release a passive grab of a button on an extension device,
+ use UngrabDeviceButton.
+
+ UngrabDeviceButton
+ device: DEVICE
+ button: BUTTON or AnyButton
+ modifiers: SETofKEYMASK or AnyModifier
+ modifier-device: DEVICE or NULL
+ grab-window: WINDOW
+
+ Errors: Device, Match, Window, Value, Alloc
+
+ This request is analogous to the core UngrabButton request. It
+ releases the passive button/key combination on the specified
+ window if it was grabbed by the client. A modifiers of
+ AnyModifier is equivalent to issuing the request for all
+ possible modifier combinations (including the combination of no
+ modifiers). A button of AnyButton is equivalent to issuing the
+ request for all possible buttons. This request has no effect on
+ an active grab. The device must have previously been opened
+ using the OpenDevice request otherwise a Device error will be
+ generated.
+
+ NULL may be passed for the modifier_device. If the
+ modifier_device is NULL, the core X keyboard is used as the
+ modifier_device.
+
+ This request cannot be used to ungrab a button on the X pointer
+ device. The core UngrabButton request should be used for that
+ purpose.
+
+2.16 Thawing A Device
+
+ To allow further events to be processed when a device has been
+ frozen, use AllowDeviceEvents.
+
+ AllowDeviceEvents
+ device: DEVICE
+ event-mode: {AsyncThisDevice, SyncThisD
+ evice, AsyncOtherDevices,
+ ReplayThisdevice, AsyncAll, or SyncAll}
+ time:TIMESTAMP or CurrentTime
+
+ Errors: Device, Value
+
+ The AllowDeviceEvents request releases some queued events if
+ the client has caused a device to freeze. The request has no
+ effect if the specified time is earlier than the last-grab time
+ of the most recent active grab for the client, or if the
+ specified time is later than the current X server time.
+
+ The following describes the processing that occurs depending on
+ what constant you pass to the event-mode argument:
+
+ * If the specified device is frozen by the client, event
+ processing for that device continues as usual. If the
+ device is frozen multiple times by the client on behalf
+ of multiple separate grabs, AsyncThisDevice thaws for
+ all. AsyncThisDevice has no effect if the specified
+ device is not frozen by the client, but the device need
+ not be grabbed by the client.
+
+ * If the specified device is frozen and actively grabbed
+ by the client, event processing for that device
+ continues normally until the next button or key event is
+ reported to the client. At this time, the specified
+ device again appears to freeze. However, if the reported
+ event causes the grab to be released, the specified
+ device does not freeze. SyncThisDevice has no effect if
+ the specified device is not frozen by the client or is
+ not grabbed by the client.
+
+ * If the specified device is actively grabbed by the
+ client and is frozen as the result of an event having
+ been sent to the client (either from the activation of a
+ GrabDeviceButton or from a previous AllowDeviceEvents
+ with mode SyncThisDevice, but not from a Grab), the grab
+ is released and that event is completely reprocessed.
+ This time, however, the request ignores any passive
+ grabs at or above (towards the root) the grab-window of
+ the grab just released. The request has no effect if the
+ specified device is not grabbed by the client or if it
+ is not frozen as the result of an event.
+
+ * If the remaining devices are frozen by the client, event
+ processing for them continues as usual. If the other
+ devices are frozen multiple times by the client on
+ behalf of multiple separate grabs, AsyncOtherDevices
+ “thaws” for all. AsyncOtherDevices has no effect if the
+ devices are not frozen by the client, but those devices
+ need not be grabbed by the client.
+
+ * If all devices are frozen by the client, event
+ processing (for all devices) continues normally until
+ the next button or key event is reported to the client
+ for a grabbed device (button event for the grabbed
+ device, key or motion event for the device), at which
+ time the devices again appear to freeze. However, if the
+ reported event causes the grab to be released, then the
+ devices do not freeze (but if any device is still
+ grabbed, then a subsequent event for it will still cause
+ all devices to freeze). SyncAll has no effect unless all
+ devices are frozen by the client. If any device is
+ frozen twice by the client on behalf of two separate
+ grabs, SyncAll "thaws" for both (but a subsequent freeze
+ for SyncAll will only freeze each device once).
+
+ * If all devices are frozen by the client, event
+ processing (for all devices) continues normally. If any
+ device is frozen multiple times by the client on behalf
+ of multiple separate grabs, AsyncAll "thaws" for all.
+ AsyncAll has no effect unless all devices are frozen by
+ the client.
+
+ AsyncThisDevice, SyncThisDevice, and ReplayThisDevice
+ have no effect on the processing of events from the
+ remaining devices. AsyncOtherDevices has no effect on
+ the processing of events from the specified device. When
+ the event_mode is SyncAll or AsyncAll, the device
+ parameter is ignored.
+
+ It is possible for several grabs of different devices
+ (by the same or different clients) to be active
+ simultaneously. If a device is frozen on behalf of any
+ grab, no event processing is performed for the device.
+ It is possible for a single device to be frozen because
+ of several grabs. In this case, the freeze must be
+ released on behalf of each grab before events can again
+ be processed.
+
+2.17 Controlling Device Focus
+
+ The current focus window for an extension input device can be
+ determined using the GetDeviceFocus request. Extension devices
+ are focused using the SetDeviceFocus request in the same way
+ that the keyboard is focused using the SetInputFocus request,
+ except that a device is specified as part of the request. One
+ additional focus state, FollowKeyboard, is provided for
+ extension devices.
+
+ To get the current focus state, revert state, and focus time of
+ an extension device, use GetDeviceFocus.
+
+ GetDeviceFocus
+ device: DEVICE
+ =>
+ focus: WINDOW, PointerRoot, FollowKeyboard, or None
+ revert-to: Parent, PointerRoot, FollowKeyboard, or None
+ focus-time: TIMESTAMP
+
+ Errors: Device, Match
+
+ This request returns the current focus state, revert-to state,
+ and last-focus-time of an extension device.
+
+ To set the focus of an extension device, use SetDeviceFocus.
+
+ SetDeviceFocus
+ device: DEVICE
+ focus: WINDOW, PointerRoot, FollowKeyboard, or None
+ revert-to: Parent, PointerRoot, FollowKeyboard, or None
+ focus-time: TIMESTAMP
+
+ Errors: Device, Window, Value, Match
+
+ This request changes the focus for an extension input device
+ and the last-focus-change-time. The request has no effect if
+ the specified time is earlier than the last-focus-change-time
+ or is later than the current X server time. Otherwise, the
+ last-focus-change-time is set to the specified time, with
+ CurrentTime replaced by the current server time.
+
+ The action taken by the server when this request is requested
+ depends on the value of the focus argument:
+
+ * If the focus argument is None, all input events from
+ this device will be discarded until a new focus window
+ is set. In this case, the revert-to argument is ignored.
+
+ * If a window ID is assigned to the focus argument, it
+ becomes the focus window of the device. If an input
+ event from the device would normally be reported to this
+ window or to one of its inferiors, the event is reported
+ normally. Otherwise, the event is reported relative to
+ the focus window.
+
+ * If you assign PointerRoot to the focus argument, the
+ focus window is dynamically taken to be the root window
+ of whatever screen the pointer is on at each input
+ event. In this case, the revert-to argument is ignored.
+
+ * If you assign FollowKeyboard to the focus argument, the
+ focus window is dynamically taken to be the same as the
+ focus of the X keyboard at each input event.
+
+ The specified focus window must be viewable at the time
+ of the request (else a Match error). If the focus window
+ later becomes not viewable, the X server evaluates the
+ revert-to argument to determine the new focus window.
+
+ * If you assign RevertToParent to the revert-to argument,
+ the focus reverts to the parent (or the closest viewable
+ ancestor), and the new revert-to value is taken to be
+ RevertToNone.
+
+ * If you assign RevertToPointerRoot,
+ RevertToFollowKeyboard, or RevertToNone to the revert-to
+ argument, the focus reverts to that value.
+
+ When the focus reverts, the X server generates DeviceFocusIn
+ and DeviceFocusOut events, but the last-focus-change time is
+ not affected.
+
+ This request causes the X server to generate DeviceFocusIn and
+ DeviceFocusOut events.
+
+2.18 Controlling Device Feedback
+
+ To get the settings of feedbacks on an extension device, use
+ GetFeedbackControl. This request provides functionality
+ equivalent to the core GetKeyboardControl and GetPointerControl
+ functions. It also provides a way to control displays
+ associated with an input device that are capable of displaying
+ an integer or string.
+
+ GetFeedbackControl
+ device: DEVICE
+ =>
+ num_feedbacks_return: CARD16
+ return_value: LISTofFEEDBACKSTATE
+
+ where
+
+ FEEDBACKSTATE: {KbdFeedbackState, PtrFeedbackState,
+ IntegerFeedbackState, StringFeedbackState,
+ BellFeedbackState, LedFeedbackState}
+
+ Feedbacks are reported by class. Those feedbacks that are
+ reported for the core keyboard device are in class KbdFeedback,
+ and are returned in the KbdFeedbackState structure. The members
+ of that structure are as follows:
+
+ CLASS Kbd:
+ [class: CARD8
+ length: CARD16
+ feedback id: CARD8
+ key_click_percent: CARD8
+ bell_percent: CARD8
+ bell_pitch: CARD16
+ bell_duration: CARD16
+ led_value: BITMASK
+ global_auto_repeat: {AutoRepeatModeOn, AutoRepeatModeOff}
+ auto_repeats: LISTofCARD8]
+
+ Those feedbacks that are equivalent to those reported for the
+ core pointer are in feedback class PtrFeedback and are reported
+ in the PtrFeedbackState structure. The members of that
+ structure are:
+
+ CLASS Ptr:
+ [class: CARD8
+ length: CARD16
+ feedback id: CARD8
+ accelNumerator: CARD16
+ accelDenominator: CARD16
+ threshold: CARD16]
+
+ Some input devices provide a means of displaying an integer.
+ Those devices will support feedback class IntegerFeedback,
+ which is reported in the IntegerFeedbackState structure. The
+ members of that structure are:
+
+ CLASS Integer:
+ [class: CARD8
+ length: CARD16
+ feedback id: CARD8
+ resolution: CARD32
+ min-val: INT32
+ max-val: INT32]
+
+ Some input devices provide a means of displaying a string.
+ Those devices will support feedback class StringFeedback, which
+ is reported in the StringFeedbackState structure. The members
+ of that structure are:
+
+ CLASS String:
+ [class: CARD8
+ length: CARD16
+ feedback id: CARD8
+ max_symbols: CARD16
+ num_keysyms_supported: CARD16
+ keysyms_supported: LISTofKEYSYM]
+
+ Some input devices contain a bell. Those devices will support
+ feedback class BellFeedback, which is reported in the
+ BellFeedbackState structure. The members of that structure are:
+
+ CLASS String:
+ [class: CARD8
+ length: CARD16
+ feedback id: CARD8
+ percent: CARD8
+ pitch: CARD16
+ duration: CARD16]
+
+ The percent sets the base volume for the bell between 0 (off)
+ and 100 (loud) inclusive, if possible. Setting to -1 restores
+ the default. Other negative values generate a Value error.
+
+ The pitch sets the pitch (specified in Hz) of the bell, if
+ possible. Setting to -1 restores the default. Other negative
+ values generate a Value error.
+
+ The duration sets the duration (specified in milliseconds) of
+ the bell, if possible. Setting to -1 restores the default.
+ Other negative values generate a Value error.
+
+ A bell generator connected with the console but not directly on
+ the device is treated as if it were part of the device. Some
+ input devices contain LEDs. Those devices will support feedback
+ class Led, which is reported in the LedFeedbackState structure.
+ The members of that structure are:
+
+ CLASS String:
+ [class: CARD8
+ length: CARD16
+ feedback id: CARD8
+ led_mask: BITMASK
+ led_value: BITMASK]
+
+ Each bit in led_mask indicates that the corresponding led is
+ supported by the feedback. At most 32 LEDs per feedback are
+ supported. No standard interpretation of LEDs is defined.
+
+ This function will fail with a BadMatch error if the device
+ specified in the request does not support feedbacks.
+
+ Errors: Device, Match
+
+ To change the settings of a feedback on an extension device,
+ use ChangeFeedbackControl.
+
+ ChangeFeedbackControl
+ device: DEVICE
+ feedbackid: CARD8
+ value-mask: BITMASK
+ value: FEEDBACKCONTROL
+ FEEDBACKCONTROL: {KBDFEEDBACKCONTROL,
+ PTRFEEDBACKCONTROL,
+ INTEGERFEEDBACKCONTROL,
+ STRINGFEEDBACKCONTROL,
+ BELLFEEDBACKCONTROL,
+ LEDFEEDBACKCONTROL}
+
+ Errors: Device, Match, Value
+
+ Feedback controls are grouped by class. Those feedbacks that
+ are equivalent to those supported by the core keyboard are
+ controlled by feedback class KbdFeedbackClass using the
+ KbdFeedbackControl structure. The members of that structure
+ are:
+
+ KBDFEEDBACKCTL
+ [class: CARD8
+ length: CARD16
+ feedback id: CARD8
+ key_click_percent: INT8
+ bell_percent: INT8
+ bell_pitch: INT16
+ bell_duration: INT16
+ led_mask: INT32
+ led_value: INT32
+ key: KEYCODE
+ auto_repeat_mode: {AutoRepeatModeOn, AutoRepeatModeOff,
+ AutoRepeatModeDefault}]
+
+ The key_click_percent sets the volume for key clicks between 0
+ (off) and 100 (loud) inclusive, if possible. Setting to -1
+ restores the default. Other negative values generate a Value
+ error.
+
+ If both auto_repeat_mode and key are specified, then the
+ auto_repeat_mode of that key is changed, if possible. If only
+ auto_repeat_mode is specified, then the global auto-repeat mode
+ for the entire keyboard is changed, if possible, without
+ affecting the per-key settings. It is a Match error if a key is
+ specified without an auto_repeat_mode.
+
+ The order in which controls are verified and altered is
+ server-dependent. If an error is generated, a subset of the
+ controls may have been altered.
+
+ Those feedback controls equivalent to those of the core pointer
+ are controlled by feedback class PtrFeedbackClass using the
+ PtrFeedbackControl structure. The members of that structure are
+ as follows:
+
+ PTRFEEDBACKCTL:
+ [class: CARD8
+ length: CARD16
+ feedback id: CARD8
+ accelNumerator: INT16
+ accelDenominator: INT16
+ threshold: INT16]
+
+ The acceleration, expressed as a fraction, is a multiplier for
+ movement. For example, specifying 3/1 means the device moves
+ three times as fast as normal. The fraction may be rounded
+ arbitrarily by the X server. Acceleration only takes effect if
+ the device moves more than threshold pixels at once and only
+ applies to the amount beyond the value in the threshold
+ argument. Setting a value to -1 restores the default. The
+ values of the do-accel and do-threshold arguments must be
+ nonzero for the device values to be set. Otherwise, the
+ parameters will be unchanged. Negative values generate a Value
+ error, as does a zero value for the accel-denominator argument.
+
+ Some devices are capable of displaying an integer. This is done
+ using feedback class IntegerFeedbackClass using the
+ IntegerFeedbackControl structure. The members of that structure
+ are as follows:
+
+ INTEGERCTL:
+ [class: CARD8
+ length: CARD16
+ feedback id: CARD8
+ int_to_display: INT32]
+
+ Some devices are capable of displaying an string. This is done
+ using feedback class StringFeedbackClass using the
+ StringFeedbackCtl structure. The members of that structure are
+ as follows:
+
+ STRINGCTL:
+ [class: CARD8
+ length: CARD16
+ feedback id: CARD8
+ syms_to_display: LISTofKEYSYMS]
+
+ Some devices contain a bell. This is done using feedback class
+ BellFeedbackClass using the BellFeedbackControl structure. The
+ members of that structure are as follows:
+
+ BELLCTL:
+ [class: CARD8
+ length: CARD16
+ feedback id: CARD8
+ percent: INT8
+ pitch: INT16
+ duration: INT16]
+
+ Some devices contain leds. These can be turned on and off using
+ the LedFeedbackControl structure. The members of that structure
+ are as follows:
+
+ LEDCTL:
+ [class: CARD8
+ length: CARD16
+ feedback id: CARD8
+ led_mask: BITMASK
+ led_value: BITMASK]
+
+ Errors: Device, Match, Value
+
+2.20 Ringing a Bell on an Input Device
+
+ To ring a bell on an extension input device, use DeviceBell.
+
+ DeviceBell:
+ device: DEVICE
+ feedbackclass: CARD8
+ feedbackid: CARD8
+ percent: INT8
+
+ Errors: Device, Value
+
+ This request is analogous to the core Bell request. It rings
+ the specified bell on the specified input device feedback,
+ using the specified volume. The specified volume is relative to
+ the base volume for the feedback. If the value for the percent
+ argument is not in the range -100 to 100 inclusive, a Value
+ error results. The volume at which the bell rings when the
+ percent argument is nonnegative is:
+
+ base - [(base * percent) / 100] + percent
+
+ The volume at which the bell rings when the percent argument is
+ negative is:
+
+ base + [(base * percent) / 100]
+
+ To change the base volume of the bell, use
+ ChangeFeedbackControl request.
+
+Controlling Device Encoding
+
+ To get the keyboard mapping of an extension device that has
+ keys, use GetDeviceKeyMapping.
+
+ GetDeviceKeyMapping
+ device: DEVICE
+ first-keycode: KEYCODE
+ count: CARD8
+ =>
+ keysyms-per-keycode: CARD8
+ keysyms: LISTofKEYSYM
+
+ Errors: Device, Match, Value
+
+ This request returns the symbols for the specified number of
+ keycodes for the specified extension device, starting with the
+ specified keycode. The first-keycode must be greater than or
+ equal to min-keycode as returned in the connection setup (else
+ a Value error), and
+
+ first-keycode + count - 1
+
+ must be less than or equal to max-keycode as returned in the
+ connection setup (else a Value error). The number of elements
+ in the keysyms list is
+
+ count * keysyms-per-keycode
+
+ and KEYSYM number N (counting from zero) for keycode K has an
+ index (counting from zero) of
+
+ (K - first-keycode) * keysyms-per-keycode + N
+
+ in keysyms. The keysyms-per-keycode value is chosen arbitrarily
+ by the server to be large enough to report all requested
+ symbols. A special KEYSYM value of NoSymbol is used to fill in
+ unused elements for individual keycodes.
+
+ If the specified device has not first been opened by this
+ client via OpenDevice, or if that device does not support input
+ class Keys, this request will fail with a Device error.
+
+ To change the keyboard mapping of an extension device that has
+ keys, use ChangeDeviceKeyMapping.
+
+ ChangeDeviceKeyMapping
+ device: DEVICE
+ first-keycode: KEYCODE
+ keysyms-per-keycode: CARD8
+ keysyms: LISTofKEYSYM
+ num_codes: CARD8
+
+ Errors: Device, Match, Value, Alloc
+
+ This request is analogous to the core ChangeKeyMapping request.
+ It defines the symbols for the specified number of keycodes for
+ the specified extension device. If the specified device has not
+ first been opened by this client via OpenDevice, or if that
+ device does not support input class Keys, this request will
+ fail with a Device error.
+
+ The number of elements in the keysyms list must be a multiple
+ of keysyms_per_keycode. Otherwise, ChangeDeviceKeyMapping
+ generates a Length error. The specified first_keycode must be
+ greater than or equal to the min_keycode value returned by the
+ ListInputDevices request, or this request will fail with a
+ Value error. In addition, if the following expression is not
+ less than the max_keycode value returned by the
+ ListInputDevices request, the request will fail with a Value
+ error:
+
+ first_keycode + (num_codes / keysyms_per_keycode) - 1
+
+ To obtain the keycodes that are used as modifiers on an
+ extension device that has keys, use GetDeviceModifierMapping.
+
+ GetDeviceModifierMapping
+ device: DEVICE
+ =>
+ keycodes-per-modifier: CARD8
+ keycodes: LISTofKEYCODE
+
+ Errors: Device, Match
+
+ This request is analogous to the core GetModifierMapping
+ request. This request returns the keycodes of the keys being
+ used as modifiers. The number of keycodes in the list is
+ 8*keycodes-per-modifier. The keycodes are divided into eight
+ sets, with each set containing keycodes-per-modifier elements.
+ The sets are assigned in order to the modifiers Shift, Lock,
+ Control, Mod1, Mod2, Mod3, Mod4, and Mod5. The
+ keycodes-per-modifier value is chosen arbitrarily by the
+ server; zeroes are used to fill in unused elements within each
+ set. If only zero values are given in a set, the use of the
+ corresponding modifier has been disabled. The order of keycodes
+ within each set is chosen arbitrarily by the server.
+
+ To set which keycodes that are to be used as modifiers for an
+ extension device, use SetDeviceModifierMapping.
+
+ SetDeviceModifierMapping
+ device: DEVICE
+ keycodes-per-modifier: CARD8
+ keycodes: LISTofKEYCODE
+ =>
+ status: {Success, Busy, Failed}
+
+ Errors: Device, Match, Value, Alloc
+
+ This request is analogous to the core SetModifierMapping
+ request. This request specifies the keycodes (if any) of the
+ keys to be used as modifiers. The number of keycodes in the
+ list must be 8*keycodes-per-modifier (else a Length error). The
+ keycodes are divided into eight sets, with the sets, with each
+ set containing keycodes-per-modifier elements. The sets are
+ assigned in order to the modifiers Shift, Lock, Control, Mod1,
+ Mod2, Mod3, Mod4, and Mod5. Only non-zero keycode values are
+ used within each set; zero values are ignored. All of the
+ non-zero keycodes must be in the range specified by min-keycode
+ and max-keycode in the ListInputDevices request (else a Value
+ error). The order of keycodes within a set does not matter. If
+ no non-zero values are specified in a set, the use of the
+ corresponding modifier is disabled, and the modifier bit will
+ always be zero. Otherwise, the modifier bit will be one
+ whenever at least one of the keys in the corresponding set is
+ in the down position.
+
+ A server can impose restrictions on how modifiers can be
+ changed (for example, if certain keys do not generate up
+ transitions in hardware or if multiple keys per modifier are
+ not supported). The status reply is Failed if some such
+ restriction is violated, and none of the modifiers are changed.
+
+ If the new non-zero keycodes specified for a modifier differ
+ from those currently defined, and any (current or new) keys for
+ that modifier are logically in the down state, then the status
+ reply is Busy, and none of the modifiers are changed.
+
+ This request generates a DeviceMappingNotify event on a Success
+ status. The DeviceMappingNotify event will be sent only to
+ those clients that have expressed an interest in receiving that
+ event via the XSelectExtensionEvent request.
+
+ A X server can impose restrictions on how modifiers can be
+ changed, for example, if certain keys do not generate up
+ transitions in hardware or if multiple modifier keys are not
+ supported. If some such restriction is violated, the status
+ reply is MappingFailed , and none of the modifiers are changed.
+ If the new keycodes specified for a modifier differ from those
+ currently defined and any (current or new) keys for that
+ modifier are in the logically down state, the status reply is
+ MappingBusy, and none of the modifiers are changed.
+
+2.20 Controlling Button Mapping
+
+ These requests are analogous to the core GetPointerMapping and
+ ChangePointerMapping requests. They allow a client to determine
+ the current mapping of buttons on an extension device, and to
+ change that mapping.
+
+ To get the current button mapping for an extension device, use
+ GetDeviceButtonMapping.
+
+ GetDeviceButtonMapping
+ device: DEVICE
+ nmap: CARD8
+ =>
+ map_return: LISTofCARD8
+
+ Errors: Device, Match
+
+ The GetDeviceButtonMapping function returns the current mapping
+ of the buttons on the specified device. Elements of the list
+ are indexed starting from one. The length of the list indicates
+ the number of physical buttons. The nominal mapping is the
+ identity mapping map[i]=i.
+
+ nmap indicates the number of elements in the map_return array.
+ Only the first nmap entries will be copied by the library into
+ the map_return array.
+
+ To set the button mapping for an extension device, use
+ SetDeviceButtonMapping.
+
+ SetDeviceButtonMapping
+ device: DEVICE
+ map: LISTofCARD8
+ nmap: CARD8
+ =>
+ status: CARD8
+
+ Errors: Device, Match, Value
+
+ The SetDeviceButtonMapping function sets the mapping of the
+ specified device and causes the X server to generate a
+ DeviceMappingNotify event on a status of MappingSuccess.
+ Elements of the list are indexed starting from one. The length
+ of the list, specified in nmap, must be the same as
+ GetDeviceButtonMapping would return. Otherwise,
+ SetDeviceButtonMapping generates a Value error. A zero element
+ disables a button, and elements are not restricted in value by
+ the number of physical buttons. If any of the buttons to be
+ altered are in the down state, the status reply is MappingBusy
+ and the mapping is not changed.
+
+ In servers supporting XI 1.x, no two elements can have the same
+ nonzero value. Otherwise, this function generates a Value
+ error.
+
+2.21 Obtaining The State Of A Device
+
+ To obtain vectors that describe the state of the keys, buttons
+ and valuators of an extension device, use QueryDeviceState.
+
+ QueryDeviceState
+ device: DEVICE
+ =>
+ device-id: CARD8
+ data: LISTofINPUTCLASS
+
+ where
+
+ INPUTCLASS: {VALUATOR, BUTTON, KEY}
+ CLASS VALUATOR:
+ [class: CARD8
+ num_valuators: CARD8
+ mode: CARD8
+ #x01 device mode (0 = Relative, 1 = Absolute)
+ #x02 proximity state (0 = InProximity, 1 = OutOfProximity)
+ valuators: LISTofINT32]
+ CLASS BUTTON:
+ [class: CARD8
+ num_buttons: CARD8
+ buttons: LISTofCARD8]
+ CLASS KEY:
+ [class: CARD8
+ num_keys: CARD8
+ keys: LISTofCARD8]
+
+ Errors: Device
+
+ The QueryDeviceState request returns the current logical state
+ of the buttons, keys, and valuators on the specified input
+ device. The buttons and keys arrays, byte N (from 0) contains
+ the bits for key or button 8N to 8N+7 with the least
+ significant bit in the byte representing key or button 8N.
+
+ If the device has valuators, a bit in the mode field indicates
+ whether the device is reporting Absolute or Relative data. If
+ it is reporting Absolute data, the valuators array will contain
+ the current value of the valuators. If it is reporting Relative
+ data, the valuators array will contain undefined data.
+
+ If the device reports proximity information, a bit in the mode
+ field indicates whether the device is InProximity or
+ OutOfProximity.
+
+2.22 Listing Device Properties
+
+ Introduced with XI 1.5
+
+ ListDeviceProperties
+ deviceid: CARD8
+ =>
+ nAtoms: CARD16
+ Atoms: LISTofATOM
+
+ Errors: Device
+
+ Each device can store an arbitrary number of properties. These
+ properties can be allocated by either the client or the driver.
+ The client can change device properties and the server
+ guarantees that the device driver is notified about a change of
+ the device's properties.
+
+ ListDeviceProperties returns all properties of a device. The
+ client is expected to retrieve details about the properties it
+ is interested in separately.
+
+2.23 Getting a Device Property
+
+ Introduced with XI 1.5
+
+ GetDeviceProperty:
+ property: ATOM
+ type: ATOM
+ longOffset: CARD32
+ longLength: CARD32
+ deviceid: CARD8
+ delete: BOOL
+ =>
+ propertyType: ATOM
+ bytesAfter: CARD32
+ nItems: CARD32
+ format: CARD8
+ deviceid: CARD8
+ data: [LISTofCARD8]
+
+ Errors: Atom, Device, Value, Access
+
+ Retrieve the value for a property. If the property does not
+ exist, propertyType is None and all other fields are undefined.
+
+ If type is not AnyPropertyType and does not match the
+ property's actual type, the propertyType, bytesAfter, and
+ format are returned but not the actual data.
+
+ longOffset and longLength specify the offset and length
+ respectively in 32-bit multiples of the data to retrieve.
+
+ If delete is True, the property is deleted after querying its
+ data. If the property cannot be deleted, a BadAccess error is
+ returned.
+
+ propertyType returns the atom identifier that defines the
+ actual type of the property.
+
+ If bytesAfter is non-zero, it specifies the number of data
+ 4-byte units after the retrieved chunk of data.
+
+ format specifies whether the data should be viewed as a list of
+ 8-bit, 16-bit, or 32-bit quantities. Possible values are 8, 16,
+ and 32. This information allows the X server to correctly
+ perform byte-swap operations as necessary.
+
+ nItem specifies the number of 8-bit, 16-bit, or 32-bit items
+ returned after the request.
+
+2.24 Changing a Device Property
+
+ Introduced with XI 1.5
+
+ ChangeDeviceProperty:
+ property: ATOM
+ type: ATOM
+ deviceid: CARD8
+ format: CARD8
+ mode: CARD8
+ nUnits: CARD32
+
+ Errors: Atom, Device, Value, Match, Access
+
+ Changes the value of a specified property.
+
+ The type specifies the atom identifier that defines the type of
+ the property. If mode is not PropModeReplace, the type must
+ match the current type of the property or a BadMatch error is
+ returned.
+
+ format specifies whether the data should be viewed as a list of
+ 8-bit, 16-bit, or 32-bit quantities. Possible values are 8, 16,
+ and 32. This information allows the X server to correctly
+ perform byte-swap operations as necessary.
+
+ If mode is PropModeReplace, a preexising value for this
+ property is replaced with the new value. If mode is
+ PropModePrepend or PropModeAppend, the value is prepended or
+ appended, respectively, to the current value of the property.
+
+ nUnits specifies the number of 8-bit, 16-bit, or 32-bit items
+ supplied after the reply.
+
+ Changing a device property results in a
+ DevicePropertyNotifyEvent being sent to all clients.
+
+2.25 Deleting a Device Property
+
+ Introduced with XI 1.5
+
+ DeleteDeviceProperty:
+ property: ATOM
+ deviceid: CARD8
+
+ Errors: Atom, Device, Match, Access.
+
+ Deletes the specified property. If the property cannot be
+ deleted by the client, a BadAccess error is returned.
+
+3. Events
+
+ The input extension creates input events analogous to the core
+ input events. These extension input events are generated by
+ manipulating one of the extension input devices.
+
+3.1 Button, Key, and Motion Events
+
+ DeviceKeyPress
+ DeviceKeyRelease
+ DeviceButtonPress,
+ DeviceButtonRelease
+ DeviceMotionNotify
+ device: CARD8
+ root, event: WINDOW
+ child: Window or None
+ same-screen: BOOL
+ root-x, root-y, event-x, event-y: INT16
+ detail: <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/proto/inputproto/configure.ac b/proto/inputproto/configure.ac
index 56b9bc7cb..1052dc2be 100644
--- a/proto/inputproto/configure.ac
+++ b/proto/inputproto/configure.ac
@@ -1,8 +1,12 @@
AC_PREREQ([2.57])
-AC_INIT([InputProto], [1.5.0], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.0], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
-XORG_RELEASE_VERSION
+# Require xorg-macros: XORG_DEFAULT_OPTIONS
+m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.3 or later before running autoconf/autogen])])
+XORG_MACROS_VERSION(1.3)
+
+XORG_DEFAULT_OPTIONS
AC_OUTPUT([Makefile
inputproto.pc])