path: root/specs/XKB/glossary.xml

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE glossary PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
	  "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
<glossary id='glossary'>
<title>Glossary</title>
<glossentry>
  <glossterm>Allocator</glossterm>
  <glossdef>
    <para>
Xkb provides functions, known as allocators, to create and initialize Xkb data
structures.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Audible Bell</glossterm>
  <glossdef>
    <para>
An audible bell is the sound generated by whatever bell is associated with the
keyboard or input extension device, as opposed to any other audible sound
generated elsewhere in the system.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Autoreset Controls</glossterm>
  <glossdef>
    <para>
The autoreset controls configure the boolean controls to automatically be
enabled or disabled at the time a program exits.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Base Group</glossterm>
  <glossdef>
    <para>
The group in effect as a result of all actions other than a previous lock or
latch request; the base group is transient. For example, the user pressing and
holding a group shift key that shifts to Group2 would result in the base group
being group 2 at that point in time. Initially, base group is always Group1.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Base Modifiers</glossterm>
  <glossdef>
    <para>
Modifiers that are turned on as a result of some actions other than previous
lock or latch requests; base modifiers are transient. For example, the user
pressing and holding a key bound to the Shift modifier would result in Shift
being a base modifier at that point in time.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Base Event Code</glossterm>
  <glossdef>
    <para>
A number assigned by the X server at run time that is assigned to the extension
to identify events from that extension.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Base State</glossterm>
  <glossdef>
    <para>
The base group and base modifiers represent keys that are physically or
logically down; these constitute the base state.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Boolean Controls</glossterm>
  <glossdef>
    <para>
Global keyboard controls that may be selectively enabled and disabled under
program control and that may be automatically set to an on or off condition
upon client program exit.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Canonical Key Types</glossterm>
  <glossdef>
    <para>
The canonical key types are predefined key types that describe the types of
keys available on most keyboards. The definitions for the canonical key types
are held in the first
<symbol>XkbNumRequiredTypes</symbol>
 entries of the
<structfield>types</structfield>
 field of the client map and are indexed using the following constants:
    </para>
    <itemizedlist>
      <listitem>
        <para>
<symbol>XkbOneLevelIndex</symbol>
        </para>
      </listitem>
      <listitem>
        <para>
<symbol>XkbTwoLevelIndex</symbol>
        </para>
      </listitem>
      <listitem>
        <para>
<symbol>XkbAlphabeticIndex</symbol>
        </para>
      </listitem>
      <listitem>
        <para>
<symbol>XkbKeypadIndex</symbol>
        </para>
      </listitem>
  </itemizedlist>
  </glossdef>
</glossentry>

<glossentry>
  <glossterm>Client Map</glossterm>
  <glossdef>
    <para>
The key mapping information needed to convert arbitrary keycodes to symbols.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Compat Name</glossterm>
  <glossdef>
    <para>
The
<emphasis>compat</emphasis>
 name is a string that provides some information about the rules used to bind
actions to keys that are changed using core protocol requests.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Compatibility State</glossterm>
  <glossdef>
    <para>
When an Xkb-extended X server connects to an Xkb-unaware client, the
compatibility state remaps the keyboard group into a core modifier whenever
possible.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Compatibility Grab State</glossterm>
  <glossdef>
    <para>
The grab state that results from applying the compatibility map to the Xkb grab
state.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Compatibility Map</glossterm>
  <glossdef>
    <para>
The definition of how to map core protocol keyboard state to Xkb keyboard state.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Component Expression</glossterm>
  <glossdef>
    <para>
An expression used to describe server keyboard database components to be
loaded. It describes the order in which the components should be loaded and the
rules by which duplicate attributes should be resolved.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Compose Processing</glossterm>
  <glossdef>
    <para>
The process of mapping a series of keysyms to a string is known as compose
processing.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Consumed Modifier</glossterm>
  <glossdef>
    <para>
