path: root/specs/ch13.xml

<chapter id='the_server_database_of_keyboard_components'>
<title>The Server Database of Keyboard Components</title>

<para>
The X server maintains a database of keyboard components and common keyboard
mappings. This database contains five kinds of components; when combined, these
five components provide a complete description of a keyboard and its behavior.
</para>


<para>
The X Keyboard Extension provides requests to list the contents of this
database, to assemble and complete keyboard descriptions by merging the current
keyboard description with the contents of this database, or to replace the
current keyboard description with a complete keyboard description assembled as
described below.
</para>

<sect1 id='component_names'>
<title>Component Names</title>

<para>
Component and keymap names have the form "<emphasis>
class</emphasis>
(<emphasis>
member</emphasis>
)" where <emphasis>
class</emphasis>
 describes a subset of the available components for a particular type and the
optional <emphasis>
member</emphasis>
 identifies a specific component from that subset. For example, the name
"atlantis(acme)" might specify the symbols used for the atlantis national
keyboard layout by the vendor "acme." Each class has an optional <emphasis>
default</emphasis>
 member — references which specify a class but not a member refer to the
default member of the class, if one exists.
</para>


<para>
The <emphasis>
class</emphasis>
 and <emphasis>
member</emphasis>
 names are both specified using characters from the Latin-1 character set. XKB
implementations must accept all alphanumeric characters, minus (‘-’) and
underscore (‘_’) in class or member names, and must not accept parentheses,
plus, vertical bar, percent sign, asterisk, question mark or white space. The
use of other characters is implementation-dependent.
</para>


</sect1>
<sect1 id='partial_components_and_combining_multiple_components'>
<title>Partial Components and Combining Multiple Components</title>

<para>
Some of the elements in the server database contain describe only a piece of
the corresponding keyboard component. These <emphasis>
partial</emphasis>
 components should be combined with other components of the same type to be
useful.
</para>


<para>
For example, a partial symbols map might describe the differences between a
common ASCII keyboard and some national layout. Such a partial map is not
useful on its own because it does not include those symbols that are the same
on both the ASCII and national layouts (such as function keys). On the other
hand, this partial map can configure <emphasis>
any</emphasis>
 ASCII keyboard to use a national layout.
</para>


<para>
Two components can be combined in two ways:
</para>

<itemizedlist>
<listitem>
  <para>If the second component <emphasis>
overrides</emphasis>
 the first, any definitions that are present in both components are taken from
the second.
  </para>
</listitem>
<listitem>
  <para>If the second component <emphasis>
augments</emphasis>
 the first, any definitions that are present in both components are taken from
the first.
  </para>
</listitem>
</itemizedlist>

<para>
Applications can use a <emphasis>
component expression</emphasis>
 to combine multiple components of some time into a complete description of
some aspect of the keyboard. A component expression is a string which lists the
components to be combined separated by operators which specify the rules for
combining them. A complete description is assembled from the listed components,
left to right, as follows:
</para>

<itemizedlist>
<listitem>
  <para>If the new elements are being merged with an existing map, the special
component name ‘%’ refers to the unmodified value of the map.
  </para>
</listitem>
<listitem>
  <para>The ‘+’ operator specifies that the next specified component should
override the current assembled definition.
  </para>
</listitem>
<listitem>
  <para>The ‘|’ operator specifies that the next specified component should
augment the currently assembled definition.
  </para>
</listitem>
<listitem>
  <para>If the new elements are being merged with an existing map and the
component expression begins with an operator, a leading ‘%’ is implied.
  </para>
</listitem>
<listitem>
  <para>If any unknown or illegal characters appear anywhere in the string, the
entire expression is invalid and is ignored.
  </para>
</listitem>
</itemizedlist>

<para>
For example, the component expression "+de" specifies that the default element
of the "de" map should be applied to the current keyboard mapping, overriding
any existing definitions.
</para>


