3. Direct XKB Configuration

Generally, you can directly prescribe what configuration of each of basic xkb components should be used to form the resulting keyboard mapping. This method is rather "brute force". You precisely need to know the structure and the meaning of all of used configuration components.

This method also exposes all xkb configuration details directly into xorg.conf configuration file which is a not very fortunate fact. In rare occasions it may be needed, though. So how does it work?

3.1. Basic Components

There are five basic components used to form a keyboard mapping:

• key codes - a translation of the scan codes produced by the keyboard into a suitable symbolic form
• types - a specification of what various combinations of modifiers produce
• key symbols - a translation of symbolic key codes into actual symbols
• geometry - a description of physical keyboard geometry
• compatibility maps - a specification of what action should each key produce in order to preserve compatibility with XKB-unware clients

3.2. Example Configuration

Look at the following example:

Section "InputDevice"
    Identifier "Keyboard0"
    Driver "kbd"

    Option "XkbKeycodes" "xorg"
    Option "XkbTypes"    "default"
    Option "XkbSymbols"  "en_US(pc104)+de+swapcaps"
    Option "XkbGeometry" "pc(pc104)"
    Option "XkbCompat"   "basic+pc+iso9995"
EndSection

This configuration sets the standard X server default interpretation of keyboard keycodes, sets the default modificator types. The symbol table is composed of extended US keyboard layout in its variant for pc keyboards with 104 keys plus all keys for german layout are redefined respectively. Also the logical meaning of Caps-lock and Control keys is swapped. The standard keyboard geometry (physical look) is set to pc style keyboard with 104 keys. The compatibility map is set to allow basic shifting, to allow Alt keys to be interpreted and also to allow iso9995 group shifting.