FixKeyState needs to be able to handle XI events, otherwise we get "impossible
keyboard events" on server zaps and other special key combos.
(cherry picked from commit 5ee409794e)
In some cases a button press may activate a passive core grab. If the client
owning the passive grab already has a core grab on another device, don't
actually activate it. Otherwise the client gets two simultaneous passive
core grabs, and may never ungrab the device again (only if the other grab uses
GrabModeSync).
Reproducable: fire up gnome-session, open up gnome-terminal. Click with the
ClientPointer onto the window decoration, then click with another pointer onto
an application icon in the panel. Drag the icon out, release the button and
voila - you just lost your second mouse.
This is a half-assed attempt at getting rid of some enter-leave problems. When
a grab is activated, the events didn't get sent before, leading to interesting
results. This commit papers over it but doesn't actually fix it properly. The
whole enter/leave (focusin/out) structure needs to be ripped out and changed
for multiple devices.
* dix/events.c, include/dix.h:
(UpdateSpriteForScreen): added this to update the mouse sprite context
when we switch from a pScreen to another.
* mi/mipointer.c:
(miPointerWarpCursor): as we are switching to a new pScreen,
don't forget to update the mouse sprite context.
Let the drivers only generate XI events and put those into the event queue.
When processing events, generate core events as needed. This fixes a number of
problems with XKB and the DIX in general.
The previous approach was to put core events and XI events as separate events
into the event queue. When being processed, the server had no knowledge of
them coming from the same device state change. Anything that would then change
the state of the device accordingly was in danger of changing it twice,
leading to some funny (i.e. not funny at all) results.
Emulating core events while processing XI events fixes this, there is only one
path that actually changes the device state now. Although we have to be
careful when replaying events from synced devices, otherwise we may lose
events.
Note: XI has precedence over core for passive grabs, but core events are
delivered to the client first.
This removes the wrapping added in 340911d724
We need it unconditionally in a few places, and the rest checked for NULL and
then set it to VCK anyway. So, fixing up all callers to appreciate the defined
return value.
GenericEvents can't be parsed to keyButtonPointer, and there's no guarantee
that it has a time field anyway. PlayReleasedEvent needs to store the millis
when we know it (core events, XI event) and just re-use them for GenericEvents.
Yes, this is a hack. But it looks like the time has zero significance anyway.
The device state needs to be changed while processing the XI event. Core
events are always processed after XI, so by then the device is already set up
properly. However, we now rely on DeviceButtonMotionMask to be equal to
ButtonMotionMask. It already is, but stick a big fat warning in so nobody
attempts to change it.
This commit disables XKB for the VCK, thus essentially for all devices.
Temporarily anyway.
We shouldn't be able to restrict events like Expose, etc. with device based
ACLs. So we just ignore all non-input events when checking for permissions.
A passive core grab doesn't specify the device, and is thus created with the
ClientPointer as device. When this grab is activated later, don't actually
activate the grab on the grab device, but rather change the device to the one
that caused the grab to activate. Same procedure for keyboards.
Makes core apps _A LOT_ more useable and reduces the need to set the
ClientPointer.
Only applies to core grabs!
We need to do this to update the sprites x/y coordinate before we assemble a
button event. Absolute devices may send a buttonEvent with valuators attached.
If we don't update the sprite before assembling the event, the valuators are
lost and the button press is delivered to the previous position of the device.
Doesn't have any effect on relative devices.
We need this to allow extensions to fill in extra data for an event before it
is sent to the client. This is probably to be used like
FillUpEventsFromWindow().
This is definitely necessary in CheckDeviceGrabAndHintWindow (thanks to Paulo
Zanoni for spotting it). We're resetting it everywhere else too, just to be
save.
Device drivers flush their buttons on device init and cause a button down
event to be generated. If we unconditionally decrease the buttons, we won't be
able to ever get a passive device grab.
Format documentation for CheckDeviceGrabs to make it readable.
(cherry picked from commit 3e894974cd)
Conflicts:
Xi/exevents.c
Is set when passive grab is implicit as result of a ButtonPress event. If this
is the case, we need to store the XI mask as well as the core mask to ensure
delivery of XI events during the grab's lifetime.
Remove all core grabs on other devices when client issues a GrabPointer or
GrabKeyboard request. Let's assume that the client really only wants one
device to interact, so this seems like a reasonable solution.
Device drivers flush their buttons on device init and cause a button down
event to be generated. If we unconditionally decrease the buttons, we won't be
able to ever get a passive device grab.
Format documentation for CheckDeviceGrabs to make it readable.
This quickfixes event delivery problems with XI events when a grab was on.
deviceMask is only used when the grab was from a ButtonPress to preserve
potential XI event masks.
This is not an ideal solution but it works until I have time to work on
PassiveGrabs.
