If we update key types from core, and groups 2 - n have a canonical type but
the same symbols as the explicit type of group 1, assume that it was a core
sym duplication according to Section 12.4 of the XKB Protocol Spec.
Ignore the canonical types and pretend there's only one group for the key -
with the explicit key type.
The protocol spec does not cover this case, so we have to guess here.
According to Section 12.4 of the XKB Protocol Spec, if a key only has a single
group but the keyboard has multiple groups defined, the core description of
the key is a duplication of the single group across all symbols. i.e.
G1L1 G1L2 G1L1 G1L2 G1L3 G1L4 G1L3 G1L4
The previous code generated G1L1 G1L2 G1L3 G1L4 G1L3 G1L4, leading to
"invented" groups when the process is reversed.
Note that this creates wrong key types on reconstruction from core to xkb,
i.e. any single-group key with a key type that is not one of the canonical
four (Sec 12.2.3), will get the assigned type on group 1, and a canonical type
for the other gruops.
X.Org Bug 14373 <http://bugs.freedesktop.org/show_bug.cgi?id=14373>
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
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.
Conflicts:
Xext/xprint.c (removed in master)
config/hal.c
dix/main.c
hw/kdrive/ati/ati_cursor.c (removed in master)
hw/kdrive/i810/i810_cursor.c (removed in master)
hw/xprint/ddxInit.c (removed in master)
xkb/ddxLoad.c
When something went wrong building a keymap, try to explain to the user
what it actually was, instead of the dreaded 'Failed to load XKB keymap'
catch-all.
- map can be NULL in some cases, so don't try to dereference it.
- don't default to inputInfo.keyboard
This is firefighting, I presume something in the class copy may have gone
wrong to get a NULL map in the first instance?
XkbFinishDeviceInit is called once when the device is initialised, but also
when a class copy causes the key class of a device to change. In this case, overwriting the CtrlProc of the KeybdFeedbackClass with XkbDDXKeybdCtrlProc sets up a nice recursive loop of XkbDDXKeybdCtrlProc calling itself until the cows come home.
If input processing is frozen, only wrap realInputProc: don't smash
processInputProc as well. When input processing is thawed, pIP will be
rewrapped correctly.
This supersedes the previous workaround in 50e80c9.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
An astute observer will note that the entirety of XkbCopyKeymap is indented
with spaces, and no tabs whatsoever, and not commit changes which break the
otherwise consistent indentation.
A non-astute observer will note the breakage when the commit mail comes
through with clearly broken indentation.
A polite, non-astute, observer will then fix it.
C'est la vie.
Due to an unwitting sense inversion when eliminating XkbFileInfo, we were
setting the complete wrong keymap on startup (non-XKB map if we had an XKB
map available, or the XKB map if we didn't have any available). Invert the
sense properly, and add two small bits that also went missing in that commit.
