diff options
| -rw-r--r-- | proto/inputproto/ChangeLog | 1391 | ||||
| -rw-r--r-- | proto/inputproto/Makefile | 4 | ||||
| -rw-r--r-- | proto/inputproto/Makefile.am | 11 | ||||
| -rw-r--r-- | proto/inputproto/XI.h | 13 | ||||
| -rw-r--r-- | proto/inputproto/XI2.h | 181 | ||||
| -rw-r--r-- | proto/inputproto/XI2proto.h | 976 | ||||
| -rw-r--r-- | proto/inputproto/XI2proto.txt | 1677 | ||||
| -rw-r--r-- | proto/inputproto/XInput.h | 1273 | ||||
| -rw-r--r-- | proto/inputproto/XIproto.h | 1038 | ||||
| -rw-r--r-- | proto/inputproto/XIproto.txt | 2542 | ||||
| -rw-r--r-- | proto/inputproto/configure.ac | 8 |
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]) |