3 Relative to the XKB 1.1 specification implemented in current X servers,
4 xkbcommon has removed support for some parts of the specification which
5 introduced unnecessary complications. Many of these removals were in fact
6 not implemented, or half-implemented at best, as well as being totally
7 unused in the standard dataset.
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
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
28 + completely unused in current keymaps, never fully implemented
30 + almost completely unused in current keymaps
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
38 On the other hand, some features and extensions were added.
42 - extended number of modifiers (planned)
43 - extended number of groups (planned)
44 - multiple keysyms per level
45 + this requires incompatible dataset changes, such that X11 would
46 not be able to parse these