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.
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.
XkbInitKeyboardDefviceStruct may call FatalError if it fails. FatalError then
cleans up all the devices, resulting in a segfault if the pointer is
uninitialised.
Old code was fundamentally broken, fixes now are:
- free the MDs current device classes
- copy the device classes instead of flipping the pointers
- check for the old MD, not the new one.
Anything in dev->key, dev->valuator etc. of a MD must always be a copy of the
original class. The intial classes of an MD (the ones set up before an SD is
attached) as well, as we may have to restore them if no SD is attached
anymore.
