xserver/xkb
Peter Hutterer 30c3c13f10 xkb: squash canonical types into explicit ones on core reconstruction.
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.
2008-09-26 09:33:39 +09:30
..
Makefile.am
README.compiled
XKBAlloc.c
XKBGAlloc.c
XKBMAlloc.c
XKBMisc.c xkb: squash canonical types into explicit ones on core reconstruction. 2008-09-26 09:33:39 +09:30
ddxBeep.c
ddxCtrls.c
ddxDevBtn.c
ddxFakeBtn.c
ddxFakeMtn.c
ddxInit.c
ddxKeyClick.c
ddxKillSrv.c
ddxLEDs.c
ddxList.c
ddxLoad.c
ddxPrivate.c
ddxVT.c
maprules.c
xkb.c
xkb.h
xkbAccessX.c
xkbActions.c
xkbDflts.h
xkbEvents.c
xkbInit.c
xkbLEDs.c
xkbPrKeyEv.c
xkbPrOtherEv.c
xkbSwap.c
xkbUtils.c
xkbfmisc.c
xkbgeom.h
xkbout.c
xkbtext.c
xkmread.c

The X server uses this directory to store the compiled version of the
current keymap and/or any scratch keymaps used by clients.  The X server
or some other tool might destroy or replace the files in this directory,
so it is not a safe place to store compiled keymaps for long periods of
time.  The default keymap for any server is usually stored in:
     X<num>-default.xkm
where <num> is the display number of the server in question, which makes
it possible for several servers *on the same host* to share the same 
directory.

Unless the X server is modified, sharing this directory between servers on
different hosts could cause problems.