Xkb normally consumes modifiers in determining the appropriate symbol for an
event, that is, the modifiers are not considered during any of the later stages
of event processing. For those rare occasions when a modifier
<emphasis>should</emphasis>
 be considered despite having been used to look up a symbol, key types include
an optional
<structfield>preserve</structfield>
 field.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Core Event</glossterm>
  <glossdef>
    <para>
An event created from the core X server.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Detectable Auto-Repeat</glossterm>
  <glossdef>
    <para>
Detectable auto-repeat allows a client to detect an auto-repeating key. If a
client requests and the server supports detectable auto-repeat, Xkb generates
<symbol>KeyRelease</symbol>
 events only when the key is physically released. Thus the client receives a
number of
<symbol>KeyPress</symbol>
 events for that key without intervening
<symbol>KeyRelease</symbol>
 events until the key is finally released, when a
<symbol>KeyRelease</symbol>
 event is received.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Effective Group</glossterm>
  <glossdef>
    <para>
The effective group is the arithmetic sum of the locked, latched, and base
groups. The effective keyboard group is always brought back into range
depending on the value of the
<emphasis>GroupsWrap</emphasis>
 control for the keyboard. If an event occurs with an effective group that is
legal for the keyboard as a whole, but not for the key in question, the group
<emphasis>for that event only</emphasis>
 is normalized using the algorithm specified by the
<structfield>group_info</structfield>
 member of the key symbol map
(<structname>XkbSymMapRec</structname>).

    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Effective Mask</glossterm>
  <glossdef>
    <para>
An Xkb modifier definition consists of a set of bit masks corresponding to the
eight real modifiers; a similar set of bitmasks corresponding to the 16 named
virtual modifiers; and an effective mask. The effective mask represents the set
of all real modifiers that can logically be set either by setting any of the
real modifiers or by setting any of the virtual modifiers in the definition.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Effective Modifier</glossterm>
  <glossdef>
    <para>
The effective modifiers are the bitwise union of the base, latched and locked
modifiers.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Extension Device</glossterm>
  <glossdef>
    <para>
Any keyboard or other input device recognized by the X input extension.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Global Keyboard Controls</glossterm>
  <glossdef>
    <para>
Controls that affect the way Xkb generates key events. The controls affect all
keys, as opposed to per-key controls that are for a single key. Global controls
include
    </para>
    <itemizedlist>
    <listitem>
      <para>RepeatKeys Control</para>
    </listitem>
    <listitem>
      <para>DetectableAuto-repeat</para>
    </listitem>
    <listitem>
      <para>SlowKeys</para>
    </listitem>
    <listitem>
      <para>BounceKeys</para>
    </listitem>
    <listitem>
      <para>StickyKeys</para>
    </listitem>
    <listitem>
      <para>MouseKeys</para>
    </listitem>
    <listitem>
      <para>MouseKeysAccel</para>
    </listitem>
    <listitem>
      <para>AccessXKeys</para>
    </listitem>
    <listitem>
      <para>AccessXTimeout</para>
    </listitem>
    <listitem>
      <para>AccessXFeedback</para>
    </listitem>
    <listitem>
      <para>Overlay1</para>
    </listitem>
    <listitem>
      <para>Overlay2</para>
    </listitem>
    <listitem>
      <para>EnabledControls</para>
    </listitem>
    </itemizedlist>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Grab State</glossterm>
  <glossdef>
    <para>
The grab state is the state used when matching events to passive grabs. It
consists of the grab group and the grab modifiers.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Group</glossterm>
  <glossdef>
    <para>See Keysym Group</para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Group Index</glossterm>
  <glossdef>
    <para>
A number used as the internal representation for a group number. Group1 through
Group 4 have indices of 0 through 3.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Groups Wrap Control</glossterm>
  <glossdef>
    <para>
If a group index exceeds the maximum number of groups permitted for the
specified keyboard, it is wrapped or truncated back into range as specified by
the global <emphasis>GroupsWrap</emphasis> control.
<emphasis>GroupsWrap</emphasis> can have the following values:
    </para>
    <literallayout>
          <emphasis>WrapIntoRange</emphasis>
          <emphasis>ClampIntoRange</emphasis>
          <emphasis>RedirectIntoRange</emphasis>
    </literallayout>
  </glossdef>
