The XKB Configuration Guide
Table of Contents
Abstract
This document describes how to configure Xorg XKB from a user’s point of view. It covers the basic configuration syntax and gives a few examples.
This version covers Xorg server versions 1.8 and later, used with the data files from the xkeyboard-config project.
Some parts of this documentation may be obsolete. We are working on improving it.
Overview
The XKB configuration system consists of a number of components. Selecting and combining the proper parts, you can achieve most of the configurations you might need. Unless you have a completely atypical keyboard, you really don’t need to touch any of the XKB component files themselves.
Some desktop environments now provide integrated graphical configuration tools for setting XKB configuration as part of your desktop session. The instructions in this document are provided for those without such support, those who need to configure XKB before the session startup (such as at the login screen), or those who need to perform more advanced configuration than those tools provide.
Selecting an XKB configuration
The easiest and most natural way to specify a keyboard mapping is to use the rules component. As its name suggests, it describes a number of general rules on how to combine the bits and pieces into a valid and useful keyboard mapping. All you need to do is to select a suitable rules file and then to feed it with a few parameters that will adjust the keyboard behaviour to fulfill your needs.
The parameters are:
XkbRules
– the file of rules to be used for keyboard mapping compositionXkbModel
– the name of the model of your keyboardXkbLayout
– the layout(s) you intend to useXkbVariant
– the variant(s) of the layout(s) you intend to useXkbOptions
– extra XKB configuration options
The rules file used depends on your system. The rules files commonly used with Xorg are provided by the xkeyboard-config project. On Linux systems, the evdev rules are most commonly used, on other systems the base rules are used. Some additional rules files exist for historical reasons, but are no longer widely used. In general, it’s best to simply not specify the rules file, in order to use the default rules selected automatically by the X server.
For each rules file there is a description file named <vendor-rules>.lst
,
for instance base.lst which is located in the XKB configuration subdirectory
rules
(for example /usr/share/X11/xkb/rules
).
Basic Configuration
Let’s say you want to configure a PC-style American keyboard with 104 keys
as described in base.lst
. It can be done by simply writing several lines
from below to a new configuration file in /etc/X11/xorg.conf.d
, such
as /etc/X11/xorg.conf.d/90-custom-kbd.conf
.
Section "InputClass"
Identifier "keyboard defaults"
MatchIsKeyboard "on"
Option "XkbModel" "pc104"
Option "XkbLayout" "us"
Option "XKbOptions" ""
EndSection
The values of the parameters XkbModel
and XkbLayout
are really not surprising.
The parameter XkbOptions
has been explicitly set to empty, meaning no options.
The parameter XkbVariant
has been left out, meaning that the default variant
(the first variant in the file, often named basic
) will be loaded.
Of course, this can also be done at runtime using the utility setxkbmap. The shell command loading the same keyboard mapping would look like:
The configuration snippet and the shell command will be very similar for most other layouts (internationalized mappings).
If you wanted to enable the Ctrl+Alt+Backspace
sequence to terminate the
X server by default, you could create a configuration snippet
/etc/X11/xorg.conf.d/90-zap.conf
containing:
Section "InputClass"
Identifier "keyboard defaults"
MatchIsKeyboard "on"
Option "XKbOptions" "terminate:ctrl_alt_bksp"
EndSection
This would be equivalent to running the shell command:
Advanced Configuration
Since XFree86 4.3.x, you can use multi-layouts XKB configuration. What does it mean? Basically it allows you to load up to four different keyboard layouts at a time. Each such layout will reside in its own group. The groups (unlike a complete keyboard remapping) can be switched very fast from one to another with some key combination.
Let’s say you want to configure your new Logitech cordless desktop keyboard, you intend to use three different layouts at the same time - US, Czech and German (in this order), and that you are used to the Alt+Shift combination for switching among them.
Then the configuration snippet could look like this:
Section "InputClass"
Identifier "Logitech Cordless"
MatchIsKeyboard "on"
Option "XkbModel" "logicordless"
Option "XkbLayout" "us,cz,de"
Option "XKbOptions" "grp:alt_shift_toggle"
EndSection
Of course, this can also be done at runtime using the utility setxkbmap. The shell command loading the same keyboard mapping would look like:
Even More Advanced Configuration
Okay, let’s say you are more demanding. You do like the example above but you want to change it a bit. Let’s imagine you want the Czech keyboard mapping to use another variant than basic. The configuration snippet then changes into:
Section "InputClass"
Identifier "Logitech Cordless"
MatchIsKeyboard "on"
Option "XkbModel" "logicordless"
Option "XkbLayout" "us,cz,de"
Option "XkbVariant" ",bksl,"
Option "XKbOptions" "grp:alt_shift_toggle"
EndSection
That seems tricky but it is not. The logic for setting variants is the same as for layouts, which means that the first and the third variant settings are left out (set to basic), and the second is set to bksl (a special variant with an enhanced definition of the backslash key).
Analogically, the loading at runtime will change to:
Basic Global Options
For a list of available options, with a short description of what they do,
see the section starting with ! option
in the rules/*.lst
files.
Keymap XKB Configuration
This is the formerly used way to configure XKB. The user included a special keymap file which specified the direct XKB configuration. This method has been obsoleted by the previously described rules files which are far more flexible and allow a simpler and more intuitive syntax. The obsolete method is preserved merely for compatibility reasons. Avoid using it if possible.