Files
xserver_xsdl/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
..
2008-03-04 18:11:10 +10:30
2008-02-17 22:52:07 +02:00
2008-01-03 17:04:54 +10:30
2008-01-03 17:04:54 +10:30
2008-01-03 17:04:54 +10:30
2007-06-29 14:06:52 -04:00
2007-06-29 14:06:52 -04:00
2008-03-04 18:11:10 +10:30
2008-07-23 13:38:38 -04:00
2008-03-05 23:57:15 -05:00
2003-11-14 15:54:54 +00:00
2008-09-22 08:37:29 +09:30
2008-02-17 22:52:07 +02:00
2008-07-23 13:38:38 -04:00
2008-02-17 22:52:07 +02:00
2008-02-17 22:52:08 +02:00
2008-03-04 18:11:10 +10:30
2008-03-04 18:11:10 +10:30
2008-02-17 22:52:08 +02:00

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.