</glossentry>

<glossentry>
  <glossterm>Key Type</glossterm>
  <glossdef>
    <para>
An attribute of a key that identifies which modifiers affect the shift level of
a key and the number of groups on the key.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Key Width</glossterm>
  <glossdef>
    <para>
The maximum number of shift levels in any group for the key type associated
with a key.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Keysym Group</glossterm>
  <glossdef>
    <para>
A keysym group is a logical state of the keyboard providing access to a
collection of characters. A group usually contains a set of characters that
logically belong together and that may be arranged on several shift levels
within that group. For example, Group1 could be the English alphabet, and
Group2 could be Greek. Xkb supports up to four different groups for an input
device or keyboard. Groups are in the range 1&ndash;4 (Group1&ndash;Group4),
and are often referred to as G1&ndash;G4 and indexed as 0&ndash;3.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Indicator</glossterm>
  <glossdef>
    <para>
An indicator is a feedback mechanism such as an LED on an input device. Using
Xkb, a client application can determine the names of the various indicators,
determine and control the way that the individual indicators should be updated
to reflect keyboard changes, and determine which of the 32 keyboard indicators
reported by the protocol are actually present on the keyboard.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Indicator Feedback</glossterm>
  <glossdef>
    <para>
An indicator feedback describes the state of a bank of up to 32 lights. It has
a mask where each bit corresponds to a light and an associated value mask that
specifies which lights are on or off.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Indicator Map</glossterm>
  <glossdef>
    <para>
An indicator has its own set of attributes that specify whether clients can
explicitly set its state and whether it tracks the keyboard state. The
indicator map is the collection of these attributes for each indicator and is
held in the
<structfield>maps</structfield>
 array, which is an array of
<structname>XkbIndicatorRec</structname>
 structures.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Input Extension</glossterm>
  <glossdef>
    <para>
An extension to the core X protocol that allows an X server to support multiple
keyboards, as well as other input devices, in addition to the core X keyboard
and pointer. Other types of devices supported by the input extension include,
but are not limited to: mice, tablets, touchscreens, barcode readers, button
boxes, trackballs, identifier devices, data gloves, and eye trackers.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Key Action</glossterm>
  <glossdef>
    <para>
A key action consists of an operator and some optional data. Once the server
has applied the global controls and per-key behavior and has decided to process
a key event, it applies key actions to determine the effects of the key on the
internal state of the server. Xkb supports actions that do the following:
    </para>
    <itemizedlist>
    <listitem>
      <para>
Change base, latched, or locked modifiers or group
      </para>
    </listitem>
    <listitem>
      <para>
Move the core pointer or simulate core pointer button events
      </para>
    </listitem>
    <listitem>
      <para>
Change most aspects of keyboard behavior
      </para>
    </listitem>
    <listitem>
      <para>
Terminate or suspend the server
      </para>
    </listitem>
    <listitem>
      <para>
Send a message to interested clients
      </para>
    </listitem>
    <listitem>
      <para>
Simulate events on other keys
      </para>
    </listitem>
    </itemizedlist>
  </glossdef>
</glossentry>

<glossentry>
  <glossterm>Key Alias</glossterm>
  <glossdef>
    <para>
A key alias is a symbolic name for a specific physical key. Key aliases allow
the keyboard layout designer to assign multiple key names to a single key. This
allows the keyboard layout designer to refer to keys using either their
position or their <quote>function</quote>.
Key aliases can be specified both in the symbolic
names component and in the keyboard geometry. Both sets of aliases are always
valid, but key alias definitions in the keyboard geometry have priority; if
both symbolic names and geometry include aliases, you should consider the
definitions from the geometry before considering the definitions from the
symbolic names section.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Key Behavior</glossterm>
  <glossdef>
    <para>
The
<structfield>behaviors</structfield>
 field of the server map is an array of
