At the startup (or at later at user's command) X server starts its xkb keyboard module extension and reads data from a compiled configuration file.
This compiled configuration file is prepared by the program
which behaves altogether as an ordinary compiler (see
Its input are human readable xkb configuration files which are verified and
then composed into a useful xkb configuration. Users don't need to mess with
xkbcomp themselves, for them it is invisible. Usually, it is started
upon X server startup.
As you probably already know, the xkb configuration consists of five main modules:
Tables that defines translation from keyboard scan codes into reasonable symbolic names, maximum, minimum legal keycodes, symbolic aliases and description of physically present LED-indicators. The primary sence of this component is to allow definitions of maps of symbols (see below) to be independent of physical keyboard scancodes. There are two main naming conventions for symbolic names (always four bytes long):
<SPCE>(stands for space bar) or
<AE01>(an exclamation mark on US keyboards), on the right there are keys
Types describe how the produced key is changed by active modifiers (like Shift, Control, Alt, ...). There are several predefined types which cover most of used combinations.
Compatibility component defines internal behaviour of modifiers. Using compat component you can assign various actions (elaborately described in xkb specification) to key events. This is also the place where LED-indicators behaviour is defined.
For i18n purposes, this is the most important table. It defines what values (=symbols) are assigned to what keycodes (represented by their symbolic name, see above). There may be defined more than one value for each key and then it depends on a key type and on modifiers state (respective compat component) which value will be the resulting one.
Geometry files aren't used by xkb itself but they may be used by some external programs to depict a keyboard image.