• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1# Compatibility
2
3Relative to the XKB 1.0 specification implemented in current X servers,
4xkbcommon has removed support for some parts of the specification which
5introduced unnecessary complications.  Many of these removals were in fact
6not implemented, or half-implemented at best, as well as being totally
7unused in the standard dataset.
8
9Notable removals:
10- geometry support
11  + there were very few geometry definitions available, and while
12    xkbcommon was responsible for parsing this insanely complex format,
13    it never actually did anything with it
14  + hopefully someone will develop a companion library which supports
15    keyboard geometries in a more useful format
16- KcCGST (keycodes/compat/geometry/symbols/types) API
17  + use RMLVO instead; KcCGST is now an implementation detail
18  + including pre-defined keymap files
19- XKM support
20  + may come in an optional X11 support/compatibility library
21- around half of the interpret actions
22  + pointer device, message and redirect actions in particular
23- non-virtual modifiers
24  + core and virtual modifiers have been collapsed into the same
25    namespace, with a 'significant' flag that largely parallels the
26    core/virtual split
27- radio groups
28  + completely unused in current keymaps, never fully implemented
29- overlays
30  + almost completely unused in current keymaps
31- key behaviors
32  + used to implement radio groups and overlays, and to deal with things
33    like keys that physically lock; unused in current keymaps
34- indicator behaviours such as LED-controls-key
35  + the only supported LED behaviour is key-controls-LED; again this
36    was never really used in current keymaps
37
38On the other hand, some features and extensions were added.
39
40Notable additions:
41- 32-bit keycodes
42- extended number of modifiers (planned)
43- extended number of groups (planned)
44- multiple keysyms per level
45  + such levels are ignored by x11/xkbcomp.
46- key names (e.g. `<AE11>`) can be longer than 4 characters.
47
48## Compose support
49
50Relative to the standard implementation in libX11 (described in the
51Compose(5) man-page), some features are not supported:
52
53- the (! MODIFIER) syntax
54    + parsed correctly but ignored.
55- using modifier keysyms in Compose sequences
56- several interactions with Braille keysyms
57