IABSD.fr/xenocara/lib/libX11/specs/XKB/glossary.xml

Branch : - branch - master - tag -

• Show log

  Commit

• Author : matthieu
  Date : 2015-04-06 20:57:55
  Hash : 8252bb00
  Message : update to libX11 1.6.3

• lib/libX11/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:
        <simplelist type='vert' columns='1'>
          <member><emphasis>WrapIntoRange</emphasis></member>
          <member><emphasis>ClampIntoRange</emphasis></member>
          <member><emphasis>RedirectIntoRange</emphasis></member>
        </simplelist>
      </para>
    </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:
        <simplelist type='vert' columns='1'>
          <member>Keyclick volume</member>
          <member>Bell volume</member>
          <member>Bell pitch</member>
          <member>Bell duration</member>
          <member>Global auto-repeat</member>
          <member>Per key auto-repeat</member>
          <member>32 LEDs</member>
        </simplelist>
      </para>
    </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>