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