The current code exposes to inconsistent updates, i.e. if handler N succeeds
but handler N+1 fails in setting the property, an error is returned to the
client although parts of the server now behave as if the property change
succeeded.
This patch adds a "checkonly" parameter to the SetProperty handler. The
handlers are then called twice, once with checkonly set to TRUE.
On the checkonly run, handlers _MUST_ return error codes if the property
cannot be applied. Handlers are not permitted to actually apply the changes.
On the second run, handlers are permitted to apply property changes.
Errors codes returned on the second run are ignored.
Most of its component get copied during CopyKeyClass anyway.
The ones that aren't:
postdown - never changed for virtual devices anyway.
down - shouldn't change that without sending events.
memcpy'ing the struct also copied mapWidth, which means we didn't realloc
during SetKeySymsMap lateron, overwriting the memory assigned to us.
X.Org Bug 16167 <http://bugs.freedesktop.org/show_bug.cgi?id=16167>
A property can only be deleted if any of the following is true:
- if a property is deletable and all handlers return Success.
- if a property is non-deleteable and the all handlers return Success AND the
delete request does not come from a client (i.e. driver or the server).
A client can never delete a non-deletable property.
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.
