| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
If the client currently holds a core grab on any device, this device has
priority, even over the ClientPointer.
|
|
In the case of a NotifyUngrab, the flag for the device may already be set but
we still need to send the FocusIn event.
|
|
Conflicts:
Xext/EVI.c
Xext/appgroup.c
Xext/cup.c
Xext/mitmisc.c
Xext/sampleEVI.c
dix/window.c
|
|
|
|
|
|
|
|
Instead of a simple counter, use bits to keep track of which device is where
etc. When device enters a window (or sets focus), the bit matching the device
is set, when it leaves again, it is unset. If there are 0 bits set, then
Leave/Enter/Focus events may be sent to the client.
Same theory as before, but this should get around the insanity with
Grab/Ungrab special cases. Those cases are basically untested though.
|
|
A pointer device may have a focus class, but even if so, pointer events must
be delivered to the sprite window, not the focus window.
|
|
If a pointer devices has key classes as well, don't register it as a keyboard
device. Let's see how much that change will break.
|
|
If an pointer event is being processed during a device grab, don't deliver it
to the focus window, even if the device has a focus class. Reason being that
some pointers may have a focus class, thus killing drag-and-drop.
|
|
an X11 window in another space.
(cherry picked from commit df21312c8b0e9ef0c809bfc57cdf64f27db0d8a7)
(cherry picked from commit 2d4194a8d124e7a9c7cd1b83635ba6957aa4ae1c)
|
|
Add Prox events to the if-clauses with the other events
that are usually sent from the input devices.
Ensure that the event deliverers won't try to deliver
events of type '0' (some extended events doesn't have
an equivalent core-type)
Small modification by Peter Hutterer.
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
|
|
|
|
This can be done by UngrabDevice, no need for separate codepaths.
|
|
The latter is used to increase the amount of allocated memory for the event
list. This will be needed for ClassesChangedEvents that can be of more or less
arbitrary size (larger than 32 anyway).
|
|
Rather than letting the DDX allocate the events, allocate them once in the DIX
and just pass it around when needed.
DDX should call GetEventList() to obtain this list and then pass it into
Get{Pointer|Keyboard}Events.
|
|
|
|
If a mask was set for the NULL device, then we pretend the mask is set for all
devices.
|
|
The correct thing would be to return the ClientPointer. However, if the client
for some reason has a core grab on another device (e.g. as result of a passive
grab), return the coordinates of the grabbed device instead.
This makes the use of nautilus a bit saner.
|
|
|
|
This finally plugs a memory hole created by grabs registering for generic
events.
|
|
If the window being changed is set as the motion hint window for any device,
the device's motion hint window is set to NULL. Which is kinda what the old
code did, except that it did it with only the VCP.
|
|
Unfortunately, this requires a change in the TCE API, and thus a change in all
callers. Tough luck.
|
|
Helps a bit in tracking down bugs.
|
|
This is a significant shift in how input events are perceived. The common
approach was to treat a core event as a different entity than the XI event.
This could result in the XI event being delivered to a different client than
the core event. This doesn't work nicely if they come from the same device.
Instead, we treat an input event as a single event, that is delivered through
two separate APIs. So when delivering an event, we first try the XI event,
then the core event. If the window want's neither, we go to the parent and
repeat. Once either core or XI has been delivered, the processing stops.
Important: Different to the previous method, if a client registers for core
button events, the parent window will not get XI events. This should only
cause problems when you're mixing core and XI events, so don't do that!
Generic events don't fit into this yet, they cause me headaches.
|
|
This should restore the correct passive grab processing. When checking for
passive grabs, the core event is emulated and we check first for XI grabs on
the window, then for core grabs. Regardless of which event activates the grab,
the XI event is stored in the device's EQ.
When replaying the event, we take the XI event and replay it on the next
window, again including the emulation of the core event.
|
|
Pairings don't exist anymore and the documented issue is a non-issue now.
|
|
Stops segfaulting when using xrandr. Yay.
|
|
Merge detritus from last pull.
|
|
Conflicts:
XTrap/xtrapddmi.c
Xext/security.c
Xext/xprint.c
Xext/xtest.c
Xext/xvdisp.c
Xi/exevents.c
Xi/grabdevb.c
Xi/grabdevk.c
Xi/opendev.c
Xi/ungrdev.c
Xi/ungrdevb.c
Xi/ungrdevk.c
dix/cursor.c
dix/devices.c
dix/dixutils.c
dix/events.c
dix/getevents.c
dix/main.c
dix/window.c
hw/xfree86/ramdac/xf86Cursor.c
include/dix.h
include/input.h
include/inputstr.h
mi/midispcur.c
mi/miinitext.c
mi/misprite.c
render/animcur.c
xfixes/cursor.c
xkb/xkbAccessX.c
|
|
|
|
|
|
If we have one global filter, one pointer may change the filter value and
affect another pointer.
Reproduceable effect:
blackbox and xterm, start dragging xterm then click anywhere with the other
pointer (attached to different masterd device!). The button release resets
the filter[Motion_Filter(button)] value, thus stopping dragging and no event
is sent to the client anymore.
Having the filters set per device gets around this.
|
|
Removing my copyright message for now, should eventually be in line with the
rest of the messages.
|
|
No escaping XINPUT anymore.
|
|
|
|
|
|
In some cases (e.g. using x2x) the previous model broke, with a window ending
not counting down to 0 anymore. Special treatment for NotifyUngrab seems to
help here.
Current solution: If a NotifyGrab is to be sent ignore it. If a NotifyUngrab
enter is sent, only adjust the semaphore if it is on 0. Likewise, do the same
for a NotifyUngrab leave if the semaphore is on 1. This seems to work alright
so far.
|
|
Conflicts:
hw/xnest/Pixmap.c
include/dix.h
|
|
|
|
|
|
This can happen if we check for a passive core grab and our device is a
floating slave device. Doesn't really change anything as SDs can't send core
events but it stops the server from segfaulting.
|
|
|
|
Conflicts:
Xi/opendev.c
|
|
Conflicts:
Xi/extinit.c
Xi/grabdev.c
Xi/setmode.c
Xi/ungrdev.c
dix/devices.c
dix/events.c
dix/getevents.c
include/dix.h
mi/midispcur.c
mi/misprite.c
xkb/xkbActions.c
xkb/xkbEvents.c
xkb/xkbPrKeyEv.c
|
|
Conflicts:
dix/dispatch.c
dix/property.c
hw/xfree86/common/xf86VidMode.c
include/xkbsrv.h
render/glyph.c
xkb/xkbActions.c
|
|
(cherry picked from commit 8840829ab93c4eb62eb58753c015da5307133fe5)
|
|
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 5ee409794ee604fcf84886f70429fc2d6b1ff4f1)
|
|
|
|
A pointer device should be able to send events while the client has a core
grab on a keyboard device, and likewise.
|
