We may need more than one handler to deal with a property (e.g. one in the
driver, one in the DIX), so get the handlers into a linked list and call them
one-by-one. This is of course slightly less entertaining than the hilarious
WRAP/UNWRAP game we play in other parts of the server.
XIRegisterPropertyHandler/XIUnregisterPropertyHandler are the interface
drivers/the DIX should use to attach themselves to the device.
XIDeleteAllDeviceProperties destroys everything, including the handlers.
Basically just copied from randr properties, with minor changes only.
Each device supports arbitrary properties that can be modified by clients.
Modifications to the properties are passed to the driver (if applicable) and
can then affect the configuration of the device.
Note that device properties are limited to a specific device. A property set
on a slave device does not migrate to the master.
Basically just copied from randr properties, with minor changes only.
Each device supports arbitrary properties that can be modified by clients.
Modifications to the properties are passed to the driver (if applicable) and
can then affect the configuration of the device.
Note that device properties are limited to a specific device. A property set
on a slave device does not migrate to the master.
This fixes a severe issue - when the client died the event mask didn't get
unregistered and a future event would dereference dangling pointers. By
storing the event masks in the resource system we can free them when the
client dies.
Using id = 0 only worked pre-MPX since XInput didn't allow XOpenDevice for the
core devices (0 and 1). Now we can now legally register for events so we may
overwrite our device-independent classes with the ones selected for the VCP.
So, increase the EMASKSIZE to MAX_DEVICES + 1 and use MAX_DEVICES as the ID
when we don't have a device.
Mixing usage where some parts of the code treated this field as a bitmask
and other parts as an array of card8 was wrong, and as the wire protocol
wanted bitmasks, it was less invasive to switch the newer counting code use
booleans.
Master devices track slave buttons by waiting for all slave buttons to be
released before delivering the release event to the client.
This also removes the state merging code in DeepCopyDeviceClasses -- that
code was changing master device state without delivering any events,
violating protocol invariants. The result will be that existing slave
button state which does not match the master will not be visible through the
master device. Fixing this would require that we synthesize events in this
function, which seems like a bad idea. Note that keyboards have the same
issue.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
device->button->down used to be a 32-byte bitmask with one bit for each
button. This has changed into a 256-byte array, with one byte assigned for
each button. Some of the callers were still using this array as a bitmask
however, this is fixed with this patch.
Thanks to Keith Packard for pointing this out. See also:
http://lists.freedesktop.org/archives/xorg/2008-June/036202.html
Button events were mapped once in GetPointerEvents and then again in
UpdateDeviceState. While it might make sense to just fix up UpdateDeviceState,
it turns out to be better to leave the raw button number in the event because
DGA reports raw device events without button translation, and so when it calls
UpdateDeviceState, the button down counts get scrambled and buttons get stuck
down.
See also:
http://lists.freedesktop.org/archives/xorg/2008-June/036201.html
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
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.
