Center the frame around the first pointer found and then update all pointers
on the same screen to move to the edges (if necessary).
Note: xf86WarpCursor needs to be modified, is using deprecated
miPointerWarpCursor and will kill the server when called with
inputInfo.pointer.
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.
Instead of hardcoding CoreProcessPointerEvent, actually try to unwrap properly
and then call the unwrapped processInputProc. Seems to be a better idea,
especially since it makes stuff actually work...
Followup to [1].
If a core grab causes the device to freeze, it overwrites the processInputProc
of the device. [1] would then overwrite this while unwrapping, the device
does not thaw anymore.
Changing this to only re-wrap if the processInputProc hasn't been changed
during the event handling.
[1] 340911d724
When processing events from the EQ, _always_ call the processInputProc of the
matching device. For XI devices, this proc is wrapped in three layers.
Core event handling is wrapped by XI event handling, which is wrapped by XKB.
A core event now passes through XKB -> XI -> DIX.
This gets rid of a sync'd grab problem: with the previous code, core events
did disappear during a sync'd device grab on account of mieqProcessInputEvents
calling the processInputProc of the VCP/VCK instead of the actual device. This
lead to the event being processed as normal instead of being enqueued for
later replaying.
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.
EnableDevices is (amongst others )called after a VT switch. We must not create
a new sprite or re-pair the device, otherwise we lose the input device setup
that we had before the VT switch.
This requires the devices to be in exactly the same order as before
the VT switch. Removing a device while on a different VT is probably a bad
idea.
Call ProcessOtherEvents first, then for all keyboard devices let them be
wrapped by XKB. This way all XI events will go through XKB.
Note that the VCK is still not wrapped, so core events will bypass XKB.
XI events can now take the same processing paths as core events, and should do
the correct state changes etc.
There's some cases where XKB will use KeyPress as type for an event to be
delivered to the client. Stuck warnings in, not sure what the correct solution
is yet.
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.
This reverts commit 6b055e5d97.
MPX relies on the XI event being delivered before the core event. Device grabs
break, amongst other things. I guess stuck modifiers need to be fixed some
other way.
Conflicts:
dix/getevents.c
Using a global array for action filters is bad. If two keyboard hit a modifier
at the same time, releaseing the first one will deactivate the filter and
thus the second keyboard can never release the modifier again.
Previous version only moved the VCP, causing "bogus pointer events" lateron.
Now we run through the device list, updating each pointer separately if
necessary.
Also stick a big warning into RRPointerMoved, not sure what device we need to
work on here.
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.
As a result, we can remove the quirks that existed to flip the bits back around
for us. This is not confirmed in all cases due to lack of bugs containing EDID
blocks associated with the quirks, but is likely true.
RRFirstOutput returns the first active output, which won't be set until
after RRScanOldConfig is finished running. Instead, just use the first
output (which is the only output present with an old driver, after all).
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!
I exported the evdev driver to Xephyr server. I'm running it using something
like:
$ ./hw/kdrive/ephyr/Xephyr :1 -mouse evdev,,device=/dev/input/event4 -keybd \
evdev,,device=/dev/input/event1,xkbmodel=abnt2,xkblayout=br
It also closes /#5668.
Don't use our DBusError for property getting, because we simply don't care:
this fixes D-Bus error spew to stderr. Thanks Michel Dänzer for debugging
and testing.