<structname>XkbBehavior</structname>,
indexed by keycode, and contains the behavior for each key. The X server uses
key behavior to determine whether to process or filter out any given key event;
key behavior is independent of keyboard modifier or group state. Each key has
exactly one behavior.
    </para>
    <para>Key behaviors include:</para>
    <itemizedlist>
    <listitem>
      <para>XkbKB_Default</para>
    </listitem>
    <listitem>
      <para>XkbKB_Lock</para>
    </listitem>
    <listitem>
      <para>XkbKB_RadioGroup</para>
    </listitem>
    <listitem>
      <para>XkbKB_Overlay1</para>
    </listitem>
    <listitem>
      <para>XkbKB_Overlay2</para>
    </listitem>
    </itemizedlist>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Key Symbol Map</glossterm>
  <glossdef>
    <para>
A key symbol map describes the symbols bound to a key and the rules to be used
to interpret those symbols. It is an array of
<structname>XkbSymMapRec</structname>
 structures indexed by keycode.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Key Type</glossterm>
  <glossdef>
    <para>
Key types are used to determine the shift level of a key given the current
state of the keyboard. There is one key type for each group for a key. Key
types are defined using the
<structname>XkbKeyTypeRec</structname>
 and
<structname>XkbKTMapEntryRec</structname>
 structures. Xkb allows up to
<symbol>XkbMaxKeyTypes</symbol>
 (255) key types to be defined, but requires at least
<symbol>XkbNumRequiredTypes</symbol>
 (4) predefined types to be in a key map.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Keyboard Bells</glossterm>
  <glossdef>
    <para>
The sound the default bell makes when rung is the system bell or the default
keyboard bell. Some input devices may have more than one bell, identified by
<structfield>bell_class</structfield> and <structfield>bell_id</structfield>.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Keyboard Components</glossterm>
  <glossdef>
    <para>
There are five types of components stored in the X server database of keyboard
components. They correspond to the
<structfield>>symbols</structfield>,
<structfield>geometry</structfield>,
<structfield>keycodes</structfield>,
<structfield>compat</structfield>,
and
<structfield>types</structfield>
 symbolic names associated with a keyboard.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Keyboard Feedback</glossterm>
  <glossdef>
    <para>
A keyboard feedback includes the following:
    </para>
<literallayout>
      Keyclick volume
      Bell volume
      Bell pitch
      Bell duration
      Global auto-repeat
      Per key auto-repeat
      32 LEDs
</literallayout>
  </glossdef>
</glossentry>

<glossentry>
  <glossterm>Key Width, Key Type Width</glossterm>
  <glossdef>
    <para>
The maximum number of shift levels for a type is referred to as the width of a
key type.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Keyboard Geometry</glossterm>
  <glossdef>
    <para>
Keyboard geometry describes the physical appearance of the keyboard, including
the shape, location, and color of all keyboard keys or other visible keyboard
components such as indicators and is stored in a
<structname>XkbGeometryRec</structname>
 structure. The information contained in a keyboard geometry is sufficient to
allow a client program to draw an accurate two-dimensional image of the
keyboard.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Keyboard Geometry Name</glossterm>
  <glossdef>
    <para>
The keyboard geometry name describes the physical location, size, and shape of
the various keys on the keyboard and is part of the
<structname>XkbNamesRec</structname>
 structure.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Keyboard State</glossterm>
  <glossdef>
    <para>
Keyboard state encompasses all of the transitory information necessary to map a
physical key press or release to an appropriate event.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Keycode</glossterm>
  <glossdef>
    <para>
A numeric value returned to the X server when a key on a keyboard is pressed or
released, indicating which key is being modulated. Keycode numbers are in the
range 1 &lt;= keycode &lt;= max, where max is the number of physical keys on
the device.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Keycode Name</glossterm>
  <glossdef>
    <para>
The keycode name describes the range and meaning of the keycodes returned by
the keyboard and is part of the
<structname>XkbNamesRec</structname>
 structure.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Latched Group</glossterm>
  <glossdef>
    <para>
