Turns out some programs don't like this change. gnome-settings-daemon crashes
hard if you tell it that XI doesn't exist. So, tell them we have XI, but leave
the other change (the one that pretends no devices are available).
This reverts commit 8973a3f798.
Sorry. With the huge changes in the device handling I honestly don't know how
to support XI and XI2 alongside. So let's just pretend XI doesn't exist if a
client doesn't request it supporting XI2.
Remember the version the client sent to us, so we can adjust our replies
accordingly. This requires the client to use the {major|minor}Version fields
in the GetExtensionVersion request. However, they were padding before, so we
must assume they are garbage if nbytes is non-zero. If nbytes is zero, the
client is probably a new client and we can handle it correctly.
Some leftover code from the previously used alloc/free device classes left us
with a incorrect button count. So a button release didn't come through if
a different pointer was moved after the button press.
Rather than freeing/allocing classes each time the device capabilities need to
swap, store them in the devPrivates system.
When a class is unused, it is pushed into the devPrivates, and later recovered
when needed again. This saves us a lot of memory allocations/frees, admittedly
on the cost of some memory.
We don't free the class anymore, so just store the previous pointers, do the
memcpy from the SD and then restore the pointers.
Plugs a memleak too, before xkbInfo was never freed.
Setting it to NULL isn't correct either. The correct behaviour is to realloc
it to the size necessary (or newly alloc it/free it). Otherwise we have a
memleak.
XkbInitIndicatorMap (in XkbInitDevice) calls XkbFindSrvLedInfo. This accesses
the devices kbdfeed struct, which is all nice and dandy if it is NULL. When
copying the device classes however, kbdfeed may not be NULL and thus
XkbFindSrvLedInfo goes on its merry way to do whatever it does.
By copying kbdfeed first, we avoid XkbFSLI to reference the "old" kbdfeed
struct of the previous SD.
Blindly copying will override the focus setting of the master. If there's XI
applications running, they may set the SD focus, while leaving the
MD's focus as it was. In this case, after a class swap we still want to get
the MD's events to the same window as before.
Floating SDs are paired with themselves, so the paired device may not be a
proper keyboard or mouse. Put some extra checks in to avoid dereferencing a
nullpointer later.
Some pointer devices have key classes (e.g. MS Optical Desktop 2000). The
previous test was performed as Error if ptr -> keybd or keybd -> ptr. This
doesnt work with such devices. New test is Succeed if ptr->ptr or
keybd->keybd.
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.
If two devices are attached to the same master device, pressing button 1 on
each of them leads to two button presses from the same device. Some apps
really don't like that.
So we just put a counter in place and only send the first press and the last
release.
The window ID includes the client ID anyway, so we might as well just look up
the client directly instead of trying to get the window first and the client
from the window.
This also fixes a possible issue with XACE. If the client had permission to
write on the client but not on the window, the previous approach would have
failed.
All the rest of XI uses rc and returns rc in case of error, so make
mpx-related stuff comply. This stops the rest of XI sending the error
manually.
This is just a cosmetic change to be in line with the rest.
This doesn't change much, as the struct previously given has the same size as
the ones now anyway. Still, we should be pendantic.
Thanks to Simon Thum for reporting.
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.
Setting it to the size of a pointer is an interesting but equally wrong
approach. Luckily Xlib never used this field anyway so nobody got hurt so far.
Spotted by Simon Thum.
(cherry picked from commit 0f2398d06c)
Setting it to the size of a pointer is an interesting but equally wrong
approach. Luckily Xlib never used this field anyway so nobody got hurt so far.
Spotted by Simon Thum.
We free the ValuatorClassRec quite regularly. If a SIGIO is handled while
we're swapping device classes, we can bring the server down when we try to
access lastx/lasty of the master device.
Sometimes (e.g. on my debian ppc box) maxKeysPerModifier of the SD is 0. So we
try to malloc(0), bringing the whole server down with a FatalError because it
looks as if the malloc failed. This is bad, so only alloc if we actually have
something to alloc.
Turns out it's really really hard synchronising device state across multiple
duplicated events if they all share the same struct. So instead of doing so,
when the SD changes deep-copy all it's classes into the MD. The MD then has
the same capabilities, but the state can be set separately. This should fix
xkb, key state, repeat etc. problems.
Updating the device state allows us to remove the SwitchCoreKeyboard from the
event gathering, it's all done during event processing now.
The master needs to have the same devPrivate as the slave, in case a client
issues a request that goes down to the driver.
Example: if a driver wants to ring the keyboard bell, it'll pick a keyboard.
The KeyClassPtr will direct it to the matching method in the driver, but
because the MD doesn't have the devPrivate set the driver segfaults.
Even if all drivers were updated to not dereference the nullpointer, nothing
would actually ever happen.
To avoid this, we flip the master's public.devPrivate to the last SDs
devPrivate.
POE now only deals with processing the event and calling the appropriate
delivery methods. Actually modifying the device state is done in
UpdateDeviceState. This separation should make it easier to avoid setting the
state twice when master events are processed.
Each time a different slave device sends through a master, an
DeviceClassesChangedEvent is enqueued. When this event is processed, all
classes of the matching master device are changed, and the event is sent to
the clients.
Next time the master is queried, it thus shows the evclasses of the last slave
device. The original classes are stored in the devPrivates.
TODO: if all slave devices are removed, the master's original classes need to
be restored.
Removes "LookupKeyboardDevice" and "LookupPointerDevice" in favor of
inputInfo.keyboard and inputInfo.pointer, respectively; all use cases
are non-XI compliant anyway.
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
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.
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 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
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.
We need this for clients that need to set the ClientPointer but don't have a
window on display yet. If used, it will set the device as the ClientPointer
for the requesting client.
Add XGE handling in DeliverGrabbedEvent.
We can now grab something selecting XGE events, but the current code is a
bit messy and doesn't work too well yet.
Add RawDeviceEvent (pointers only for now).
This commit changes the event queue to use EventLists instead of xEvent
arrays. Only EQ is affected, event delivery still uses xEvent* (look for
comment in mieqProcessInputEvent).
RawDeviceEvents deliver driver information to the client, without clipping or
acceleration.
Requires moving the spriteTrace into the DeviceIntRec and adjusting a few
functions to take in device argument, most notably XYToWindow().
Cursor rendering on the second screen is busted.
Calloc cursor struct to ensure devPrivates are zeroed out and don't
increase the refcnt for devices automatically when allocating a new
cursor. Use new DeviceIsPointerType() to detect if device is a pointer
_before_ device has been activated and can thus be identified and set
up grab functions accordingly. This way we can increase the refcnt
when we get a pointer grab.
dix: IsPointerDevice and IsKeyboardDevice, use same ways to identify type
of device as XI does for the XListInputDevices reply.
Autopair each non-pointer device with VCP when activating, pair with
real device after activation.
Don't return non-keyboard devices when calling GetPairedKeyboard or
PickKeyboard, otherwise we segfault for 'evdev brain'.
state field in the event, rather than using the virtual devices.
ProcessPointerEvent: name argument "device" instead of "other".
Add GetPairedKeyboard().
otherwise a Xi grab may overwrite or release a core grab.
Replace grab and associates with coreGrab and deviceGrab structures,
adjust rest of dix/Xi/etc to compile.
xfree86: Don't check for core devices, we'll have the virtual ones anyway.
If we check, the first mouse device is duplicated and sends
double events.
dix: set coreGrab flag for grabs caused by GrabPointer and button presses.
remove virtual core devices from device list, only real devices are in
the list now.
Auto-pair each keyboard with a real pointer if one is available,
provides multiple keyboards automatically after startup if devices
are configured.
fix GuessFreePointerDevice() to do what it's supposed to do.
mi: fix: call miPointerMove from miPointerWarpCursor.
fix: remove unused id field from miCursorInfoRec
don't update sprite for virtual core pointer.
Adding PointerKeyboardPairingChanged event
Correct error values for XWarpDevicePointer
dix: Adding device argument to SendMappingNotify
Adding spriteOwner flag to devices
Some renaming and cleaning up in extinit.c
MPXLastEvent added
Xi: ShouldFreeInputMask() from XI is not static any more, used in mpx
dix: GetPointerEvents() allocates MPX event for MPX devices.
DeliverDeviceEvents() caters for MPX devices.
fixed miSpriteRealize to use passed pDev argument instead of looping.
dix: changed sprite dependency and added MPX functionality to parts of
events.c (XineramaChangeToCursor, XineramaCheckPhysLimits,
XineramaConstrainCursor)
Xi: fix: accessing other->buttons for keyboard segfaulted the server
added SpriteRecs for MPX devices
changed sprite dependency and added MPX functionality to parts
of events.c (ConfineToShape, PostNewCursor, XineramaCheckMotion,
CheckMotion, XineramaChangeToCursor, ChangeToCursor, CheckPhysLimits,
PointerConfinedToScreen)
added DeviceIntRec param to GetSpritePosition(). This required some
minor changes in ddx, xtest, xkb and xfixes.
mi: changed miPointer to pointer instead of static struct.
Update the DEVICE_ABS_CALIB stuff to include the new elements.
New DEVICE_ABS_AREA support.
dev->touchscreen becomes dev->absolute, with _CALIB and _AREA stuff in it.
Update xfree86 to compile with this, kdrive needs an update too.
Move SendEventToAllWindows and FindInterestedChildren from chgptr to exevents,
so the DIX can more easily use it.
Clean up two warnings (type mismatch, unused variable) in exevents.c.
Allow new devices to be added after a device that _wasn't_ the last on the
list was removed, by ensuring inputInfo.numDevices always increases, and
never decreases.
Add DEVICE_TOUCHSCREEN and DEVICE_CORE controls to the Xi code, and the
TouchscreenClassRec and a coreEvents flag, to toggle propagation of core
events.
Get rid of almost all uses of these definitions. They're still defined for
delinquent out-of-tree drivers, and also for the Mesa build. As well as
for miinitext.c. But largely gone.
Add XSERV_t, TRANS_SERVER, TRANS_REOPEN to quash warnings.
Add #include <dix-config.h> or <xorg-config.h>, as appropriate, to all
source files in the xserver/xorg tree, predicated on defines of
HAVE_{DIX,XORG}_CONFIG_H. Change all Xfont includes to
<X11/fonts/foo.h>.
change "foo.h" to <X11/foo.h> for core headers, e.g. X.h, Xpoll.h;
change "foo.h", "extensions/foo.h" and "X11/foo.h" to
<X11/extensions/foo.h> for extension headers, e.g. Xv.h;
change "foo.[ch]" to <X11/Xtrans/foo.[ch]> for Xtrans files.
