libX11 git update 14 sep 2011

1 files changed, 1016 insertions, 0 deletions

diff --git a/libX11/specs/XKB/glossary.xml b/libX11/specs/XKB/glossary.xml
new file mode 100644
index 000000000..0cccf0f8f
--- /dev/null
+++ b/libX11/specs/XKB/glossary.xml
@@ -0,0 +1,1016 @@
+<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 <emphasis>
+XkbNumRequiredTypes</emphasis>
+ entries of the <emphasis>
+types</emphasis>
+ field of the client map and are indexed using the following constants:
+    </para>
+    <itemizedlist>
+      <listitem>
+        <para>
+<emphasis>XkbOneLevelIndex</emphasis>
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+<emphasis>XkbTwoLevelIndex</emphasis>
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+<emphasis>XkbAlphabeticIndex</emphasis>
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+<emphasis>XkbKeypadIndex</emphasis>
+        </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 <emphasis>
+preserve</emphasis>
+ 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
+<emphasis>
+KeyRelease</emphasis>
+ events only when the key is physically released. Thus the client receives a
+number of <emphasis>
+KeyPress</emphasis>
+ events for that key without intervening <emphasis>
+KeyRelease</emphasis>
+ events until the key is finally released, when a <emphasis>
+KeyRelease</emphasis>
+ 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 <emphasis>
+group_info</emphasis>
+ member of the key symbol map (<emphasis>
+XkbSymMapRec</emphasis>
+).
+    </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-4 (Group1 - Group4), and are
+often referred to as G1 - G4 and indexed as 0 - 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 <emphasis>
+maps</emphasis>
+ array, which is an array of <emphasis>
+XkbIndicatorRec</emphasis>
+ 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 "function." 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 <emphasis>
+behaviors</emphasis>
+ field of the server map is an array of <emphasis>
+XkbBehavior</emphasis>
+, 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 <emphasis>
+XkbSymMapRec</emphasis>
+ 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 <emphasis>
+XkbKeyTypeRec</emphasis>
+ and <emphasis>
+XkbKTMapEntryRec</emphasis>
+ structures. Xkb allows up to <emphasis>
+XkbMaxKeyTypes</emphasis>
+ (255) key types to be defined, but requires at least <emphasis>
+XkbNumRequiredTypes</emphasis>
+ (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
+<emphasis>bell_class</emphasis> and <emphasis>bell_id</emphasis>.
+    </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 <emphasis>
+symbols, geometry, keycodes, compat, </emphasis>
+and<emphasis>
+ types</emphasis>
+ 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 <emphasis>
+XkbGeometryRec</emphasis>
+ 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 <emphasis>
+XkbNamesRec</emphasis>
+ 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 <emphasis>
+XkbNamesRec</emphasis>
+ 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 (<emphasis>
+Shift</emphasis>
+, <emphasis>
+Lock</emphasis>
+, <emphasis>
+Control</emphasis>
+, and <emphasis>
+Mod1</emphasis>
+ through <emphasis>
+Mod5</emphasis>
+), 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 <emphasis>
+XkbModsRec</emphasis>
+, 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 <emphasis>
+XkbIndicatorRec</emphasis>
+ that indicates which indicators are bound to physical LEDs on the keyboard; if
+a bit is set in <emphasis>
+phys_indicators</emphasis>
+, 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 <emphasis>
+symbols</emphasis>
+ 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 <emphasis>
+phys_symbols</emphasis>
+ 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 <emphasis>
+preserve</emphasis>
+ field. If a modifier is present in the <emphasis>
+preserve</emphasis>
+ 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 (<emphasis>
+Shift</emphasis>
+, <emphasis>
+Lock</emphasis>
+, <emphasis>
+Control</emphasis>
+, and <emphasis>
+Mod1</emphasis>
+ through <emphasis>
+Mod5</emphasis>
+); 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 <emphasis>
+symbols</emphasis>
+ 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 <emphasis>
+phys_symbols</emphasis>
+ 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 <emphasis>
+names</emphasis>
+ 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 (<emphasis>
+Shift</emphasis>
+, <emphasis>
+Lock</emphasis>
+, <emphasis>
+Control,</emphasis>
+ and <emphasis>
+Mod1</emphasis>
+-<emphasis>
+Mod5</emphasis>
+).
+    </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>