|
libxkbcommon
1.13.1
LibraryimplementingtheXKBspecificationforparsingkeyboarddescriptionsandhandlingkeyboardstate
|
{html:2}
See: ./introduction-to-xkb.md "Introduction to XKB".
See: terminology.
The xkbcommon project does not provide keyboard layouts. Standard keyboard layouts are provided by the xkeyboard-config project. See contributing to xkeyboard-config for further information.
They are usually located at /usr/share/xkeyboard-config-2, or /usr/share/X11/xkb on older setups.
There are currently some issue with modifier-only shortcuts. See this issue.
There could be many reasons!
libxkbcommon may not be able to load your configuration due to an issue (file not found, syntax error, unsupported keysym, etc.). Please use our ./debugging.md "debugging tools" to get further information.
Note that the xkbcommon project does not provide keyboard layouts. See the xkeyboard-config project for further information.
This is most probably an issue with your Compose configuration. If you customized it, do not forget to restart your session before trying it.
Please use our ./debugging.md "debugging tools" with the option --enable-compose to get further information.
This project does not provide any keyboard layout database:
See also the ./keymap-text-format-v1-v2.md "keymap text format" documentation for the syntax and the ./compatibility.md "compatibility" page for the supported features.
Use our ./debugging.md "debugging tools".
🚧 TODO
Since version 1.8 the RMLVO API does not support parsing multiple groups per key anymore, because it may break the expectation of most desktop environments and tools that the number of groups should be equal to the number of configured layouts. See #262 and #518 for further details.
The following explain how to migrate for some common use cases:
If you define multiple layouts in a single xkb_symbols section, you should instead split them into individual sections and update your keyboard settings to use each such layout.
E.g. if you have a single layout variant1_variant2 defined as:
then you should split it into:
See also User-configuration to make the layouts discoverable for easy configuration in your keyboard settings app.
If you define an option that affect multiple groups at once in a single xkb_symbols section, you should split that section and update the corresponding rules for each layout index.
E.g. if one has the following group switcher on CapsLock key:
and the corresponding custom rules:
then it should be migrated to:
with the corresponding custom rules:
Consider the following use cases:
Caps_Lock is on the second level of some key, and Shift is latched, pressing the key locks Caps while also breaking the Shift latch, ensuring that the next character is properly uppercase.ISO_Level5_Latch is on the third level of <AC04>. So if a level 3 latch (typically on <RALT>) is used to access it, the level 5 must break the previous level 3 latch, else both latches would be active: the effective level would be 7 instead of the intended 5.Both uses cases can be implemented using the following features:
VoidAction(): to break latches.Patch that fixes the first use case:
xmodmap -pm There is no strict equivalent. Since 1.10 xkbcli compile-keymap has the option --modmaps to print the modifiers maps from a keymap, but it does not print keysyms. In order to get the output for the current keymap, use it with xkbcli dump-keymap-*:
xmodmap -e "…" xmodmap /path/to/file xkbcli does not modify the display server keymap. setxkbmap -print -layout …Since 1.9 one can use the --kccgst option:
setxkbmap -query No equivalent: xkbcli only query raw keymaps and has no access to the original RMLVO settings.
setxkbmap -layout … No equivalent: xkbcli does not modify the display server keymap. One must use the tools specific to each display server in order order to achieve it.
If you use a custom layout, please have a look at User-configuration, which enables making custom layouts discoverable by keyboard configuration GUI.
xkbcomp -xkb /path/to/keymap/file - xkbcomp -xkb $DISPLAY - xkbcomp - $DISPLAY xkbcomp /path/to/keymap/file $DISPLAY No equivalent: xkbcli does not modify the display server keymap. One must use the tools specific to each display server in order order to achieve it. Please have a look at User-configuration, which enables making custom layouts discoverable by keyboard configuration GUI.
xev -event keyboard The virtual modifiers encoding, (also: mappings to real modifiers in X11 jargon) is an implementation detail. However, some applications may require it in order to interface with legacy code.
Use the dedicated functions xkb_keymap::xkb_keymap_mod_get_mask() (since 1.10) and xkb_keymap::xkb_keymap_mod_get_mask2() (since 1.11).
Use the following snippet:
``c // Find the real modifier mapping of the virtual modifierLevelThree` #include <xkbcommon/xkbcommon.h> #include <xkbcommon/xkbcommon-names.h> const xkb_mod_index_t levelThree_idx = xkb_keymap_mod_get_index(keymap, XKB_VMOD_NAME_LEVEL3); const xkb_mod_mask_t levelThree = UINT32_C(1) << levelThree_idx; struct xkb_state* state = xkb_state_new(keymap); assert(state); // Please handle error properly xkb_state_update_mask(state, levelThree, 0, 0, 0, 0, 0); const xkb_mod_mask_t levelThree_mapping = xkb_state_serialize_mods(state, XKB_STATE_MODS_EFFECTIVE); xkb_state_unref(state); ```
There is no dedicated API, since the use cases are too diverse or niche. Nevertheless, the following snippet provide a minimal example to achieve it.
1.8.10