There's no need for internal events to be a struct with a single nested
union, we might as well make the union itself the InternalEvent.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
isMaster is not enough as long as we differ between master pointers and
keyboard. With flexible device classes, the usual checks for whether a
master device is a pointer (currently check for ->button, ->valuators or
->key) do not work as an SD may post an event through a master and mess this
check up.
Example, a device with valuators but no buttons would remove the button
class from the VCP and thus result in the
IsPointerDevice(inputInfo.pointer) == FALSE.
This will become worse in the future when new device classes are introduced
that aren't provided in the current system (e.g. a switch class).
This patch replaces isMaster with "type", one of SLAVE, MASTER_POINTER and
MASTER_KEYBOARD. All checks for dev->isMaster are replaced with an
IsMaster(dev).
dev->u.lastSlave was not signal safe since it was accessed by the DIX and
during signal handling.
Replaced with:
'dev->last.slave' for the signal handler's lastSlave (used to generate
DeviceChangedEvents), .
'dev->u.lastSlave' for the DIX lastSlave (currently only used in
change_modmap)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This type is only used in XI to give a hint of what type this device may be.
Call it xinput_type for clarity.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This approach is broken anyway. DIPT only checked for the XInput type
"MOUSE" and the only user of this is xf86ActivateDevice when it sets the
Activate/DeactivateGrab functions.
Since synaptics and wacom set their own types, evdev only sets MOUSE for,
well, mice half the devices didn't have this set correctly anyway.
Instead, ActivatePointerGrab should be merged together with
ActivateKeyboardGrab.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Buttons append 4-byte units to the end of the reply, they need to be
included too.
Reported-by: Mark Dokter
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Both values need to fail the request, so we need to check them before
looping through the modifier masks. Otherwise, a wrong grab_window will
show up in each failed modifier return but not actually cause an error.
There's only two reasons for hierarchy events:
- device is added, removed, etc. In this case we want to send the event as
it happens.
- devices are added in a XIChangeDeviceHierarchy request. In this case we
only want one event cumulating all changes.
Rather than have one field per hierarchy change, XI2 has two fields - one
generic one and one per-device that include the device-specific flags.
This requires some funky handling for removed devices, but oh well.
This wrong check may cause BadLength to be returned to the client even if the
length is correct.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Key events may change the modifier state, so we need to get the prev_state for
those (i.e. without the changes by the event already applied).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A XTest virtual slave device pair (kbd/ptr) exists for every master
device pair. This is so XTest events are correctly propogated via slave
devices up to Master devices and the classes are correctly changed along
the way. We add the XTest slave device pair to the Virtual Core pointer
and provide a simple way of creating the devices.
A XTest Slave Device is identified by the XTstDevicePrivateKey property
being set in the devices devProperties
XI events are still propagated through the matching device, in the hope the
client knows what it is doing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Allocating a slave device is essentially the same as allocating a master device.
Hence we rename AllocMaster to AllocDevicePair and provided the ability to
indicate if a master or slave device pair is required.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some keyboards (?) advertise more than MAX_VALUATORS axes. Parts of the
internal event delivery relies on not having more than MAX_VALUATOR axes, so
let's cap it down.
If there's real devices that require more than the current 36, I'm sure we can
bump this up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some keyboards (?) advertise more than MAX_VALUATORS axes. Parts of the
internal event delivery relies on not having more than MAX_VALUATOR axes, so
let's cap it down.
If there's real devices that require more than the current 36, I'm sure we can
bump this up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Virtually all callers use
XkbGetRulesDefault(&rmlvo);
InitKeyboardDeviceStruct(..., rmlvo);
Let's save them the trouble and accept NULL as a hint to take the
default RMLVO.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Close <Benjamin.Close@clearchain.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>