XKB support
Relative to the XKB 1.0 specification implemented in current X servers, xkbcommon has removed support for some parts of the specification which introduced unnecessary complications. Many of these removals were in fact not implemented, or half-implemented at best, as well as being totally unused in the standard dataset.
Notable removals
- Keymap components are no longer mandatory, e.g. a keymap without a
xkb_types section is legal.
- geometry support
- there were very few geometry definitions available, and while xkbcommon was responsible for parsing this insanely complex format, it never actually did anything with it
- hopefully someone will develop a companion library which supports keyboard geometries in a more useful format
- KcCGST (keycodes/compat/geometry/symbols/types) API
- use RMLVO instead; KcCGST is now an implementation detail
- including pre-defined keymap files
- XKM support
- may come in an optional X11 support/compatibility library
- around half of the interpret actions
- pointer device, message and redirect actions in particular
- non-virtual modifiers
- core and virtual modifiers have been collapsed into the same namespace, with a 'significant' flag that largely parallels the core/virtual split
- radio groups
- completely unused in current keymaps, never fully implemented
- overlays
- almost completely unused in current keymaps
- key behaviors
- used to implement radio groups and overlays, and to deal with things like keys that physically lock; unused in current keymaps
- indicator behaviours such as LED-controls-key
- the only supported LED behaviour is key-controls-LED; again this was never really used in current keymaps
- xkbcommon has stronger type checks, so floating-point numbers cannot be used where an integer is expected.
- exponent syntax for floating-point numbers is not supported.
- legacy merge mode
alternate is not supported and is ignored.
- support the merge mode replace in include statements via the prefix
^, in addition to the standard merge | and override + modes.
On the other hand, some features and extensions were added.
Notable additions
- 32-bit keycodes
- extended number of modifiers (planned)
- extended number of groups (planned)
- multiple keysyms and actions per level
- such levels are ignored by x11/xkbcomp.
- key names (e.g.
<AE11>) can be longer than 4 characters.
- keysyms can be written as their corresponding string, e.g.
udiaeresis can be written "ΓΌ". A string with multiple Unicode code points denotes a list of the corresponding keysyms. An empty string denotes the keysym NoSymbol.
Rules support
Additions
! include statement.- Support the merge mode replace via the prefix
^, in addition to the standard merge | and override + modes.
- Additional wild cards:
<none> matches empty value;<some> matches non-empty value in every context.<any> matches optionally empty value in every context, contrary to the legacy * wild card which does not match empty values for layout and variant;
Compose support
Relative to the standard implementation in libX11 (described in the Compose(5) man-page), some features are not supported:
- the (! MODIFIER) syntax
- parsed correctly but ignored.
- using modifier keysyms in Compose sequences
- several interactions with Braille keysyms