<para>
A slightly more involved example: the expression
"acme(ascii)+de(basic)|iso9995-3" constructs a German (de) mapping for the
ASCII keyboard supplied by the "acme" vendor. The new definition begins with
the symbols for the default ASCII keyboard for Acme, overrides them with any
keys that are defined for the default German keyboard layout and then applies
the definitions from the iso9995-3 to any undefined keys or groups of keys
(part three of the iso9995 standard defines a common set of bindings for the
secondary group, but allows national layouts to override those definitions
where necessary).
</para>


</sect1>
<sect1 id='component_hints'>
<title>Component Hints</title>

<para>
Each component has a set of flags that provide some additional hints about that
component. XKB provides these hints for clients that present the keyboard
database to users and specifies their interpretation only loosely. Clients can
use these hints to constrain the list of components or to control the way that
components are presented to the user.
</para>


<para>
Hints for a component are reported with its name. The least significant byte of
the hints field has the same meaning for all five types of keyboard components,
and can contain any combination of the following values:
</para>

<informaltable frame='none'>
<tgroup cols='2'>
<colspec align="left" colsep="0"/>
<colspec align="left" colsep="0"/>
<thead>
  <row rowsep='1'>
    <entry>Flag</entry>
    <entry>Meaning</entry>
  </row>
</thead>
<tbody>
  <row rowsep='0'>
    <entry><emphasis>
LC_Hidden</emphasis>
</entry>
    <entry>Indicates a component that should not normally be presented to the
user.</entry>
  </row>
  <row rowsep='0'>
    <entry><emphasis>
LC_Default</emphasis>
</entry>
    <entry>Indicates a component that is the default member of its
class.</entry>
  </row>
  <row rowsep='0'>
    <entry><emphasis>
LC_Partial</emphasis>
</entry>
    <entry>Indicates a partial component.</entry>
  </row>
</tbody>
</tgroup>
</informaltable>

<para>
The interpretation of the most significant byte of the hints field is dependent
on the type of component. The hints defined for each kind of component are
listed in the section below that describes that kind of component.
</para>


</sect1>
<sect1 id='keyboard_components'>
<title>Keyboard Components</title>

<para>
The five types of components stored in the server database of keyboard
components correspond to the <emphasis>
symbols</emphasis>
, <emphasis>
geometry</emphasis>
, <emphasis>
keycodes</emphasis>
, <emphasis>
compat</emphasis>
 and <emphasis>
types</emphasis>
 symbolic names associated with a keyboard.
</para>

</sect1>
<sect1 id='the_keycodes_component'>
<title>The Keycodes Component</title>

<para>
The <emphasis>
keycodes</emphasis>
 component of a keyboard mapping specifies the range and interpretation of the
raw keycodes reported by the device. It sets the <emphasis>
keycodes</emphasis>
 symbolic name, the minimum and maximum legal keycodes for the keyboard, and
the symbolic name for each key. The keycodes component might also contain
aliases for some keys, symbolic names for some indicators, and a description of
which indicators are physically present.
</para>


<para>
The special keycodes component named "computed" indicates that XKB should
assign unused keycodes to any unknown keys referenced by name by any of the
other components. The computed keycodes component is useful primarily when
browsing keymaps because it makes it possible to use the symbols and geometry
components without having to find a set of keycodes that includes keycode
definitions for all of the keys listed in the two components.
</para>


<para>
XKB defines no hints that are specific to the keycodes component.
</para>


<sect2 id='the_types_component'>
<title>The Types Component</title>

<para>
The <emphasis>
types</emphasis>
 component of a keyboard mapping specifies the key types that can be associated
with the various keyboard keys. It affects the <emphasis>
types</emphasis>
 symbolic name and the list of types associated with the keyboard (see
<link linkend='key_types'>Key Types</link>). The types component
of a keyboard mapping can also optionally contain real modifier bindings and
symbolic names for one or more virtual modifiers.
</para>


<para>
The special types component named "canonical" always contains the types and
definitions listed in <link linkend="canonical_key_types">Canonical Key Types</link> of this document.
</para>


<para>
XKB defines no hints that are specific to the types component.
</para>


</sect2>
<sect2 id='the_compatibility_map_component'>
<title>The Compatibility Map Component</title>