A latched group is a group index that is combined with the base and locked
group to form the effective group. It applies only to the next key event that
does not change the keyboard state. The latched group can be changed by
keyboard activity or via Xkb extension library functions.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Latched Modifier</glossterm>
  <glossdef>
    <para>
Latched modifiers are the set of modifiers that are combined with the base
modifiers and the locked modifiers to form the effective modifiers. It applies
only to the next key event that does not change the keyboard state.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>LED</glossterm>
  <glossdef>
    <para>
A light emitting diode. However, for the purposes of the X keyboard extension
specification, a LED is any form of visual two-state indicator that is either
on or off.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Locked Group</glossterm>
  <glossdef>
    <para>
A locked group is a group index that is combined with the base and latched
group to form the effective group. When a group is locked, it supersedes any
previous locked group and remains the locked group for all future key events,
until a new group is locked. The locked group can be changed by keyboard
activity or via Xkb extension library functions.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Locked Modifiers</glossterm>
  <glossdef>
    <para>
Locked modifiers are the set of modifiers that are combined with the base
modifiers and the latched modifiers to form the effective modifiers. A locked
modifier applies to all future key events until it is explicitly unlocked.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Lookup State      </glossterm>
  <glossdef>
    <para>
The lookup state is composed of the lookup group and the lookup modifiers, and
it is the state an Xkb-capable or Xkb-aware client should use to map a keycode
to a keysym.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Modifier</glossterm>
  <glossdef>
    <para>
A modifier is a logical condition that is either set or unset. The modifiers
control the Shift Level selected when a key event occurs. Xkb supports the core
protocol eight modifiers
(<symbol>Shift</symbol>,
<symbol>Lock</symbol>,
<symbol>Control</symbol>,
and
<symbol>Mod1</symbol>
 through
<symbol>Mod5</symbol>),
 called the
<emphasis>real</emphasis>
 modifiers. In addition, Xkb extends modifier flexibility by providing a set of
sixteen named virtual modifiers, each of which can be bound to any set of the
eight real modifiers.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Modifier Key</glossterm>
  <glossdef>
    <para>
A modifier key is a key whose operation has no immediate effect, but that, for
as long as it is held down, modifies the effect of other keys. A modifier key
may be, for example, a shift key or a control key.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Modifier Definition</glossterm>
  <glossdef>
    <para>
An Xkb modifier definition, held in an
<structname>XkbModsRec</structname>,
consists of a set of real modifiers, a set of virtual modifiers, and an
effective mask. The mask is the union of the real modifiers and the set of real
modifiers to which the virtual modifiers map; the mask cannot be explicitly
changed.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Nonkeyboard Extension Device      </glossterm>
  <glossdef>
    <para>
An input extension device that is not a keyboard. Other types of devices
supported by the input extension include, but are not limited to: mice,
tablets, touchscreens, barcode readers, button boxes, trackballs, identifier
devices, data gloves, and eye trackers.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Outlines</glossterm>
  <glossdef>
    <para>
An outline is a list of one or more points that describes a single closed
polygon, used in the geometry specification for a keyboard.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Physical Indicator Mask</glossterm>
  <glossdef>
    <para>
The physical indicator mask is a field in the
<structname>XkbIndicatorRec</structname>
 that indicates which indicators are bound to physical LEDs on the keyboard; if
a bit is set in
<structfield>phys_indicators</structfield>,
then the associated indicator has a physical LED associated with it. This
field is necessary because some indicators may not have corresponding physical
LEDs on the keyboard.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Physical Symbol Keyboard Name</glossterm>
  <glossdef>
    <para>
The
<structfield>symbols</structfield>
 keyboard name identifies the symbols logically bound to the keys. The symbols
name is a human or application-readable description of the intended locale or
usage of the keyboard with these symbols. The
<structfield>phys_symbols</structfield>
 keyboard name, on the other hand, identifies the symbols actually engraved on
the keyboard.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Preserved Modifier</glossterm>
  <glossdef>
    <para>
