path: root/sgml/XKB-Config.sgml

<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN">

<article>
<title>The XKB Configuration Guide
<author>Kamil Toman, Ivan U. Pascal
<date>25 November 2002

<ident>
$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/XKB-Config.sgml,v 1.4 2003/09/21 01:55:03 dawes Exp $
</ident>

<abstract>
This document describes how to configure XFree86 XKB from a user's point
a few. It converts basic configuration syntax and gives also a few examples.
</abstract>

<toc>

<p>
<sect>Overview
<p>
The XKB configuration is decomposed into a number of components. Selecting
proper parts and combining them back you can achieve most of configurations
you might need. Unless you have a completely atypical keyboard you really don't
need to touch any of xkb configuration files.

<sect>Selecting XKB Configuration
<p>
The easiest and the most natural way how to specify a keyboard mapping is
to use <tt>rules</tt> component. As its name suggests it describes a number of general
rules how to combine all 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.
<p>
The parameters are:
<itemize>
<item><tt>XkbRules </tt>- files of rules to be used for keyboard mapping 
composition
<item><tt>XkbModel </tt>- name of model of your keyboard type
<item><tt>XkbLayout </tt>- layout(s) you intend to use
<item><tt>XkbVariant </tt>- variant(s) of layout you intend to use
<item><tt>XkbOptions </tt>- extra xkb configuration options
</itemize>
<p>
The proper rules file depends on your vendor. In reality, the commonest
file of rules is <tt>xfree86</tt>. For each rules file there is a description
file named <tt>&lt;vendor-rules&gt;.lst</tt>, for instance <tt>xfree86.lst</tt> 
which is located in xkb configuration subdirectory <tt>rules</tt> (for example 
<tt>/etc/X11/xkb/rules</tt>).

<sect1>Basic Configuration
<p>
Let's say you want to configure a PC style America keyboard with 104
keys as described in <tt>xfree86.lst</tt>. It can be done by simply writing
several lines from below to you XFree86 configuration file (often
found as <tt>/etc/X11/XF86Config-4</tt> or <tt>/etc/X11/XF86Config</tt>):
<tscreen><verb>
Section "InputDevice"
    Identifier "Keyboard1"
    Driver "Keyboard"

    Option "XkbModel" "pc104"
    Option "XkbLayout" "us"
    Option "XKbOptions" ""
EndSection
</verb></tscreen>
The values of parameters <tt>XkbModel</tt> and <tt>XkbLayout</tt> are really 
not surprising. The parameters <tt>XkbOptions</tt> has been explicitly set to 
empty set of parameters. The parameter <tt>XkbVariant</tt> has been left out. 
That means the default variant named <tt>basic</tt> is loaded.
<p>
Of course, this can be also done at runtime using utility setxkbmap.
Shell command loading the same keyboard mapping would look like:
<tscreen><verb>
setxkbmap -rules xfree86 -model pc104 -layout us -option ""
</verb></tscreen>
The configuration and the shell command would be very analogical
for most other layouts (internationalized mappings). 

<sect1>Advanced Configuration
<p>
Since XFree86 4.3.x you can use multi-layouts xkb configuration.
What does it mean? Basically it allows to load up to four different
keyboard layouts at a time. Each such layout would reside in its
own group. The groups (unlike complete keyboard remapping) can be
switched very fast from one to another by a combination of keys.
<p>
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 <tt>Alt-Shift</tt> combination for switching among them.
<p>
Then the configuration snippet could look like this:
<tscreen><verb>
Section "InputDevice"
    Identifier "Keyboard1"
    Driver "Keyboard"

    Option "XkbModel" "logicordless"
    Option "XkbLayout" "us,cz,de"
    Option "XKbOptions" "grp:alt_shift_toggle"
EndSection
</verb></tscreen>
Of course, this can be also done at runtime using utility setxkbmap.
Shell command loading the same keyboard mapping would look like:
<tscreen><verb>
setxkbmap -rules xfree86 -model logicordless -layout "us,cz,de" \
         -option "grp:alt_shift_toggle"
</verb></tscreen>


<sect1>Even More Advanced Configuration
<p>
Okay, let's say you are more demanding. You do like the example
above but you want it to change a bit. Let's imagine you want
the czech keyboard mapping to use another variant but basic.
The configuration snippet then changes into:
<tscreen><verb>
Section "InputDevice"
    Identifier "Keyboard1"
    Driver "Keyboard"

    Option "XkbModel" "logicordless"
    Option "XkbLayout" "us,cz,de"
    Option "XkbVariant" ",bksl,"
    Option "XKbOptions" "grp:alt_shift_toggle"
EndSection
</verb></tscreen>
That's seems tricky but it is not. The logic for settings of variants
is the same as for layouts, that means the first and the third variant
settings are left out (set to <tt>basic</tt>), the second is set to 
<tt>bksl</tt> (a special variant with an enhanced definition of the backslash 
key).
<p>
Analogically, the loading runtime will change to:
<tscreen><verb>
setxkmap -rules xfree86 -model logicordless -layout "us,cz,de" \
         -variant ",bksl," -option "grp:alt_shift_toggle"
</verb></tscreen>

<sect1>Basic Global Options
<p>
See rules/*.lst files.

<!-- 
  TODO: More detailed descriptions of options. User's often get confused.
-->

<sect>Direct XKB Configuration
<p>
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. 
<p>
This method also exposes all xkb configuration details directly into XFree86
configuration file which is a not very fortunate fact.
In rare occasions it may be needed, though. So how does it work?

<sect1>Basic Components
<p>
There are five basic components used to form a keyboard mapping:
<itemize>
<item><em>key codes</em> - a translation of the scan codes produced by the 
                        keyboard into a suitable symbolic form
              
<item><em>types</em> - a specification of what various combinations of 
modifiers produce

<item><em>key symbols</em> - a translation of symbolic key codes into actual 
symbols

<item><em>geometry</em> - a description of physical keyboard geometry

<item><em>compatibility maps</em> - a specification of what action should
each key produce in order to preserve compatibility with XKB-unware clients
</itemize>

<sect1>Example Configuration
<p>
Look at the following example:
<tscreen><verb>
Section "InputDevice"
    Identifier "Keyboard0"
    Driver "Keyboard"

    Option "XkbKeycodes" "xfree86"
    Option "XkbTypes"    "default"
    Option "XkbSymbols"  "en_US(pc104)+de+swapcaps"
    Option "XkbGeometry" "pc(pc104)"
    Option "XkbCompat"   "basic+pc+iso9995"
EndSection
</verb></tscreen>

This configuration sets the standard XFree86 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 <tt>Caps-lock</tt> and <tt>Control</tt> 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.

<!--
    TODO: add information about layout shifting:
    TODO: us+ru(winkeys):2+de:3
-->

<sect>Keymap XKB Configuration
<p>
It 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 previously described rules files which are far
more flexible and allow simpler and more intuitive syntax. It is
preserved merely for compatibility reasons. Avoid using it if it is possible.
<p>

</article>