<para>
The <emphasis>
compatibility map</emphasis>
 component of a keyboard mapping primarily specifies the rules used to assign
actions to keysyms. It affects the <emphasis>
compat</emphasis>
 symbolic name, the symbol compatibility map and the group compatibility map.
The compat component might also specify maps for some indicators and the real
modifier bindings and symbolic names of some virtual modifiers.
</para>


<para>
XKB defines no hints that are specific to the compatibility map component.
</para>


</sect2>
<sect2 id='the_symbols_component'>
<title>The Symbols Component</title>

<para>
The <emphasis>
symbols</emphasis>
 component of a keyboard mapping specifies primarily the symbols bound to each
keyboard key. It affects the <emphasis>
symbols</emphasis>
 symbolic name, a key symbol mapping for each key, they keyboard modifier
mapping, and the symbolic names for the keyboard symbol groups. Optionally, the
<emphasis>
symbols</emphasis>
 component can contain explicit actions and behaviors for some keys, or the
real modifier bindings and symbolic names for some virtual modifiers.
</para>


<para>
XKB defines the following additional hints for the symbols component:
</para>

<informaltable frame='none'>
<tgroup cols='2'>
<colspec align="left" colsep="0"/>
<colspec align="left" colsep="0"/>
<thead>
  <row rowsep='1'>
    <entry>Flag</entry>
    <entry>Meaning</entry>
  </row>
</thead>
<tbody>
  <row rowsep='0'>
    <entry><emphasis>
LC_AlphanumericKeys</emphasis>
</entry>
    <entry>Indicates a symbol component that contains bindings primarily for an
alphanumeric section of the keyboard.</entry>
  </row>
  <row rowsep='0'>
    <entry><emphasis>
LC_ModifierKeys</emphasis>
</entry>
    <entry>Indicates a symbol component that contains bindings primarily for
modifier keys.</entry>
  </row>
  <row rowsep='0'>
    <entry><emphasis>
LC_KeypadKeys</emphasis>
</entry>
    <entry>Indicates a symbol component that contains bindings primarily for
numeric keypad keys.</entry>
  </row>
  <row rowsep='0'>
    <entry>LC_FunctionKeys</entry>
    <entry>Indicates a symbol component that contains bindings primarily for
function keys.</entry>
  </row>
  <row rowsep='0'>
    <entry>LC_AlternateGroup</entry>
    <entry>Indicates a symbol component that contains bindings for an alternate
keyboard group.</entry>
  </row>
</tbody>
</tgroup>
</informaltable>

<para>
These hints only apply to partial symbols components; full symbols components
are assumed to specify all of the pieces listed above.
</para>

<note><para>The alphanumeric, modifier, keypad or function keys hints should
describe the primary intent of the component designer and should not simply an
exhaustive list of the kinds of keys that are affected. For example, national
keyboard layouts affect primarily alphanumeric keys, but many affect a few
modifier keys too; such mappings should set only <emphasis>
LC_AlphanumericKeys</emphasis>
 hint. In general, symbol components should set only one of those four flags
(though <emphasis>
LC_AlternateGroup</emphasis>
 may be combined with any of the other flags).</para></note>

</sect2>
<sect2 id='the_geometry_component'>
<title>The Geometry Component</title>

<para>
The <emphasis>
geometry</emphasis>
 component of a keyboard mapping specifies primarily the geometry of the
keyboard. It contains the geometry symbolic name and the keyboard geometry
description. The geometry component might also contain aliases for some keys or
symbolic names for some indicators and might affect the set of indicators that
are physically present. Key aliases defined in the geometry component of a
keyboard mapping override those defined in the keycodes component.
</para>


<para>
XKB defines no hints that are specific to the geometry component.
</para>


</sect2>
</sect1>
<sect1 id='complete_keymaps'>
<title>Complete Keymaps</title>

<para>
The X server also reports a set of fully specified keymaps. The keymaps
specified in this list are usually assembled from the components stored in the
rest of the database and typically represent the most commonly used keymaps for
a particular system.
</para>


<para>
XKB defines no hints that are specific to complete keymaps.
</para>
</sect1>
</chapter>