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>
Yes, this means we have even more arguments to GrabDevice. But it beats having
a copy of most but not all of GrabDevice in ProcGrabPointer.
Also, reshuffle the order of parameters, the CARD* status is a return value
and should be last.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
