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