After UpdateDeviceState, the device has the current position in absolute
coordinates, the event has the correct valuator data to be delivered to the
client.
This is better than the approach implemented with
8973a3f798 which disabled XI altogether for 1.x.
Instead, return a device list that resembles a traditional XI setup on pre XI
2.0 servers. If the client tries to open a device other than a floating SD,
return a BadDevice error.
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.
