Unplug a mouse, then warp the pointer and the warp pointer code will try
to update the position of the last slave device associated with the
master. That pointer will be stale and the X server will crash.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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.
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
We only have one set of default rules options in xkb. When the second keyboard
is brought up with Xkb options specified, these new options overwrite the old.
In future server generations, the rules used for the VCK are a mixture of the
default ones and ones previously specified for other keyboards. Simply
resetting the xkb default rules to NULL avoids this issue.
Reproducable by setting XkbLayout "de" and XkbVariant "nodeadkeys". In the
second server generation, the VCK has "us(nodeadkeys)". This again produces a
SIGABRT when the first key is hit.
I could not figure out why the SIGABRT happens. This patch is avoiding the
issue rather than fixing it.
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.
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.
Sometimes we didn't have a cursor when coming back from suspend. Reason was
that the suspend caused the server to lose the device that was attached to the
VCP, and a RemoveDevice() would then set the cursor to NULL.
Solution: only set the cursor to NULL if we actually own the sprite.
We pass in the client that wants to create the device anyway, lets use the
parameter instead of hardcoding the serverClient.
Wow. I hope this is merge detritus, otherwise it'd be a sign that I didn't
have enough coffee that day.
When a new device is added, calculate the event size needed if a DCCE event is
sent and set the EQ's event size to this minimum. This avoids reallocs when a
event is sent (which may happen during a SIGIO).
This variable was used originally to determine which client is allowed to
change the pointer-keyboard pairing. For now, we just let anyone change it and
see how that works out.
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.
The DDX (xfree86 anyway) maintains its own device list in addition to the one
in the DIX. CloseDevice will only remove it from the DIX, not the DDX. If the
server then restarts (last client disconnects), the DDX devices are still
there, will be re-initialised, then the hal devices come in and are added too.
This repeats until we run out of device ids.
This also requires us to strdup() the default pointer/keyboard in
checkCoreInputDevices.
X.Org Bug 14418 <http://bugs.freedesktop.org/show_bug.cgi?id=14418>
The device classes aren't deleted anymore on a class change, so there's no
need to store the MD's original classes. We should however restore the MD to
sane defaults when disconnecting the last device, consider this as TODO item.
Instead of a simple counter, use bits to keep track of which device is where
etc. When device enters a window (or sets focus), the bit matching the device
is set, when it leaves again, it is unset. If there are 0 bits set, then
Leave/Enter/Focus events may be sent to the client.
Same theory as before, but this should get around the insanity with
Grab/Ungrab special cases. Those cases are basically untested though.
InitializeSprite won't create a new one if it already exists, with the result
of overwriting the master's sprite. This master sprite is then assigned to the
floating slave, and freed when the slave is reattached later.
Setting the sprite to NULL forces InitializeSprite to alloc a new one, and
this one can be freed without further repercussions.
XkbFinishDeviceInit does the following:
xkbi->kbdProc= pXDev->kbdfeed->CtrlProc;
pXDev->kbdfeed->CtrlProc= XkbDDXKeybdCtrlProc;
If we directly copy the device classes for the VCK, pXDev->kbdfeed->CtrlProc
at the time of copying is still XbkDDXKeybdCtrlProc. So at some point
XkbDDXKeybdCtrlProc is called, and calls itself, and calls itself, and...
Setting the device's classes to NULL seems to fix things. The memory isn't
lost, it gets stored into the devPrivates and freed at device closing time.
Before we enable the device through the driver, we size it up and make sure
that the events in the event list contain enough bytes for a possible
ClassesChangedEvent lateron.
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.
