fdo-mirrors/xorg-xorgproto
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/xorg/proto/xorgproto.git synced 2026-05-09 04:48:06 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

Remove duplicate 'See see' text in docs - take 2

Browse source
This commit is contained in:
Matt Dew 2011-03-15 23:30:15 -06:00
parent c336374f3b
commit b82c9b3f75
15 changed files with 136 additions and 119 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
specs/ch02.xml
View file

@ -273,7 +273,7 @@ ServerInternalModifiers</emphasis>
IgnoreLocksModifiers</emphasis>
and <emphasis>
IgnoreGroupLock</emphasis>
controls, described in <link linkend='server_internal_modifiers_and_ignore_locks_behavior'>See Server
controls, described in <link linkend='server_internal_modifiers_and_ignore_locks_behavior'>Server
Internal Modifiers and Ignore Locks Behavior</link>, to derive these two
states as follows:
</para>
@ -355,7 +355,7 @@ The core protocol interpretation of
keyboard modifiers does not include direct support for multiple groups, so XKB
reports the effective keyboard group to XKB-aware clients using some of the
reserved bits in the state field of some core protocol events, as described in
<link linkend='computing_a_state_field_from_an_xkb_state'>See Computing A State Field from an
<link linkend='computing_a_state_field_from_an_xkb_state'>Computing A State Field from an
XKB State</link>.
</para>
@ -363,7 +363,7 @@ XKB State</link>.
This modified state field would not be interpreted correctly by XKB-unaware
clients, so XKB provides a <emphasis>
group compatibility mapping</emphasis>
(see <link linkend='group_compatibility_map'>See Group Compatibility Map</link>) which
(see <link linkend='group_compatibility_map'>Group Compatibility Map</link>) which
remaps the keyboard group into a core modifier mask that has similar effects,
when possible. XKB maintains three compatibility state components that are used
to make non-XKB clients work as well as possible:
@ -398,7 +398,7 @@ of the grab state.
<para>
Compatibility states are essentially the corresponding XKB state, but with
keyboard group possibly encoded as one or more modifiers; <link linkend='group_compatibility_map'>See Group Compatibility Map</link> describes
keyboard group possibly encoded as one or more modifiers; <link linkend='group_compatibility_map'>Group Compatibility Map</link> describes
the group compatibility map, which specifies the modifier(s) that correspond to
each keyboard group.
</para>

2
specs/ch03.xml
View file

