The core protocol requires absolute values and it's a bit hard to get them if
we only have relative ones in the history. Switch the motion history to
absolute, and if we really need the relative values, we can probably generated
them from the abs. ones in the future.
Add each event to the master's MH as well as to the SDs. In the MD, store
min/max and the actual value. When retrieving the MH, rescale all coordinates
to the current coordinate range and only post those valuators that are
currently active on the device.
With the MD/SD device hierarchy we need control over the generation of the
motion history as well as the conversion later before posting it to the
client. So let's not let the drivers change it.
No x.org driver currently uses it anyway, linuxwacom doesn't either so dumping
it seems safe enough.
Event is always absolute, update the device's valuators (always absolute too),
and then change the deviceValuator event to reflect the device's reporting
mode.
We can't rely on GPE to update device->valuators->axisVal. If a SIGIO occurs
during event processing this may have incoherent results.
This reverts commit f6645ddbf7.
During GetPointerEvents (and others), we need to access the last coordinates
posted for this device from the driver (not as posted to the client!). Lastx/y
is ok if we only have two axes, but with more complex devices we also need to
transition between all other axes.
ABI break, recompile your input drivers.
The state field of the event must specify the state of the devices before the
event occured. With the code as it was, the state would also include the
event (e.g. state from a button press event would show the button as pressed)
Gathering the state before updating the device should fix this.
X.Org Bug 15934 <http://bugs.freedesktop.org/show_bug.cgi?id=15934>
When the opcode squash happened in the protocol, the processing vector got out
of sync for a few requests. As a result, client and server would interpret
requests differently, leading to a couple of BadLength problems.
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.
