doc/compat.md

   1 # Compatibility
   2
   3 Relative to the XKB 1.0 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.
   8
   9 Notable 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
  38 On the other hand, some features and extensions were added.
  39
  40 Notable 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
  50 Relative to the standard implementation in libX11 (described in the
  51 Compose(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