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