These grabs are suported through two fake devices inputInfo.all_devices and
inputInfo.all_master_devices. These devices are not part of the device list
and are only initialised for their device id, nothing else.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A passive XI2 grab always uses the paired master device as a modifier
device. After issuing a passive grab, the slave may be reattached to a
different master and hence the modifier device may change.
Rework addresses two issues:
- storing the master device's pointer is a bad idea, we need to store the ID
of the device in case it disappears during the grab.
- restoring the old master did not actually reattach the device. Fixed now.
grab->type is the device type and XI2 types overlap with core events (being
less than GenericEvent). Thus, for passive grabs the grab device would be
overwritten with whatever device was activating it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Extension devices have ActivateKeyboardGrab as their grab activation
function, hence we need to ensure the implicit passive grab flag is set
accordingly in the grab for further event delivery.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If an implicit passive grab is active, the XI event mask is in
grab->deviceMask. Otherwise, for explicit grabs, the XI event mask is in
grab->eventMask.
Reported-by: Thomas Jaeger
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With internal events, we only have one event for all the data, no need to
calculate for extra events.
Reported-by: Thomas Jaeger
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a passive enter or focus in grab activates, send additional enter or
focus events with mode XIPassiveGrabNotify to the grabbing client.
Likewise, if the grab deactivates, send additional leave or focus out
events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Enter grabs are checked for in CheckMotion(), each time the sprite window
changes the current grab is deactivated (if applicable) and the new grab is
activated (if applicable). Exception - if the grab is on a parent window of
the current window since we keep the grab across descendants.
Since CheckMotion() may change the grab status of a device, we mustn't get
"dev->deviceGrab.grab" in ProcessOtherEvents until after CheckMotion().
FocusIn grabs are checked in much the same manner.
The event delivery for grabs replaces the NotifyNormal on window change with
a NotifyGrab on window change. Note that this happens before the grab
activates, so the EnterNotify(NotifyGrab) is still delivered to the window,
not to the grabbing client. This is in line with the core protocol semantics
for NotifyGrab events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's devices (e.g. some barcode readers) that have axes but no buttons.
When such a device sends a motion event, the valuator and button class is
copied into the master pointer (i.e. removing the button class).
So we need a couple of extra sanity checks for the button class to exist.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Copying all classes into the master device has drawbacks for hybrid devices
(devices that are both mice and keyboards). If such a device posts an event,
it's key classes are moved into the VCP. The key event itself is unaffected
by keyboard grabs and the like.
Partial class copying copies depending on the event and copies the classes
into the right master device (i.e. the VCK for key events, the VCP for
pointer events).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For hybrid devices (keys + buttons/axes) the attached master device is
generally the wrong one. One shouldn't post a button event through a
keyboard and vice versa.
GetMaster(dev) returns the right master device for the given type needed.
This may be the MD paired with this device's MD.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ChangeDeviceId would actually overwrite the flags field if deviceid wasn't
present. Aside from the event of course not telling which device generated
it in the first place.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
A device can only be attached to a single master device. So instead of
looping and searching for the master device, we can just use dev->u.master
directly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the device is disabled ("off"), it must not send events to a client.
The driver shouldn't send events in that case anyway, but just to make sure
we simply drop events coming while the device is disabled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A device can only be attached to a single master device. So instead of
looping and searching for the master device, we can just use dev->u.master
directly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a proper access mode, and reverse the logic of the return value.
Zero ("Success") is returned on success from the hook calls.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
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.
Xephyr doesn't manually set Activate/DeactivateGrab for new devices,
resulting in a NULL-pointer dereference later when a grab is activated.
Avoid the segfault by ensuring that the pointer is always valid.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Xephyr doesn't manually set Activate/DeactivateGrab for new devices,
resulting in a NULL-pointer dereference later when a grab is activated.
Avoid the segfault by ensuring that the pointer is always valid.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Error: Write outside array bounds at Xext/geext.c:406
in function 'GEWindowSetMask' [Symbolic analysis]
In array dereference of cli->nextSib[extension] with index 'extension'
Array size is 128 elements (of 4 bytes each), index <= 128
Error: Buffer overflow at dix/events.c:592
in function 'SetMaskForEvent' [Symbolic analysis]
In array dereference of filters[deviceid] with index 'deviceid'
Array size is 20 elements (of 512 bytes each), index >= 0 and index <= 20
Error: Read buffer overflow at hw/xfree86/loader/loader.c:226
in function 'LoaderOpen' [Symbolic analysis]
In array dereference of refCount[new_handle] with index 'new_handle'
Array size is 256 elements (of 4 bytes each), index >= 1 and index <= 256
These bugs were found using the Parfait source code analysis tool.
For more information see http://research.sun.com/projects/parfait
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
newer gcc's warn against how this cast is done (though it eludes me why),
and lrintf() is also faster especially on insane processors like the P4
(http://www.mega-nerd.com/FPcast).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a shorthand for disabling acceleration, while retaining the
possiblity to use constant deceleration. If constant deceleration is
also unused, it will optimize motion processing.
Other possiblities to deactivate acceleration were quite hidden,
and didn't always work as expected. E.g. xset m 1 1 would retain
adaptive deceleration, while xset m 1 0 would not (in the default
profile).
Also removes the 'reserved' profile; it was unused and it's trivial
to add new ones anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
