This macro aggregate a number of existing macros that sets commmon
X.Org components configuration options. It shields the configuration file from
future changes.
Using common defaults will reduce errors and maintenance.
Only the very small or inexistent custom section need periodic maintenance
when the structure of the component changes. Do not edit defaults.
This is the XI protocol specification document that used to be in xorg-docs.
It's now moved here, and if it ever sees updates, the updates will only
apply to here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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 d0b1e55b87.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