Xkb normally consumes modifiers in determining the appropriate symbol for an
event, that is, the modifiers are not considered during any of the later stages
of event processing. For those rare occasions when a modifier
<emphasis>should</emphasis>
 be considered despite having been used to look up a symbol, key types include
an optional
<structfield>preserve</structfield>
 field. If a modifier is present in the
<structfield>preserve</structfield>
 list, it is a preserved modifier.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Radio Group</glossterm>
  <glossdef>
    <para>
A radio group is a set of keys whose behavior simulates a set of radio buttons.
Once a key in a radio group is pressed, it stays logically depressed until
another key in the group is pressed, at which point the previously depressed
key is logically released. Consequently, at most one key in a radio group can
be logically depressed at one time.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Real Modifier</glossterm>
  <glossdef>
    <para>
Xkb supports the eight core protocol modifiers
(<symbol>Shift</symbol>,
<symbol>Lock</symbol>,
<symbol>Control</symbol>,
and
<symbol>Mod1</symbol>
 through
<symbol>Mod5</symbol>);
 these are called the
<emphasis>real</emphasis>
 modifiers, as opposed to the set of sixteen named virtual modifiers that can
be bound to any set of the eight real modifiers.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Server Internal Modifiers</glossterm>
  <glossdef>
    <para>
Modifiers that the server uses to determine the appropriate symbol for an
event; internal modifiers are normally consumed by the server.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Shift Level</glossterm>
  <glossdef>
    <para>
One of several states (normally 2 or 3) governing which graphic character is
produced when a key is actuated.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Symbol Keyboard Name</glossterm>
  <glossdef>
    <para>
The
<structfield>symbols</structfield>
 keyboard name identifies the symbols logically bound to the keys. The symbols
name is a human or application-readable description of the intended locale or
usage of the keyboard with these symbols. The
<structfield>phys_symbols</structfield>
 keyboard name, on the other hand, identifies the symbols actually engraved on
the keyboard.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Symbolic Name</glossterm>
  <glossdef>
    <para>
Xkb supports symbolic names for most components of the keyboard extension. Most
of these symbolic names are grouped into the
<structfield>names</structfield>
 component of the keyboard description.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>State Field</glossterm>
  <glossdef>
    <para>
The portion of a client-side core protocol event that holds the modifier,
group, and button state information pertaining to the event.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Types Name</glossterm>
  <glossdef>
    <para>
The
<emphasis>types</emphasis>
 name provides some information about the set of key types that can be
associated with the keyboard. In addition, each key type can have a name, and
each shift level of a type can have a name.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Valuator</glossterm>
  <glossdef>
    <para>
A valuator reports a range of values for some entity, like a mouse axis, a
slider, or a dial.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Virtual Modifier</glossterm>
  <glossdef>
    <para>
Xkb provides a set of sixteen named virtual modifiers that can be bound to any
set of the eight real modifiers. Each virtual modifier can be bound to any set
of the real modifiers
(<symbol>Shift</symbol>,
<symbol>Lock</symbol>,
<symbol>Control</symbol>,
 and
<symbol>Mod1</symbol>
&ndash;
<symbol>Mod5</symbol>).

    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Virtual Modifier Mapping</glossterm>
  <glossdef>
    <para>
Xkb maintains a virtual modifier mapping, which lists the virtual modifiers
associated with each key.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Xkb-aware Client</glossterm>
  <glossdef>
    <para>
A client application that initializes Xkb extension and is consequently bound
to an Xlib that includes the Xkb extension.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Xkb-capable Client</glossterm>
  <glossdef>
    <para>
A client application that makes no Xkb extension Xlib calls but is bound to an
Xlib that includes the Xkb extension.
    </para>
  </glossdef>
</glossentry>
<glossentry>
  <glossterm>Xkb-unaware Client</glossterm>
  <glossdef>
    <para>
A client application that makes no Xkb extension Xlib calls and is bound to an
Xlib that does not include the Xkb extension.
    </para>
  </glossdef>
</glossentry>

</glossary>