1
<glossary id='glossary'>
2
<title>Glossary</title>
4
<glossterm>Allocator</glossterm>
7
Xkb provides functions, known as allocators, to create and initialize Xkb data
13
<glossterm>Audible Bell</glossterm>
16
An audible bell is the sound generated by whatever bell is associated with the
17
keyboard or input extension device, as opposed to any other audible sound
18
generated elsewhere in the system.
23
<glossterm>Autoreset Controls</glossterm>
26
The autoreset controls configure the boolean controls to automatically be
27
enabled or disabled at the time a program exits.
32
<glossterm>Base Group</glossterm>
35
The group in effect as a result of all actions other than a previous lock or
36
latch request; the base group is transient. For example, the user pressing and
37
holding a group shift key that shifts to Group2 would result in the base group
38
being group 2 at that point in time. Initially, base group is always Group1.
43
<glossterm>Base Modifiers</glossterm>
46
Modifiers that are turned on as a result of some actions other than previous
47
lock or latch requests; base modifiers are transient. For example, the user
48
pressing and holding a key bound to the Shift modifier would result in Shift
49
being a base modifier at that point in time.
54
<glossterm>Base Event Code</glossterm>
57
A number assigned by the X server at run time that is assigned to the extension
58
to identify events from that extension.
63
<glossterm>Base State</glossterm>
66
The base group and base modifiers represent keys that are physically or
67
logically down; these constitute the base state.
72
<glossterm>Boolean Controls</glossterm>
75
Global keyboard controls that may be selectively enabled and disabled under
76
program control and that may be automatically set to an on or off condition
77
upon client program exit.
82
<glossterm>Canonical Key Types</glossterm>
85
The canonical key types are predefined key types that describe the types of
86
keys available on most keyboards. The definitions for the canonical key types
87
are held in the first <emphasis>
88
XkbNumRequiredTypes</emphasis>
89
entries of the <emphasis>
91
field of the client map and are indexed using the following constants:
96
<emphasis>XkbOneLevelIndex</emphasis>
101
<emphasis>XkbTwoLevelIndex</emphasis>
106
<emphasis>XkbAlphabeticIndex</emphasis>
111
<emphasis>XkbKeypadIndex</emphasis>
119
<glossterm>Client Map</glossterm>
122
The key mapping information needed to convert arbitrary keycodes to symbols.
127
<glossterm>Compat Name</glossterm>
132
name is a string that provides some information about the rules used to bind
133
actions to keys that are changed using core protocol requests.
138
<glossterm>Compatibility State</glossterm>
141
When an Xkb-extended X server connects to an Xkb-unaware client, the
142
compatibility state remaps the keyboard group into a core modifier whenever
148
<glossterm>Compatibility Grab State</glossterm>
151
The grab state that results from applying the compatibility map to the Xkb grab
157
<glossterm>Compatibility Map</glossterm>
160
The definition of how to map core protocol keyboard state to Xkb keyboard state.
165
<glossterm>Component Expression</glossterm>
168
An expression used to describe server keyboard database components to be
169
loaded. It describes the order in which the components should be loaded and the
170
rules by which duplicate attributes should be resolved.
175
<glossterm>Compose Processing</glossterm>
178
The process of mapping a series of keysyms to a string is known as compose
184
<glossterm>Consumed Modifier</glossterm>
187
Xkb normally consumes modifiers in determining the appropriate symbol for an
188
event, that is, the modifiers are not considered during any of the later stages
189
of event processing. For those rare occasions when a modifier <emphasis>
191
be considered despite having been used to look up a symbol, key types include
192
an optional <emphasis>
199
<glossterm>Core Event</glossterm>
202
An event created from the core X server.
207
<glossterm>Detectable Auto-Repeat</glossterm>
210
Detectable auto-repeat allows a client to detect an auto-repeating key. If a
211
client requests and the server supports detectable auto-repeat, Xkb generates
213
KeyRelease</emphasis>
214
events only when the key is physically released. Thus the client receives a
217
events for that key without intervening <emphasis>
218
KeyRelease</emphasis>
219
events until the key is finally released, when a <emphasis>
220
KeyRelease</emphasis>
226
<glossterm>Effective Group</glossterm>
229
The effective group is the arithmetic sum of the locked, latched, and base
230
groups. The effective keyboard group is always brought back into range
231
depending on the value of the <emphasis>
232
GroupsWrap</emphasis>
233
control for the keyboard. If an event occurs with an effective group that is
234
legal for the keyboard as a whole, but not for the key in question, the group
236
for that event only</emphasis>
237
is normalized using the algorithm specified by the <emphasis>
238
group_info</emphasis>
239
member of the key symbol map (<emphasis>
240
XkbSymMapRec</emphasis>
246
<glossterm>Effective Mask</glossterm>
249
An Xkb modifier definition consists of a set of bit masks corresponding to the
250
eight real modifiers; a similar set of bitmasks corresponding to the 16 named
251
virtual modifiers; and an effective mask. The effective mask represents the set
252
of all real modifiers that can logically be set either by setting any of the
253
real modifiers or by setting any of the virtual modifiers in the definition.
258
<glossterm>Effective Modifier</glossterm>
261
The effective modifiers are the bitwise union of the base, latched and locked
267
<glossterm>Extension Device</glossterm>
270
Any keyboard or other input device recognized by the X input extension.
275
<glossterm>Global Keyboard Controls</glossterm>
278
Controls that affect the way Xkb generates key events. The controls affect all
279
keys, as opposed to per-key controls that are for a single key. Global controls
284
<para>RepeatKeys Control</para>
287
<para>DetectableAuto-repeat</para>
290
<para>SlowKeys</para>
293
<para>BounceKeys</para>
296
<para>StickyKeys</para>
299
<para>MouseKeys</para>
302
<para>MouseKeysAccel</para>
305
<para>AccessXKeys</para>
308
<para>AccessXTimeout</para>
311
<para>AccessXFeedback</para>
314
<para>Overlay1</para>
317
<para>Overlay2</para>
320
<para>EnabledControls</para>
326
<glossterm>Grab State</glossterm>
329
The grab state is the state used when matching events to passive grabs. It
330
consists of the grab group and the grab modifiers.
335
<glossterm>Group</glossterm>
337
<para>See Keysym Group</para>
341
<glossterm>Group Index</glossterm>
344
A number used as the internal representation for a group number. Group1 through
345
Group 4 have indices of 0 through 3.
350
<glossterm>Groups Wrap Control</glossterm>
353
If a group index exceeds the maximum number of groups permitted for the
354
specified keyboard, it is wrapped or truncated back into range as specified by
355
the global <emphasis>GroupsWrap</emphasis> control. <emphasis>
356
GroupsWrap</emphasis> can have the following values:
359
<emphasis>WrapIntoRange</emphasis>
360
<emphasis>ClampIntoRange</emphasis>
361
<emphasis>RedirectIntoRange</emphasis>
367
<glossterm>Key Type</glossterm>
370
An attribute of a key that identifies which modifiers affect the shift level of
371
a key and the number of groups on the key.
376
<glossterm>Key Width</glossterm>
379
The maximum number of shift levels in any group for the key type associated
385
<glossterm>Keysym Group</glossterm>
388
A keysym group is a logical state of the keyboard providing access to a
389
collection of characters. A group usually contains a set of characters that
390
logically belong together and that may be arranged on several shift levels
391
within that group. For example, Group1 could be the English alphabet, and
392
Group2 could be Greek. Xkb supports up to four different groups for an input
393
device or keyboard. Groups are in the range 1-4 (Group1 - Group4), and are
394
often referred to as G1 - G4 and indexed as 0 - 3.
399
<glossterm>Indicator</glossterm>
402
An indicator is a feedback mechanism such as an LED on an input device. Using
403
Xkb, a client application can determine the names of the various indicators,
404
determine and control the way that the individual indicators should be updated
405
to reflect keyboard changes, and determine which of the 32 keyboard indicators
406
reported by the protocol are actually present on the keyboard.
411
<glossterm>Indicator Feedback</glossterm>
414
An indicator feedback describes the state of a bank of up to 32 lights. It has
415
a mask where each bit corresponds to a light and an associated value mask that
416
specifies which lights are on or off.
421
<glossterm>Indicator Map</glossterm>
424
An indicator has its own set of attributes that specify whether clients can
425
explicitly set its state and whether it tracks the keyboard state. The
426
indicator map is the collection of these attributes for each indicator and is
427
held in the <emphasis>
429
array, which is an array of <emphasis>
430
XkbIndicatorRec</emphasis>
436
<glossterm>Input Extension</glossterm>
439
An extension to the core X protocol that allows an X server to support multiple
440
keyboards, as well as other input devices, in addition to the core X keyboard
441
and pointer. Other types of devices supported by the input extension include,
442
but are not limited to: mice, tablets, touchscreens, barcode readers, button
443
boxes, trackballs, identifier devices, data gloves, and eye trackers.
448
<glossterm>Key Action</glossterm>
451
A key action consists of an operator and some optional data. Once the server
452
has applied the global controls and per-key behavior and has decided to process
453
a key event, it applies key actions to determine the effects of the key on the
454
internal state of the server. Xkb supports actions that do the following:
459
Change base, latched, or locked modifiers or group
464
Move the core pointer or simulate core pointer button events
469
Change most aspects of keyboard behavior
474
Terminate or suspend the server
479
Send a message to interested clients
484
Simulate events on other keys
492
<glossterm>Key Alias</glossterm>
495
A key alias is a symbolic name for a specific physical key. Key aliases allow
496
the keyboard layout designer to assign multiple key names to a single key. This
497
allows the keyboard layout designer to refer to keys using either their
498
position or their "function." Key aliases can be specified both in the symbolic
499
names component and in the keyboard geometry. Both sets of aliases are always
500
valid, but key alias definitions in the keyboard geometry have priority; if
501
both symbolic names and geometry include aliases, you should consider the
502
definitions from the geometry before considering the definitions from the
503
symbolic names section.
508
<glossterm>Key Behavior</glossterm>
513
field of the server map is an array of <emphasis>
514
XkbBehavior</emphasis>
515
, indexed by keycode, and contains the behavior for each key. The X server uses
516
key behavior to determine whether to process or filter out any given key event;
517
key behavior is independent of keyboard modifier or group state. Each key has
518
exactly one behavior.
520
<para>Key behaviors include:</para>
523
<para>XkbKB_Default</para>
526
<para>XkbKB_Lock</para>
529
<para>XkbKB_RadioGroup</para>
532
<para>XkbKB_Overlay1</para>
535
<para>XkbKB_Overlay2</para>
541
<glossterm>Key Symbol Map</glossterm>
544
A key symbol map describes the symbols bound to a key and the rules to be used
545
to interpret those symbols. It is an array of <emphasis>
546
XkbSymMapRec</emphasis>
547
structures indexed by keycode.
552
<glossterm>Key Type</glossterm>
555
Key types are used to determine the shift level of a key given the current
556
state of the keyboard. There is one key type for each group for a key. Key
557
types are defined using the <emphasis>
558
XkbKeyTypeRec</emphasis>
560
XkbKTMapEntryRec</emphasis>
561
structures. Xkb allows up to <emphasis>
562
XkbMaxKeyTypes</emphasis>
563
(255) key types to be defined, but requires at least <emphasis>
564
XkbNumRequiredTypes</emphasis>
565
(4) predefined types to be in a key map.
570
<glossterm>Keyboard Bells</glossterm>
573
The sound the default bell makes when rung is the system bell or the default
574
keyboard bell. Some input devices may have more than one bell, identified by
575
<emphasis>bell_class</emphasis> and <emphasis>bell_id</emphasis>.
580
<glossterm>Keyboard Components</glossterm>
583
There are five types of components stored in the X server database of keyboard
584
components. They correspond to the <emphasis>
585
symbols, geometry, keycodes, compat, </emphasis>
588
symbolic names associated with a keyboard.
593
<glossterm>Keyboard Feedback</glossterm>
596
A keyboard feedback includes the following:
611
<glossterm>Key Width, Key Type Width</glossterm>
614
The maximum number of shift levels for a type is referred to as the width of a
620
<glossterm>Keyboard Geometry</glossterm>
623
Keyboard geometry describes the physical appearance of the keyboard, including
624
the shape, location, and color of all keyboard keys or other visible keyboard
625
components such as indicators and is stored in a <emphasis>
626
XkbGeometryRec</emphasis>
627
structure. The information contained in a keyboard geometry is sufficient to
628
allow a client program to draw an accurate two-dimensional image of the
634
<glossterm>Keyboard Geometry Name</glossterm>
637
The keyboard geometry name describes the physical location, size, and shape of
638
the various keys on the keyboard and is part of the <emphasis>
639
XkbNamesRec</emphasis>
645
<glossterm>Keyboard State</glossterm>
648
Keyboard state encompasses all of the transitory information necessary to map a
649
physical key press or release to an appropriate event.
654
<glossterm>Keycode</glossterm>
657
A numeric value returned to the X server when a key on a keyboard is pressed or
658
released, indicating which key is being modulated. Keycode numbers are in the
659
range 1 <= keycode <= max, where max is the number of physical keys on
665
<glossterm>Keycode Name</glossterm>
668
The keycode name describes the range and meaning of the keycodes returned by
669
the keyboard and is part of the <emphasis>
670
XkbNamesRec</emphasis>
676
<glossterm>Latched Group</glossterm>
679
A latched group is a group index that is combined with the base and locked
680
group to form the effective group. It applies only to the next key event that
681
does not change the keyboard state. The latched group can be changed by
682
keyboard activity or via Xkb extension library functions.
687
<glossterm>Latched Modifier</glossterm>
690
Latched modifiers are the set of modifiers that are combined with the base
691
modifiers and the locked modifiers to form the effective modifiers. It applies
692
only to the next key event that does not change the keyboard state.
697
<glossterm>LED</glossterm>
700
A light emitting diode. However, for the purposes of the X keyboard extension
701
specification, a LED is any form of visual two-state indicator that is either
707
<glossterm>Locked Group</glossterm>
710
A locked group is a group index that is combined with the base and latched
711
group to form the effective group. When a group is locked, it supersedes any
712
previous locked group and remains the locked group for all future key events,
713
until a new group is locked. The locked group can be changed by keyboard
714
activity or via Xkb extension library functions.
719
<glossterm>Locked Modifiers</glossterm>
722
Locked modifiers are the set of modifiers that are combined with the base
723
modifiers and the latched modifiers to form the effective modifiers. A locked
724
modifier applies to all future key events until it is explicitly unlocked.
729
<glossterm>Lookup State </glossterm>
732
The lookup state is composed of the lookup group and the lookup modifiers, and
733
it is the state an Xkb-capable or Xkb-aware client should use to map a keycode
739
<glossterm>Modifier</glossterm>
742
A modifier is a logical condition that is either set or unset. The modifiers
743
control the Shift Level selected when a key event occurs. Xkb supports the core
744
protocol eight modifiers (<emphasis>
754
), called the <emphasis>
756
modifiers. In addition, Xkb extends modifier flexibility by providing a set of
757
sixteen named virtual modifiers, each of which can be bound to any set of the
758
eight real modifiers.
763
<glossterm>Modifier Key</glossterm>
766
A modifier key is a key whose operation has no immediate effect, but that, for
767
as long as it is held down, modifies the effect of other keys. A modifier key
768
may be, for example, a shift key or a control key.
773
<glossterm>Modifier Definition</glossterm>
776
An Xkb modifier definition, held in an <emphasis>
777
XkbModsRec</emphasis>
778
, consists of a set of real modifiers, a set of virtual modifiers, and an
779
effective mask. The mask is the union of the real modifiers and the set of real
780
modifiers to which the virtual modifiers map; the mask cannot be explicitly
786
<glossterm>Nonkeyboard Extension Device </glossterm>
789
An input extension device that is not a keyboard. Other types of devices
790
supported by the input extension include, but are not limited to: mice,
791
tablets, touchscreens, barcode readers, button boxes, trackballs, identifier
792
devices, data gloves, and eye trackers.
797
<glossterm>Outlines</glossterm>
800
An outline is a list of one or more points that describes a single closed
801
polygon, used in the geometry specification for a keyboard.
806
<glossterm>Physical Indicator Mask</glossterm>
809
The physical indicator mask is a field in the <emphasis>
810
XkbIndicatorRec</emphasis>
811
that indicates which indicators are bound to physical LEDs on the keyboard; if
812
a bit is set in <emphasis>
813
phys_indicators</emphasis>
814
, then the associated indicator has a physical LED associated with it. This
815
field is necessary because some indicators may not have corresponding physical
816
LEDs on the keyboard.
821
<glossterm>Physical Symbol Keyboard Name</glossterm>
826
keyboard name identifies the symbols logically bound to the keys. The symbols
827
name is a human or application-readable description of the intended locale or
828
usage of the keyboard with these symbols. The <emphasis>
829
phys_symbols</emphasis>
830
keyboard name, on the other hand, identifies the symbols actually engraved on
836
<glossterm>Preserved Modifier</glossterm>
839
Xkb normally consumes modifiers in determining the appropriate symbol for an
840
event, that is, the modifiers are not considered during any of the later stages
841
of event processing. For those rare occasions when a modifier <emphasis>
843
be considered despite having been used to look up a symbol, key types include
844
an optional <emphasis>
846
field. If a modifier is present in the <emphasis>
848
list, it is a preserved modifier.
853
<glossterm>Radio Group</glossterm>
856
A radio group is a set of keys whose behavior simulates a set of radio buttons.
857
Once a key in a radio group is pressed, it stays logically depressed until
858
another key in the group is pressed, at which point the previously depressed
859
key is logically released. Consequently, at most one key in a radio group can
860
be logically depressed at one time.
865
<glossterm>Real Modifier</glossterm>
868
Xkb supports the eight core protocol modifiers (<emphasis>
878
); these are called the <emphasis>
880
modifiers, as opposed to the set of sixteen named virtual modifiers that can
881
be bound to any set of the eight real modifiers.
886
<glossterm>Server Internal Modifiers</glossterm>
889
Modifiers that the server uses to determine the appropriate symbol for an
890
event; internal modifiers are normally consumed by the server.
895
<glossterm>Shift Level</glossterm>
898
One of several states (normally 2 or 3) governing which graphic character is
899
produced when a key is actuated.
904
<glossterm>Symbol Keyboard Name</glossterm>
909
keyboard name identifies the symbols logically bound to the keys. The symbols
910
name is a human or application-readable description of the intended locale or
911
usage of the keyboard with these symbols. The <emphasis>
912
phys_symbols</emphasis>
913
keyboard name, on the other hand, identifies the symbols actually engraved on
919
<glossterm>Symbolic Name</glossterm>
922
Xkb supports symbolic names for most components of the keyboard extension. Most
923
of these symbolic names are grouped into the <emphasis>
925
component of the keyboard description.
930
<glossterm>State Field</glossterm>
933
The portion of a client-side core protocol event that holds the modifier,
934
group, and button state information pertaining to the event.
939
<glossterm>Types Name</glossterm>
944
name provides some information about the set of key types that can be
945
associated with the keyboard. In addition, each key type can have a name, and
946
each shift level of a type can have a name.
951
<glossterm>Valuator</glossterm>
954
A valuator reports a range of values for some entity, like a mouse axis, a
960
<glossterm>Virtual Modifier</glossterm>
963
Xkb provides a set of sixteen named virtual modifiers that can be bound to any
964
set of the eight real modifiers. Each virtual modifier can be bound to any set
965
of the real modifiers (<emphasis>
980
<glossterm>Virtual Modifier Mapping</glossterm>
983
Xkb maintains a virtual modifier mapping, which lists the virtual modifiers
984
associated with each key.
989
<glossterm>Xkb-aware Client</glossterm>
992
A client application that initializes Xkb extension and is consequently bound
993
to an Xlib that includes the Xkb extension.
998
<glossterm>Xkb-capable Client</glossterm>
1001
A client application that makes no Xkb extension Xlib calls but is bound to an
1002
Xlib that includes the Xkb extension.
1007
<glossterm>Xkb-unaware Client</glossterm>
1010
A client application that makes no Xkb extension Xlib calls and is bound to an
1011
Xlib that does not include the Xkb extension.
added
removed
specs/XKB/glossary.xml
