1017 lines
29 KiB
XML
1017 lines
29 KiB
XML
<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 <= keycode <= 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>
|