doc/compatibility.md

   1 # Compatibility {#xkbcommon-compatibility}
   2
   3 @tableofcontents{html:2}
   4
   5 ## XKB support {#xkb-v1-compatibility}
   6
   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.
  12
  13 ### Notable removals
  14
  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
  26 - XKM support
  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
  33     core/virtual split
  34 - radio groups
  35   + completely unused in current keymaps, never fully implemented
  36 - overlays
  37   + almost completely unused in current keymaps
  38 - key behaviors
  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
  44
  45 On the other hand, some features and extensions were added.
  46
  47 ### Notable additions
  48
  49 - 32-bit keycodes
  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.
  55
  56 ## Compose support {#compose-support}
  57
  58 Relative to the standard implementation in libX11 (described in the
  59 Compose(5) man-page), some features are not supported:
  60
  61 - the (! MODIFIER) syntax
  62     + parsed correctly but ignored.
  63 - using modifier keysyms in Compose sequences
  64 - several interactions with Braille keysyms