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.
This commit fixes two problems:
1) XTFI used to assemble the event itself, then passed it to the device. It's
much easier to just pass the variables into GPE/GKE and let the DIX do the
rest.
2) XTFI would pass the VCP/VCK as default device to event processing. As a
result, updating LEDs would be updated on the VCK, not on the actual keyboard.
Instead, we now pass the events through the last-used SD, thus toggling the
LEDs on the last keyboard that sent through this MD.
Also some cleanup in XTFI to merge validity checks a bit closer together
rather than having several different sections.
This breaks XTestFakeMotion with Xinerama though.
X.Org Bug 16145 <http://bugs.freedesktop.org/show_bug.cgi?id=16145>
The problem happens if Monitor/Card combo doesn't provide EDID info,
and the XFree86-VidModeExtension extension is used.
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.
Since we can't predict how many valuators may be in a future SD attached to an
MD, we need to preallocate a history buffer that is large enough to keep
MAX_VALUATORS coordinates per event.
In addition, the history buffer needs to memorize the coordinate ranges at the
time, thus requiring MDs to store (min_val, max_val, current_val, time)
instead of (current_val, time) for each motion history entry.
This commit only fixes the allocation.
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.
Recording damage from other operations (e.g. creating a client damage record)
may confuse the migration code resulting in corruption.
Option "EXAOptimizeMigration" appears safe now, so enable it by default. Also
remove it from the manpage, as it should only be necessary on request in the
course of bug report diagnostics anymore.
GNU/kFreeBSD defines __FreeBSD_kernel__, but not __FreeBSD__.
Unify preprocessor conditionals between variable declaration and use.
Debian bug #482550.