@ -212,7 +212,7 @@ NumLock</emphasis>
<para>
The virtual modifier mapping is normally updated automatically whenever actions
are assigned to keys (see <link linkend='changing_the_keyboard_mapping_using_the_core_protocol'>See Changing
are assigned to keys (see <link linkend='changing_the_keyboard_mapping_using_the_core_protocol'>Changing
the Keyboard Mapping Using the Core Protocol</link> for details) and few
applications should need to change the virtual modifier mapping explicitly.
</para>

31
specs/ch04.xml
View file

@ -99,7 +99,7 @@ whether or not it is supported.
<para>
<link linkend='querying_and_changing_per_client_flags'>See Querying and Changing Per-Client
<link linkend='querying_and_changing_per_client_flags'>Querying and Changing Per-Client
Flags</link> describes the <emphasis>
XkbPerClientFlags</emphasis>
request, which reports or changes values for all of the per-client flags, and
@ -148,7 +148,7 @@ rejection or release of any key to interested clients using <emphasis>
AccessXNotify</emphasis>
events. The <emphasis>
AccessXNotify</emphasis>
event is described in more detail in <link linkend='events'>See Events</link>.
event is described in more detail in <link linkend='events'>Events</link>.
</para>
</sect1>
@ -183,7 +183,7 @@ interested clients by sending an <emphasis>
AccessXNotify</emphasis>
event. The <emphasis>
AccessXNotify</emphasis>
event is described in more detail in <link linkend='events'>See Events</link>.
event is described in more detail in <link linkend='events'>Events</link>.
</para>
</sect1>
@ -375,7 +375,7 @@ When <emphasis>
MouseKeys</emphasis>
are active and a <emphasis>
SA_MovePtr</emphasis>
key action (see <link linkend='key_actions'>See Key
key action (see <link linkend='key_actions'>Key
Actions</link>) is activated, a pointer motion event is generated immediately.
If <emphasis>
MouseKeysAccel</emphasis>
@ -515,11 +515,10 @@ StickyKeys</emphasis>
<para>
Some of these key sequences optionally generate audible feedback of the change
in state, as described in <link linkend='the_accessxfeedback_control'>See The
in state, as described in <link linkend='the_accessxfeedback_control'>The
AccessXFeedback Control</link>, or cause <emphasis>
XkbAccessXNotify</emphasis>
events as described in <link linkend='events'>See
Events</link>.
events as described in <link linkend='events'>Events</link>.
</para>
@ -779,7 +778,7 @@ should generate when that overlay is enabled, assign it either the <emphasis>
KB_Overlay1</emphasis>
or <emphasis>
KB_Overlay2</emphasis>
key behaviors, as described in <link linkend='key_behavior'>See
key behaviors, as described in <link linkend='key_behavior'>
Key Behavior</link>.
</para>
@ -791,10 +790,10 @@ Key Behavior</link>.
<para>
All of the controls described above, along with the <emphasis>
AudibleBell</emphasis>
control (described in <link linkend='disabling_server_generated_bells'>See Disabling
control (described in <link linkend='disabling_server_generated_bells'>Disabling
Server Generated Bells</link>) and the <emphasis>
IgnoreGroupLock</emphasis>
control (described in <link linkend='server_internal_modifiers_and_ignore_locks_behavior'>See Server
control (described in <link linkend='server_internal_modifiers_and_ignore_locks_behavior'>Server
Internal Modifiers and Ignore Locks Behavior</link>) comprise the <emphasis>
boolean controls</emphasis>
. In addition to any parameters listed in the descriptions of the individual
@ -813,18 +812,18 @@ EnabledControls</emphasis>
control or specified in any context that accepts only boolean controls:
<emphasis>
GroupsWrap</emphasis>
(<link linkend='computing_effective_modifier_and_group'>See Computing Effective Modifier and
(<link linkend='computing_effective_modifier_and_group'>Computing Effective Modifier and
Group</link>), <emphasis>
EnabledControls</emphasis>
, <emphasis>
InternalMods</emphasis>
(<link linkend='server_internal_modifiers_and_ignore_locks_behavior'>See Server Internal Modifiers and
(<link linkend='server_internal_modifiers_and_ignore_locks_behavior'>Server Internal Modifiers and
Ignore Locks Behavior</link>), and <emphasis>
IgnoreLockMods</emphasis>
(<link linkend='server_internal_modifiers_and_ignore_locks_behavior'>See Server Internal Modifiers and
(<link linkend='server_internal_modifiers_and_ignore_locks_behavior'>Server Internal Modifiers and
Ignore Locks Behavior</link>) and <emphasis>
PerKeyRepeat</emphasis>
(<link linkend='the_repeatkeys_control'>See The RepeatKeys Control</link>)
(<link linkend='the_repeatkeys_control'>The RepeatKeys Control</link>)
</para>
@ -836,7 +835,7 @@ PerKeyRepeat</emphasis>
The <emphasis>
auto-reset controls</emphasis>
are a per-client value which consist of two masks that can contain any of the
boolean controls (see <link linkend='boolean_controls_and_the_enabledcontrols_control'>See "Boolean"
boolean controls (see <link linkend='boolean_controls_and_the_enabledcontrols_control'>"Boolean"
Controls and The EnabledControls Control</link>). Whenever the client exits
for any reason, any boolean controls specified in the <emphasis>
auto-reset mask</emphasis>
@ -851,7 +850,7 @@ automatically, even if abnormally terminated.
For example, a client that replace the keyboard bell with some other audible
cue might want to turn off the <emphasis>
AudibleBell</emphasis>
control (<link linkend='disabling_server_generated_bells'>See Disabling Server
control (<link linkend='disabling_server_generated_bells'>Disabling Server
Generated Bells</link>) to prevent the server from also generating a sound and
thus avoid cacophony. If the client were to exit without resetting the
<emphasis>

16
specs/ch05.xml
View file

@ -19,7 +19,8 @@ elapsed while the <emphasis>
RepeatKeys</emphasis>
control can cause multiple X events from a single physical key press if the
key is held down for an extended period. The global keyboard controls affect
all of the keys on the keyboard and are described in <link linkend='global_keyboard_controls'>See Global Keyboard Controls</link>.
all of the keys on the keyboard and are described in
<link linkend='global_keyboard_controls'>Global Keyboard Controls</link>.
</para>
</listitem>
<listitem>
@ -29,7 +30,8 @@ keyboard overlays, in which a key generates an alternate keycode under certain
circumstances, can be implemented using per-key behavior. Every key has a
single behavior, so the effect of key behavior does not depend on keyboard
modifier or group state, though it might depend on global keyboard controls.
Per-key behaviors are described in detail in <link linkend='key_behavior'>See Key Behavior</link>.
Per-key behaviors are described in detail in
<link linkend='key_behavior'>Key Behavior</link>.
</para>
</listitem>
<listitem>
@ -37,7 +39,7 @@ Per-key behaviors are described in detail in <link linkend='key_behavior'>See Ke
keyboard has some action associated with it. The key action tells the server
what to do when an event which yields the corresponding keysym is generated.
Key actions might change or suppress the event, generate some other event, or
change some aspect of the server. Key actions are described in <link linkend='key_actions'>See Key Actions</link>.
change some aspect of the server. Key actions are described in <link linkend='key_actions'>Key Actions</link>.
</para>
</listitem>
</orderedlist>
@ -50,13 +52,13 @@ event, the client which receives the event processes it in several steps.
<orderedlist>
<listitem>
<para>First the client extracts the effective keyboard group and a set of
modifiers from the state field of the event. See <link linkend='computing_a_state_field_from_an_xkb_state'>See Computing A State Field from an XKB
modifiers from the state field of the event. See <link linkend='computing_a_state_field_from_an_xkb_state'>Computing A State Field from an XKB
State</link> for details.
</para>
</listitem>
<listitem>
<para>Using the modifiers and effective keyboard group, the client selects a
symbol from the list of keysyms bound to the key. <link linkend='determining_the_keysym_associated_with_a_key_event'>See Determining the KeySym Associated with a
symbol from the list of keysyms bound to the key. <link linkend='determining_the_keysym_associated_with_a_key_event'>Determining the KeySym Associated with a
Key Event</link> discusses symbol selection.
</para>
</listitem>
@ -66,7 +68,9 @@ using any modifiers that are "left over" from the process of looking up a
symbol. For example, if the <emphasis>
Lock</emphasis>
modifier is left over, the resulting keysym is capitalized according to the
capitalization rules specified by the system. See <link linkend='transforming_the_keysym_associated_with_a_key_event'>See Transforming the KeySym Associated with a
capitalization rules specified by the system. See
<link linkend='transforming_the_keysym_associated_with_a_key_event'>
Transforming the KeySym Associated with a
Key Event</link> for a more detailed discussion of the transformations defined
by XKB.
</para>

16
specs/ch06.xml
View file

@ -262,7 +262,7 @@ list of symbols associated with the key (i.e. it has one action per symbol
associated with the key). For key press events, the server looks up the action
to be applied from this list using the key symbol mapping associated with the
event key, just as a client looks up symbols as described in <link
linkend="determining_the_keysym_associated_with_a_key_event">See Determining the KeySym Associated with a
linkend="determining_the_keysym_associated_with_a_key_event">Determining the KeySym Associated with a
Key Event</link>; if the event key does not have any actions, the server uses
the <emphasis>
SA_NoAction</emphasis>
@ -292,7 +292,7 @@ delay between the activation of one and the other.
<para>
Most actions which affect keyboard modifier state accept a modifier definition
(see <link linkend="virtual_modifiers">See Virtual Modifiers</link>)
(see <link linkend="virtual_modifiers">Virtual Modifiers</link>)
named <emphasis>
mods</emphasis>
and a boolean flag name <emphasis>
@ -679,7 +679,7 @@ MouseKeysAccel</emphasis>
keyboard control is enabled, key press also initiates the mouse keys timer for
this key; every time this timer expires, the cursor moves again. The distance
the cursor moves in these subsequent events is determined by the mouse keys
acceleration as described in <link linkend="the_mousekeysaccel_control">See The
acceleration as described in <link linkend="the_mousekeysaccel_control">The
MouseKeysAccel Control</link>.
</para>
</listitem>
@ -1627,7 +1627,7 @@ event that caused them.
Events sent to clients that have not issued an <emphasis>
XkbUseExtension</emphasis>
request contain a compatibility state in place of the actual XKB keyboard
state. See <link linkend="effects_of_xkb_on_core_protocol_events">See Effects of XKB on Core
state. See <link linkend="effects_of_xkb_on_core_protocol_events">Effects of XKB on Core
Protocol Events</link> for a description of this compatibility mapping.
</para>
@ -1647,7 +1647,7 @@ the following changes:
<listitem>
<para>A passive grab triggers if the modifier state specified in the grab
matches the grab compatibility state (described in <link
linkend="compatibility_components_of_keyboard_state">See Compatibility Components of Keyboard
linkend="compatibility_components_of_keyboard_state">Compatibility Components of Keyboard
State</link>). Clients can choose to use the XKB grab state instead by setting
the <emphasis>
GrabsUseXKBState</emphasis>
@ -1678,14 +1678,14 @@ LookupStateWhenGrabbed</emphasis>
<listitem>
<para>Otherwise, the state field of events that do not trigger a passive grab
report is derived from the XKB effective modifiers and group, as described in
<link linkend="computing_a_state_field_from_an_xkb_state">See Computing A State Field from an
<link linkend="computing_a_state_field_from_an_xkb_state">Computing A State Field from an
XKB State</link>.
</para>
</listitem>
<listitem>
<para>If a key release event is the result of an autorepeating key that is
being held down, and the client to which the event is reported has requested
detectable autorepeat (see <link linkend="detectable_autorepeat">See
detectable autorepeat (see <link linkend="detectable_autorepeat">
Detectable Autorepeat</link>), the event is not delivered to the client.
</para>
</listitem>
@ -1720,7 +1720,7 @@ interact.
<listitem>
<para>The largest problems arise from the fact that an XKB state field
encodes an explicit keyboard group in bits 13-14 (as described in <link
linkend="computing_a_state_field_from_an_xkb_state">See Computing A State Field from an XKB
linkend="computing_a_state_field_from_an_xkb_state">Computing A State Field from an XKB
State</link>), while pre-XKB clients use one of the eight keyboard modifiers
to select an alternate keyboard group. To make existing clients behave
reasonably, XKB normally uses the compatibility grab state instead of the XKB

28
specs/ch07.xml
View file

@ -7,7 +7,7 @@ client map</emphasis>
for a keyboard is the collection of information a client needs to interpret
key events that come from that keyboard. It contains a global list of <emphasis>
key types</emphasis>
, described in <link linkend='key_types'>See Key Types</link>,
, described in <link linkend='key_types'>Key Types</link>,
and an array of <emphasis>
key symbol map</emphasis>
s, each of which describes the symbols bound to one particular key and the
@ -19,7 +19,7 @@ rules to be used to interpret those symbols.
<para>
XKB associates a two-dimensional array of symbols with each key. Symbols are
addressed by keyboard group (see <link linkend='keyboard_state'>See
addressed by keyboard group (see <link linkend='keyboard_state'>
Keyboard State</link>) and shift level, where level is defined as in the
ISO9995 standard:
</para>
@ -86,13 +86,13 @@ group and shift level that correspond to the event.
<para>
Group is reported in bits 13-14 of the state field of the key event, as
described in <link linkend='computing_a_state_field_from_an_xkb_state'>See Computing A State
described in <link linkend='computing_a_state_field_from_an_xkb_state'>Computing A State
Field from an XKB State</link>. The keyboard group reported in the event might
be out-of-range for any particular key because the number of groups can vary
from key to key. The XKB description of each key contains a <emphasis>
group info</emphasis>
field which is interpreted identically to the global groups wrap control (see
<link linkend='computing_effective_modifier_and_group'>See Computing Effective Modifier and
<link linkend='computing_effective_modifier_and_group'>Computing Effective Modifier and
Group</link>) and which specifies the interpretation of groups that are
out-of-range for that key.
</para>
@ -104,7 +104,7 @@ determine the shift level. The description of a key includes a <emphasis>
key type</emphasis>
for each group of symbols bound to the key. Given the modifiers from the key
event, this key type yields a shift level and a set of "leftover" modifiers, as
described in <link linkend='key_types'>See Key Types</link>
described in <link linkend='key_types'>Key Types</link>
below.
</para>
@ -125,7 +125,7 @@ map</emphasis>
field specifies the shift level that corresponds to some XKB modifier
definition; any combination of modifiers that is not explicitly listed
somewhere in the map yields shift level one. Map entries which specify unbound
virtual modifiers (see <link linkend='inactive_modifier_definitions'>See Inactive
virtual modifiers (see <link linkend='inactive_modifier_definitions'>Inactive
Modifier Definitions</link>) are not considered; each entry contains an
automatically-updated <emphasis>
active</emphasis>
@ -161,7 +161,7 @@ Any modifiers specified in <emphasis>
modifiers</emphasis>
are normally <emphasis>
consumed</emphasis>
(see <link linkend='transforming_the_keysym_associated_with_a_key_event'>See Transforming the KeySym
(see <link linkend='transforming_the_keysym_associated_with_a_key_event'>Transforming the KeySym
Associated with a Key Event</link>), which means that they are not considered
during any of the later stages of event processing. For those rare occasions
that a modifier <emphasis>
@ -427,7 +427,9 @@ Control</emphasis>
<entry>Report the control character associated with the symbol. This
extension defines the control characters associated with the ASCII alphabetic
characters (both upper and lower case) and for a small set of punctuation
characters (see <link linkend="default_symbol_transformations">Default Symbol Transformations</link>). Applications are
characters (see
<link linkend="default_symbol_transformations">Default Symbol Transformations</link>).
Applications are
free to associate control characters with any symbols that are not specified by
this extension.</entry>
</row>
@ -449,11 +451,9 @@ Interpretation of other modifiers is application dependent.
<note><para>This definition of capitalization is fundamentally different from
the core protocol’s, which uses the lock modifier to select from the symbols
bound to the key. Consider key 9 in the example keyboard on <link
linkend="client_map_example">See Consider a simple, if
unlikely, keyboard with the following keys (gray characters indicate symbols
that are implied or expected but are not actually engraved on the
key):</link>; the core protocol provides no way to generate the capital form
bound to the key. Consider key 9 in the
<link linkend="client_map_example">client map example</link>;
the core protocol provides no way to generate the capital form
of either symbol bound to this key. XKB specifies that we first look up the
symbol and then capitalize, so XKB yields the capital form of the two symbols
when caps lock is active. </para></note>
@ -677,7 +677,7 @@ to be used. The key type determines which symbol is chosen from the list.
<para>
<link linkend='determining_the_keysym_associated_with_a_key_event'>See Determining the KeySym Associated
<link linkend='determining_the_keysym_associated_with_a_key_event'>Determining the KeySym Associated
with a Key Event</link> details the procedure to map from a key event to a
symbol and/or a string.
</para>

6
specs/ch08.xml
View file

@ -86,7 +86,9 @@ symbols</emphasis>
geometry</emphasis>
names typically correspond to the keyboard components from which the current
keyboard description was assembled. These components are stored individually in
the server’s database of keyboard components, described in <link linkend='the_server_database_of_keyboard_components'>See The Server Database of Keyboard
the server’s database of keyboard components, described in
<link linkend='the_server_database_of_keyboard_components'>
The Server Database of Keyboard
Components</link>, and can be combined to assemble a complete keyboard
description.
</para>
@ -130,7 +132,7 @@ customizations are straightforward.
<para>
Key aliases can be specified both in the symbolic names component and in the
keyboard geometry (see <link linkend='keyboard_geometry'>See Keyboard
keyboard geometry (see <link linkend='keyboard_geometry'>Keyboard
Geometry</link>). 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, applications should consider the definitions from the

8
specs/ch09.xml
View file

@ -60,7 +60,7 @@ keyboard, it cannot be directly changed under program control. It is possible,
however, for the set of physical indicators to be change if a new keyboard is
attached or if a completely new keyboard description is loaded by the <emphasis>
XkbGetKeyboardByName</emphasis>
request (see <link linkend='using_the_servers_database_of_keyboard_components'>See Using the Server’s
request (see <link linkend='using_the_servers_database_of_keyboard_components'>Using the Server’s
Database of Keyboard Components</link>).
</para>
@ -88,7 +88,7 @@ XkbGetNames</emphasis>
request reports the symbolic names for all keyboard components, including the
indicators. Use the <emphasis>
XkbSetNames</emphasis>
request to change symbolic names. Both requests are described in <link linkend='querying_and_changing_symbolic_names'>See Querying and Changing Symbolic
request to change symbolic names. Both requests are described in <link linkend='querying_and_changing_symbolic_names'>Querying and Changing Symbolic
Names</link>.
</para>
@ -232,7 +232,7 @@ mods</emphasis>
fields of an indicator map determine how the state of the keyboard modifiers
affect the corresponding indicator. The <emphasis>
mods</emphasis>
field is an XKB modifier definition, as described in <link linkend='modifier_definitions'>See Modifier Definitions</link>, which can
field is an XKB modifier definition, as described in <link linkend='modifier_definitions'>Modifier Definitions</link>, which can
specify both real and virtual modifiers. The mods field takes effect even if
some or all of the virtual indicators specified in <emphasis>
mods</emphasis>
@ -305,7 +305,7 @@ IM_UseCompat</emphasis>
<para>
The <emphasis>
controls</emphasis>
field specifies a subset of the boolean keyboard controls (see <link linkend='boolean_controls_and_the_enabledcontrols_control'>See "Boolean" Controls and The
field specifies a subset of the boolean keyboard controls (see <link linkend='boolean_controls_and_the_enabledcontrols_control'>"Boolean" Controls and The
EnabledControls Control</link>). The indicator is lit whenever any of the
boolean controls specified in <emphasis>
controls</emphasis>

2
specs/ch10.xml
View file

@ -110,7 +110,7 @@ sounds other than simple tones, but it is not required to do so.
<para>
Aside from those used by the XKB <emphasis>
AccessXFeedback</emphasis>
control (see <link linkend='the_accessxfeedback_control'>See The AccessXFeedback
control (see <link linkend='the_accessxfeedback_control'>The AccessXFeedback
Control</link>), this extension does not specify bell names or their
interpretation.
</para>

4
specs/ch11.xml
View file

@ -79,7 +79,7 @@ structures refer to geometry properties.
<listitem>
<para>A list of <emphasis>
key aliases</emphasis>
, as described in <link linkend='symbolic_names'>See Symbolic
, as described in <link linkend='symbolic_names'>Symbolic
Names</link>.
</para>
</listitem>
@ -89,7 +89,7 @@ shapes</emphasis>
; other keyboard components refer to shapes by their index in this list. A
shape consists of a name and one or more closed-polygons called <emphasis>
outlines</emphasis>
. Shapes and outlines are described in detail in <link linkend='shapes_and_outlines'>See Shapes and Outlines</link>.
. Shapes and outlines are described in detail in <link linkend='shapes_and_outlines'>Shapes and Outlines</link>.
</para>
</listitem>
</itemizedlist>

28
specs/ch12.xml
View file

@ -53,7 +53,7 @@ of a keyboard mapping and XKB and explains the ways they can interact.
<title>Group Compatibility Map</title>
<para>
As described in <link linkend='keyboard_state'>See Keyboard
As described in <link linkend='keyboard_state'>Keyboard
State</link>, the current keyboard group is reported to XKB-aware clients in
bits 13-14 of the state field of many core protocol events. XKB-unaware clients
cannot interpret those bits, but they might use a keyboard modifier to
@ -243,40 +243,40 @@ field for a key can contain any combination of the following values:
<entry>ExplicitKeyType1</entry>
<entry>Automatic determination of the key type associated with <emphasis>
Group1</emphasis>
(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>See Assigning Types To Groups of
(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>Assigning Types To Groups of
Symbols for a Key</link>)</entry>
</row>
<row rowsep='0'>
<entry>ExplicitKeyType2</entry>
<entry>Automatic determination of the key type associated with <emphasis>
Group2 </emphasis>
(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>See Assigning Types To Groups of
(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>Assigning Types To Groups of
Symbols for a Key</link>)</entry>
</row>
<row rowsep='0'>
<entry>ExplicitKeyType3</entry>
<entry>Automatic determination of the key type associated with <emphasis>
Group3 </emphasis>
(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>See Assigning Types To Groups of
(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>Assigning Types To Groups of
Symbols for a Key</link>).</entry>
</row>
<row rowsep='0'>
<entry>ExplicitKeyType4</entry>
<entry>Automatic determination of the key type associated with <emphasis>
Group4 </emphasis>
(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>See Assigning Types To Groups of
(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>Assigning Types To Groups of
Symbols for a Key</link>).</entry>
</row>
<row rowsep='0'>
<entry>ExplicitInterpret</entry>
<entry>Application of any of the fields of a symbol interpretation to the
key in question (see <link linkend='assigning_actions_to_keys'>See Assigning
key in question (see <link linkend='assigning_actions_to_keys'>Assigning
Actions To Keys</link>).</entry>
</row>
<row rowsep='0'>
<entry>ExplicitAutoRepeat</entry>
<entry>Automatic determination of autorepeat status for the key, as
specified in a symbol interpretation (see <link linkend='assigning_actions_to_keys'>See Assigning Actions To
specified in a symbol interpretation (see <link linkend='assigning_actions_to_keys'>Assigning Actions To
Keys</link>).</entry>
</row>
<row rowsep='0'>
@ -285,14 +285,14 @@ Keys</link>).</entry>
KB_Lock</emphasis>
behavior to the key, if the <emphasis>
LockingKey</emphasis>
flag is set in a symbol interpretation (see <link linkend='assigning_actions_to_keys'>See Assigning Actions To
flag is set in a symbol interpretation (see <link linkend='assigning_actions_to_keys'>Assigning Actions To
Keys</link>).</entry>
</row>
<row rowsep='0'>
<entry>ExplicitVModMap</entry>
<entry>Automatic determination of the virtual modifier map for the key
based on the actions assigned to the key and the symbol interpretations which
match the key (see <link linkend='assigning_actions_to_keys'>See Assigning
match the key (see <link linkend='assigning_actions_to_keys'>Assigning
Actions To Keys</link>).</entry>
</row>
</tbody>
@ -310,7 +310,7 @@ ChangeKeyboardMapping</emphasis>
groups that are defined for the key and the width of each group. The XKB
extension does not change key types in response to core protocol <emphasis>
SetModifierMapping</emphasis>
requests, but it does choose key actions as described in <link linkend='assigning_actions_to_keys'>See Assigning Actions To Keys</link>.
requests, but it does choose key actions as described in <link linkend='assigning_actions_to_keys'>Assigning Actions To Keys</link>.
</para>
@ -487,7 +487,7 @@ ALPHABETIC</emphasis>
<entry>Describes alphabetic keys that have exactly two symbols per group.
The default definition of the <emphasis>
ALPHABETIC</emphasis>
type provides shift-cancels-caps behavior as described in <link linkend='key_types'>See Key Types</link>. Index <emphasis>
type provides shift-cancels-caps behavior as described in <link linkend='key_types'>Key Types</link>. Index <emphasis>
2</emphasis>
in any key symbol map specifies key type <emphasis>
ALPHABETIC</emphasis>
@ -733,7 +733,7 @@ locking key</emphasis>
field is set in the symbol interpretation, the behavior of the key is changed
to <emphasis>
KB_Lock</emphasis>
(see <link linkend='key_behavior'>See Key Behavior</link>). The
(see <link linkend='key_behavior'>Key Behavior</link>). The
<emphasis>
ExplicitBehavior</emphasis>
component prevents this change.
@ -787,7 +787,7 @@ indicator maps, internal modifiers or ignore locks modifiers.
After applying server actions which modify the base, latched or locked modifier
or group state of the keyboard, the X server recomputes the effective group and
state. Several components of the keyboard state are reported to XKB-aware
clients depending on context (see <link linkend='keyboard_state'>See
clients depending on context (see <link linkend='keyboard_state'>
Keyboard State</link> for a detailed description of each of the keyboard state
components):
</para>
@ -963,7 +963,7 @@ by all of the actions associated with the key plus all of the modifiers
associated with any virtual modifiers bound to the key by the virtual modifier
mapping. If any of the actions associated with a key affect any component of
the keyboard group, any modifiers specified in any entry of the group
compatibility map (see <link linkend='group_compatibility_map'>See Group
compatibility map (see <link linkend='group_compatibility_map'>Group
Compatibility Map</link>) are reported in the modifier mask. The <emphasis>
SA_ISOLock</emphasis>
action can theoretically affect any modifier, but the modifier map of an

3
specs/ch13.xml
View file

@ -275,7 +275,8 @@ types</emphasis>
component of a keyboard mapping specifies the key types that can be associated
with the various keyboard keys. It affects the <emphasis>
types</emphasis>
symbolic name and the list of types associated with the keyboard (see <link linkend='key_types'>See Key Types</link>). The types component
symbolic name and the list of types associated with the keyboard (see
<link linkend='key_types'>Key Types</link>). The types component
of a keyboard mapping can also optionally contain real modifier bindings and
symbolic names for one or more virtual modifiers.
</para>

2
specs/ch14.xml
View file

@ -9,7 +9,7 @@ keycodes. The server can generate an <emphasis>
XkbNewKeyboardNotify</emphasis>
event when it detects a new keyboard, or in response to an <emphasis>
XkbGetKeyboardByName</emphasis>
request (see <link linkend='using_the_servers_database_of_keyboard_components'>See Using the Server’s
request (see <link linkend='using_the_servers_database_of_keyboard_components'>Using the Server’s
Database of Keyboard Components</link>) which loads a new keyboard description.
</para>

2
specs/ch15.xml
View file

@ -113,7 +113,7 @@ Keyboard</emphasis>
<para>
The XKB extension optionally allows clients to assign any key action (see
<link linkend='key_actions'>See Key Actions</link>) to core
<link linkend='key_actions'>Key Actions</link>) to core
pointer or input extension device buttons. This makes it possible to control
the keyboard or generate keyboard key events from extension devices or from the
core pointer.

99
specs/ch16.xml
View file

@ -1215,7 +1215,7 @@ affectWhich</emphasis>
<para>
If any components are specified in a client’s event masks, the X server sends
the client an appropriate event whenever any of those components change state.
Unless explicitly modified, all event detail masks are empty. <link linkend='events'>See Events</link> describes all XKB events
Unless explicitly modified, all event detail masks are empty. <link linkend='events'>Events</link> describes all XKB events
and the conditions under which the server generates them.
</para>
@ -1532,7 +1532,7 @@ effective modifiers minus any server internal modifiers. The <emphasis>
grabMods</emphasis>
return value reports the grab modifiers, which consist of the lookup modifiers
minus any members of the ignore locks mask that are not either latched or
logically depressed. <link linkend='keyboard_state'>See Keyboard
logically depressed. <link linkend='keyboard_state'>Keyboard
State</link> describes the lookup modifiers and grab modifiers in more detail.
</para>
@ -1556,7 +1556,7 @@ compatGrabMods</emphasis>
return values report the core protocol compatibility states that correspond to
the XKB lookup and grab state. All of the compatibility states are computed by
applying the group compatibility mapping to the corresponding XKB modifier and
group states, as described in <link linkend='group_compatibility_map'>See
group states, as described in <link linkend='group_compatibility_map'>
Group Compatibility Map</link>.
</para>
@ -1821,13 +1821,14 @@ The <emphasis>
numGroups</emphasis>
return value reports the current number of groups, and <emphasis>
groupsWrap</emphasis>
reports the treatment of out-of-range groups, as described in <link linkend='key_symbol_map'>See Key Symbol Map</link>. The <emphasis>
reports the treatment of out-of-range groups, as described in <link linkend='key_symbol_map'>Key Symbol Map</link>. The <emphasis>
internalMods</emphasis>
and <emphasis>
ignoreLockMods</emphasis>
return values report the current values of the server internal and ignore
locks modifiers as described in <link linkend='keyboard_state'>See
Keyboard State</link>. Both are modifier definitions (<link linkend='modifier_definitions'>See Modifier Definitions</link>) which
locks modifiers as described in <link linkend='keyboard_state'>
Keyboard State</link>. Both are modifier definitions (
<link linkend='modifier_definitions'>Modifier Definitions</link>) which
report the real modifiers, virtual modifiers, and the resulting combination of
real modifiers that are bound to the corresponding control.
</para>
@ -1854,7 +1855,7 @@ mouseKeysMaxSpeed</emphasis>
and <emphasis>
mouseKeysCurve</emphasis>
return values report the current acceleration applied to mouse keys, as
described in <link linkend='the_mousekeysaccel_control'>See The MouseKeysAccel
described in <link linkend='the_mousekeysaccel_control'>The MouseKeysAccel
Control</link>. All times are reported in milliseconds.
</para>
@ -2221,7 +2222,8 @@ If applied, <emphasis>
repeatDelay</emphasis>
and <emphasis>
repeatInterval</emphasis>
change the autorepeat characteristics of the keyboard, as described in <link linkend='the_repeatkeys_control'>See The RepeatKeys Control</link>. If
change the autorepeat characteristics of the keyboard, as described in
<link linkend='the_repeatkeys_control'>The RepeatKeys Control</link>. If
specified, <emphasis>
repeatDelay</emphasis>
and <emphasis>
@ -2237,7 +2239,7 @@ If applied, the <emphasis>
slowKeysDelay</emphasis>
field specifies a new delay for the <emphasis>
SlowKeys</emphasis>
control, as defined in <link linkend='the_slowkeys_control'>See The
control, as defined in <link linkend='the_slowkeys_control'>The
SlowKeys Control</link>. If specified, <emphasis>
slowKeysDelay</emphasis>
must be non-zero, or a <emphasis>
@ -2251,7 +2253,7 @@ If applied, the <emphasis>
debounceDelay</emphasis>
field specifies a new delay for the <emphasis>
BounceKeys</emphasis>
control, as described in <link linkend='the_bouncekeys_control'>See The
control, as described in <link linkend='the_bouncekeys_control'>The
BounceKeys Control</link>. If present, the <emphasis>
debounceDelay</emphasis>
must be non-zero or a <emphasis>
@ -2272,7 +2274,7 @@ SA_LockPtrBtn</emphasis>
mouseKeysDfltBtn</emphasis>
must specify a legal button for the core pointer device, or a <emphasis>
Value</emphasis>
error results. <link linkend='key_actions'>See Key
error results. <link linkend='key_actions'>Key
Actions</link> describes the <emphasis>
SA_PtrBtn</emphasis>
and <emphasis>
@ -2295,7 +2297,7 @@ mouseKeysCurve</emphasis>
fields change the rate at which the pointer moves when a key which generates a
<emphasis>
SA_MovePtr</emphasis>
action is held down. <link linkend='the_mousekeysaccel_control'>See The
action is held down. <link linkend='the_mousekeysaccel_control'>The
MouseKeysAccel Control</link> describes these <emphasis>
MouseKeysAccel</emphasis>
parameters in more detail. If defined, the <emphasis>
@ -2321,7 +2323,8 @@ Value</emphasis>
<para>
If applied, the <emphasis>
accessXOptions</emphasis>
field sets the AccessX options, which are described in detail in <link linkend='the_accessxkeys_control'>See The AccessXKeys Control</link>. If
field sets the AccessX options, which are described in detail in
<link linkend='the_accessxkeys_control'>The AccessXKeys Control</link>. If
either one of <emphasis>
XkbStickyKeysMask</emphasis>
and <emphasis>
@ -2355,7 +2358,7 @@ accessXTimeoutOptionsMask</emphasis>
and <emphasis>
accessXTimeoutOptionsValues</emphasis>
fields change the behavior of the AccessX Timeout control, as described in
<link linkend='the_accessxtimeout_control'>See The AccessXTimeout
<link linkend='the_accessxtimeout_control'>The AccessXTimeout
Control</link>. The <emphasis>
accessXTimeout</emphasis>
must be greater than zero, or a <emphasis>
@ -2383,7 +2386,7 @@ Match</emphasis>
If present, the <emphasis>
groupsWrap</emphasis>
field specifies the treatment of out-of-range keyboard groups, as described in
<link linkend='key_symbol_map'>See Key Symbol Map</link>. If the
<link linkend='key_symbol_map'>Key Symbol Map</link>. If the
<emphasis>
groupsWrap</emphasis>
field does not specify a legal treatment for out-of-range groups, a <emphasis>
@ -3323,7 +3326,7 @@ flags</emphasis>
last key type specified by this request is the last element in the list. If the
list of key types is shrunk, any existing key definitions that use key types
that eliminated are automatically assigned key types from the list of canonical
key types as described in <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>See
key types as described in <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>
Assigning Types To Groups of Symbols for a Key</link>. The list of key types
bound to a keyboard must always include the four canonical types and cannot
have more than <emphasis>
@ -3736,7 +3739,8 @@ XkbSetMapRecomputeActions</emphasis>
bit is set in <emphasis>
flags</emphasis>
, the actions associated with any keys for which symbol or modifier bindings
were changed by this request are recomputed as described in <link linkend='assigning_actions_to_keys'>See Assigning Actions To Keys</link>. Note
were changed by this request are recomputed as described in
<link linkend='assigning_actions_to_keys'>Assigning Actions To Keys</link>. Note
that actions are recomputed <emphasis>
after </emphasis>
any actions specified in this request are bound to keys, so the actions
@ -4082,7 +4086,7 @@ recomputeActions</emphasis>
True</emphasis>
, the server regenerates recalculates the actions bound to all keyboard keys by
applying the new symbol interpretations to the entire key symbol map, as
described in <link linkend='assigning_actions_to_keys'>See Assigning Actions To
described in <link linkend='assigning_actions_to_keys'>Assigning Actions To
Keys</link>.
</para>
@ -4239,7 +4243,7 @@ XkbIndicatorStateNotify</emphasis>
The <emphasis>
maps</emphasis>
return value reports the requested indicator maps. Indicator maps are
described in <link linkend='indicator_maps'>See Indicator Maps</link>
described in <link linkend='indicator_maps'>Indicator Maps</link>
</para>
@ -4713,7 +4717,7 @@ If <emphasis>
setMap </emphasis>
is <emphasis>
True</emphasis>
, XKB changes the map for the indicator (see <link linkend='indicator_maps'>See Indicator Maps</link>) to reflect the
, XKB changes the map for the indicator (see <link linkend='indicator_maps'>Indicator Maps</link>) to reflect the
values specified in <emphasis>
map</emphasis>
.
@ -5522,7 +5526,7 @@ name</emphasis>
is a valid atom other than <emphasis>
None</emphasis>
, the server returns the keyboard geometry description with that name in the
server database of keyboard components (see <link linkend='the_server_database_of_keyboard_components'>See The Server Database of Keyboard
server database of keyboard components (see <link linkend='the_server_database_of_keyboard_components'>The Server Database of Keyboard
Components</link>) if one exists. If <emphasis>
deviceSpec</emphasis>
does not specify a valid keyboard device, a <emphasis>
@ -5562,7 +5566,7 @@ found</emphasis>
True</emphasis>
, the remaining fields of the reply describe the requested keyboard geometry.
The interpretation of the components that make up a keyboard geometry is
described in detail in <link linkend='keyboard_geometry'>See Keyboard
described in detail in <link linkend='keyboard_geometry'>Keyboard
Geometry</link>
</para>
@ -5855,35 +5859,35 @@ per-client-flags are:
<entry><emphasis>
XkbPCF_DetectableAutorepeat</emphasis>
</entry>
<entry><link linkend='detectable_autorepeat'>See Detectable
<entry><link linkend='detectable_autorepeat'>Detectable
Autorepeat</link></entry>
</row>
<row rowsep='0'>
<entry><emphasis>
XkbPCF_GrabsUseXKBStateMask</emphasis>
</entry>
<entry><link linkend='setting_a_passive_grab_for_an_xkb_state'>See Setting a Passive Grab
<entry><link linkend='setting_a_passive_grab_for_an_xkb_state'>Setting a Passive Grab
for an XKB State</link></entry>
</row>
<row rowsep='0'>
<entry><emphasis>
XkbPCF_AutoResetControlsMask</emphasis>
</entry>
<entry><link linkend='automatic_reset_of_boolean_controls'>See Automatic Reset of
<entry><link linkend='automatic_reset_of_boolean_controls'>Automatic Reset of
Boolean Controls</link></entry>
</row>
<row rowsep='0'>
<entry><emphasis>
XkbPCF_LookupStateWhenGrabbed</emphasis>
</entry>
<entry><link linkend='effects_of_xkb_on_core_protocol_events'>See Effects of XKB on Core
<entry><link linkend='effects_of_xkb_on_core_protocol_events'>Effects of XKB on Core
Protocol Events</link></entry>
</row>
<row rowsep='0'>
<entry><emphasis>
XkbPCF_SendEventUsesXKBState</emphasis>
</entry>
<entry><link linkend='sending_events_to_clients'>See Sending Events to
<entry><link linkend='sending_events_to_clients'>Sending Events to
Clients</link></entry>
</row>
</tbody>
@ -6109,7 +6113,7 @@ components.
<para>
Each pattern uses the ISO Latin-1 encoding and should contain only parentheses,
the wildcard characters "?" and "*" or characters that are permitted in a
component class or member name (see <link linkend='component_names'>See Component Names</link>). Illegal
component class or member name (see <link linkend='component_names'>Component Names</link>). Illegal
characters in a pattern are simply ignored; no error results if a pattern
contains illegal characters.
</para>
@ -6153,14 +6157,14 @@ compatMaps</emphasis>
symbols</emphasis>
and <emphasis>
geometries</emphasis>
return the hints (see <link linkend='component_hints'>See Component
return the hints (see <link linkend='component_hints'>Component
Hints</link>) and names of any components from the server database that match
the corresponding pattern.
</para>
<para>
<link linkend='the_server_database_of_keyboard_components'>See The Server Database of Keyboard
<link linkend='the_server_database_of_keyboard_components'>The Server Database of Keyboard
Components</link> describes the X server database of keyboard components in
more detail.
</para>
@ -6300,7 +6304,7 @@ compatMapSpec</emphasis>
symbolsSpec</emphasis>
and <emphasis>
geometrySpec</emphasis>
component expressions (see <link linkend='partial_components_and_combining_multiple_components'>See
component expressions (see <link linkend='partial_components_and_combining_multiple_components'>
Partial Components and Combining Multiple Components</link>) specify the
database components to be used to assemble the keyboard description.
</para>
@ -6410,7 +6414,7 @@ If either field contains a GBN component that depends on some database
component for which the request does not supply an expression, XKB
automatically substitutes the special pattern "%" which copies the
corresponding component from the current keyboard description, as described in
<link linkend='partial_components_and_combining_multiple_components'>See Partial Components and Combining
<link linkend='partial_components_and_combining_multiple_components'>Partial Components and Combining
Multiple Components</link>.
</para>
@ -6434,7 +6438,8 @@ If all necessary components are both specified and found, the new keyboard
description is loaded. If the new keyboard description has a different geometry
or keycode range than the previous keyboard description, XKB sends <emphasis>
XkbNewKeyboardNotify</emphasis>
events to all interested clients. See <link linkend='replacing_the_keyboard_on_the_fly'>See Replacing the Keyboard
events to all interested clients. See
<link linkend='replacing_the_keyboard_on_the_fly'>Replacing the Keyboard
"On-the-Fly"</link> for more information about the effects of replacing the
keyboard description on the fly.
</para>
@ -6885,7 +6890,9 @@ deviceID</emphasis>
which values are being returned. The <emphasis>
supported</emphasis>
return value reports the set of optional XKB extension device features that
are supported by this implementation (see <link linkend='interactions_between_xkb_and_the_x_input_extension'>See Interactions Between XKB and the X Input
are supported by this implementation (see
<link linkend='interactions_between_xkb_and_the_x_input_extension'>
Interactions Between XKB and the X Input
Extension</link>) for the specified device, and the unsupported return value
reports any <emphasis>
unsupported</emphasis>
@ -7532,7 +7539,7 @@ Once a client receives a new keyboard notify event which reports a new keycode
range, the X server reports events from all keys in the new range to that
client. Clients that do not request or receive new keyboard notify events
receive events only from keys that fall in the last range for legal keys
reported to that client. See <link linkend='replacing_the_keyboard_on_the_fly'>See
reported to that client. See <link linkend='replacing_the_keyboard_on_the_fly'>
Replacing the Keyboard "On-the-Fly"</link> for a more detailed explanation.
</para>
@ -7898,9 +7905,9 @@ requestMajor, requestMinor: CARD8</entry>
</informaltable>
<para>
An <emphasis>
XkbStateNotify</emphasis>
event reports that some component of the XKB state (see <link linkend='keyboard_state'>See Keyboard State</link>) has changed.
An <emphasis>XkbStateNotify</emphasis>
event reports that some component of the XKB state (see
<link linkend='keyboard_state'>Keyboard State</link>) has changed.
State notify events are usually caused by key or pointer activity, but they can
also result from explicit state changes requested by the <emphasis>
XkbLatchLockState</emphasis>
@ -7914,7 +7921,8 @@ deviceID</emphasis>
field reports the keyboard on which some state component changed. The
<emphasis>
changed</emphasis>
field reports the XKB state components (see <link linkend='keyboard_state'>See Keyboard State</link>) that have changed
field reports the XKB state components (see
<link linkend='keyboard_state'>Keyboard State</link>) that have changed
and contain any combination of:
</para>
@ -8163,8 +8171,10 @@ requestMinor: CARD8</entry>
An <emphasis>
XkbControlsNotify</emphasis>
event reports a change in one or more of the global keyboard controls (see
<link linkend='global_keyboard_controls'>See Global Keyboard Controls</link>)
or in the internal modifiers or ignore locks masks (see <link linkend='server_internal_modifiers_and_ignore_locks_behavior'>See Server Internal Modifiers and Ignore
<link linkend='global_keyboard_controls'>Global Keyboard Controls</link>)
or in the internal modifiers or ignore locks masks (see
<link linkend='server_internal_modifiers_and_ignore_locks_behavior'>
Server Internal Modifiers and Ignore
Locks Behavior</link>). Controls notify events are usually caused by and
<emphasis>
XkbSetControls</emphasis>
@ -9167,8 +9177,9 @@ detail</emphasis>
slowKeysDelay</emphasis>
and <emphasis>
debounceDelay</emphasis>
fields always reports the current slow keys acceptance delay (see <link linkend='the_slowkeys_control'>See The SlowKeys Control</link>) and
debounce delay (see <link linkend='the_bouncekeys_control'>See The BounceKeys
fields always reports the current slow keys acceptance delay (see
<link linkend='the_slowkeys_control'>The SlowKeys Control</link>) and
debounce delay (see <link linkend='the_bouncekeys_control'>The BounceKeys
Control</link>) for the specified keyboard.
</para>
@ -9333,7 +9344,7 @@ extension device feature that is not supported by the XKB implementation in the
server for the specified device. The <emphasis>
unsupported</emphasis>
mask reports the requested features that are not available on the specified
device. See <link linkend='interactions_between_xkb_and_the_x_input_extension'>See Interactions Between
device. See <link linkend='interactions_between_xkb_and_the_x_input_extension'>Interactions Between
XKB and the X Input Extension</link> for more information about possible XKB
interactions with the X Input Extension.
</para>