This project does not provide any keyboard layout database:
If you want to modify only your user keyboard configuration, see: custom configuration.
If you want to modify the system-wide keyboard configuration, follow the custom configuration but replace $XDG_CONFIG_HOME with <sysconfdir> (usually /etc) in the file locations.
If you want to modify the standard keyboard layout database, please first try it locally (see our debugging tools) and then file a merge request at the xkeyboard-config project.
See also the keymap text format documentation for the syntax and the compatibility page for the supported features.
How do I test my custom layout without installing it?
Why does my key combination to switch between layouts not work?
There are some issues with modifier-only shortcuts: see this bug report.
This can be fixed by using the new parameter lockOnRelease in LockGroup(), available since libxkbcommon 1.11. This will be done at some point in xkeyboard-config.
xkb_compatibility {
interpret ISO_Next_Group {
useModMapMods= level1;
virtualModifier= AltGr;
- action= LockGroup(group=+1);
+ action= LockGroup(group=+1, lockOnRelease);
};
};
Why do my keyboard shortcuts not work properly?
Users have different expectations when it comes to keyboard shortcuts. However, the reference use case is usually a single Latin keyboard layout, with fallbacks for other configurations. These fallbacks may not match users’ expectations nor even be consistent across applications. See The keyboard shortcuts mess for some examples.
Since version 1.14, libxkbcommon offers a dedicated API for Wayland compositors, which enables to customize the layouts to use for keyboard shortcuts.
Issue specific to a single application
File a bug report to the corresponding project. Possible reasons:
Shortcuts do not handle non-Latin keyboard layouts.
Issue specific to multiple applications
First, check if your desktop environment enables to customize shortcuts handling globally, e.g. by selecting specific layouts when some modifiers are active. If it does not, consider filing a bug report to your Wayland compositor project to encourage developers to implement the relevant API.
Why does my keyboard layout not work as expected?
There could be many reasons!
Wrong keyboard model
Nowadays most keyboards follow standards, so prefer using one of the “generic” keyboard models in the XKB configuration to avoid vendor-specific mappings.
There is an issue with your keyboard layout database
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 tools to get further information.
Note that the xkbcommon project does not provide keyboard layouts. See the xkeyboard-config project for further information.
Diacritics/accents do not work
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 tools with the option --enable-compose to get further information.
The application you use does not handle the keyboard properly
Please use our debugging tools to ensure that it is specific to the application.
Your keyboard layout uses features not supported by libxkbcommon
See: compatibility
None of the previous
If none of the previous is conclusive, then this may an issue with libxkbcommon. Please use our debugging tools to provide the maximum information (setup, log, expected/got results) and file a bug report!
What are the <tt>[XKB-nnn]</tt> numbers in the log?
They correspond to the error identifiers. See the error index for the documentation of each error.
How do I swap some keys?
🚧 TODO
How do I define multiple groups per key?
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:
Multiple layouts
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:
xkb_symbols "variant1_variant2" {
key <AD01> {
symbols[Group1] = [U13AA, U13C6],
symbols[Group2] = [ q, Q],
};
// …
};
then you should split it into:
xkb_symbols "variant1" {
key <AD01> { [U13AA, U13C6] };
// …
};
xkb_symbols "variant2" {
key <AD01> { [ q, Q] };
// …
};
See also the instructions to make the layouts discoverable for easy configuration in your keyboard settings app.
Option for multiple layouts
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:
How do I break a latch before triggering another latch or lock?
Consider the following use cases:
If 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.
On the German E1 layout, 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:
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-*:
No equivalent: xkbcli does not modify the display server keymap.
setxkbmap
setxkbmap -print -layout …
Since 1.9 one can use the --kccgst option:
xkbcli compile-keymap --kccgst --layout …
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 Custom configuration, which enables making custom layouts discoverable by keyboard configuration GUI.
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 Custom configuration, which enables making custom layouts discoverable by keyboard configuration GUI.
xev
xev -event keyboard
Automatic session type detection
xkbcli interactive
Wayland session
xkbcli interactive-wayland
X11 session
xkbcli interactive-x11
API
Modifiers
How to get the virtual modifier encoding?
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.
A number used to represent a physical key on a keyboard.
Definition xkbcommon.h:202
How to use keyboard shortcuts from a different layout?
The keyboard shortcuts mess
Keyboard shortcuts in applications are usually using Latin letters. In order to make them work on non-Latin keyboard layouts, each toolkit (Gtk, Qt, etc.) implements its strategy.
However there are some edge cases where this does not work:
Strategies may differ slightly, resulting in different shortcuts behavior depending on the app used.
Punctuation is usually not remapped. E.g. the standard Israeli layout cannot remap its key <AD01> “slash” to the US layout “q”.
If one have multiple Latin layouts, shortcuts may be positioned differently. E.g. US Qwerty and French Azerty have different positions for Ctrl+Q, while the user might want all shortcuts to be positioned independently of the layout.
XKB limitations
Some users want explicitly to use keyboard shortcuts as if they were typing on another keyboard layout, e.g. using Qwerty shortcuts with a Dvorak layout. While achievable with modern XKB features (e.g. multiple actions per level), this is non-trivial and it does not scale well, thus preventing support in the standard keyboard database, xkeyboard-config.
Custom and consistent shortcuts behavior using libxkbcommon
Since libxkbcommon 1.14, tweaking the keyboard shortcuts can be achieved by using the following functions from the xkb_machine API:
Set the layout to use for shortcuts for each relevant layout. There are 2 typical use cases:
Single layout
The user types with a single layout, but want the shortcuts to act as if using another layout: e.g. Qwerty shortcuts for the Arabic layout. The keymap would be configured with 2 layouts: the user layout then the shortcut layout (e.g. ara,us).
if (xkb_machine_builder_remap_shortcut_layout(options, 0, 1)) {
/* handle error */
…
}
Multiple layouts
The user types with multiples layouts but wants shortcuts consistency accross all the layouts, typically using the first layout as the reference.
// When using shortcuts, all layouts will behave as if using the *first* layout.
