fdo-mirrors/xorg-libx11
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/xorg/lib/libx11.git synced 2026-05-07 22:38:15 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

specs/XKB: Turn section references into xref links

Browse source 
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This commit is contained in:
Alan Coopersmith 2014-07-06 21:29:59 -07:00
parent 53e931d799
commit 135fa07b74
19 changed files with 202 additions and 199 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
specs/XKB/ch01.xml
View file

@ -219,7 +219,7 @@ and incremental reconfiguration are both supported.
<para>
The graphic characters or control functions that may be accessed by one key are
logically arranged in groups and levels. See section 14.1for a complete
logically arranged in groups and levels. See <link linkend="Notation_and_Terminology">section 14.1</link> for a complete
description of groups and levels.
</para>
@ -307,7 +307,7 @@ configuration.
<para>
The Xkb extension adds a single protocol error,
<emphasis>BadKeyboard</emphasis>,
to the core protocol error set. See section 2.6 for a discussion of the <!-- xref -->
to the core protocol error set. See <link linkend="Protocol_Errors">section 2.6</link> for a discussion of the <!-- xref -->
<emphasis>BadKeyboard</emphasis>
protocol error.
</para>

4
specs/XKB/ch02.xml
View file

@ -62,7 +62,7 @@ The name of the Xkb extension is given in
<para>
Most extensions to the X protocol are initialized by calling
<function>XInitExtension</function>
and passing the extension name. However, as explained in section 2.4, Xkb
and passing the extension name. However, as explained in <link linkend="Initializing_the_Keyboard_Extension">section 2.4</link>, Xkb
requires a more complex initialization sequence, and a client program should
not call
<function>XInitExtension</function>
@ -308,7 +308,7 @@ and the major and minor version numbers of the extension in
The major opcode is reported in the
<emphasis>req_major</emphasis>
fields of some Xkb events. For a discussion of the base event code, see
section 4.1. <!-- xref -->
<link linkend="Xkb_Event_Types">section 4.1</link>. <!-- xref -->
</para>
<para>

6
specs/XKB/ch04.xml
View file

@ -17,7 +17,7 @@ Xkb keyboard status events are reported to all interested clients, regardless
of which window currently has the keyboard focus and regardless of the grab
state of the keyboard.<footnote><para>The one exception to this rule is the
XkbExtensionDeviceNotify event report that is sent when a client attempts to
use an unsupported feature of an X Input Extension device (see section 21.4).
use an unsupported feature of an X Input Extension device (see <link linkend="Setting_Xkb_Features_for_Non_KeyClass_Input_Extension_Devices">section 21.4</link>).
</para></footnote> <!-- xref -->
</para>
@ -651,7 +651,7 @@ if you have requested them via a call to
or
<function>XkbSelectEventDetails</function>.
Specify the event types in which you are interested in a mask, as described
in section 4.3.
in <link linkend="Selecting_Xkb_Events">section 4.3</link>.
</para>
@ -788,7 +788,7 @@ type and for the core protocol
<emphasis>type</emphasis>
field to determine if the event is an Xkb event (
<emphasis>type</emphasis>
equals the Xkb base event code; see section 2.4). If the event is an Xkb
equals the Xkb base event code; see <link linkend="Initializing_the_Keyboard_Extension">section 2.4</link>). If the event is an Xkb
event, you may then use the
<emphasis>any.xkb_type</emphasis>
field to determine the type of Xkb event and thereafter access the

6
specs/XKB/ch05.xml
View file

@ -166,7 +166,7 @@ The global locked or effective group changes. In this case, the changed group is
<emphasis>groups_wrap</emphasis>
field of the
<emphasis>XkbControlsRec</emphasis>
structure for the keyboard (see section 10.7.1). <!-- xref -->
structure for the keyboard (see <link linkend="The_GroupsWrap_Control">section 10.7.1</link>). <!-- xref -->
</para></listitem>
<listitem><para>
@ -257,7 +257,7 @@ The
<para>
If the server’s
<emphasis>IgnoreGroupLock</emphasis>
control (see section 10.7.3) is not set, the grab group is the same as the effective group. Otherwise, the grab group is computed from the base group and latched group, ignoring the locked group.
control (see <link linkend="The_IgnoreGroupLock_Control">section 10.7.3</link>) is not set, the grab group is the same as the effective group. Otherwise, the grab group is computed from the base group and latched group, ignoring the locked group.
</para>
@ -867,7 +867,7 @@ To track changes in the keyboard state for a particular device, select to receiv
<function>XkbSelectEvents</function>
or
<function>XkbSelectEventDetails</function>
(see section 4.3). <!-- xref -->
(see <link linkend="Selecting_Xkb_Events">section 4.3</link>). <!-- xref -->
</para>

4
specs/XKB/ch06.xml
View file

@ -275,7 +275,7 @@ The valid masks for
<para>
To free the returned keyboard description, use
<function>XkbFreeKeyboard</function>
(see section 6.4). <!-- xref -->
(see <link linkend="Allocating_and_Freeing_a_Keyboard_Description">section 6.4</link>). <!-- xref -->
</para>
@ -285,7 +285,7 @@ To free the returned keyboard description, use
<para>
The server can generate events whenever its copy of the keyboard description
for a device changes. Refer to section 14.4 for detailed information on <!-- xref -->
for a device changes. Refer to <link linkend="Tracking_Changes_to_Map_Components">section 14.4</link> for detailed information on <!-- xref -->
tracking changes to the keyboard description.
</para>

18
specs/XKB/ch07.xml
View file

@ -70,7 +70,7 @@ Virtual modifiers are named by converting their string name to an X
<emphasis>names.vmods</emphasis>
array in an
<emphasis>XkbDescRec</emphasis>
structure (see section 6.1). The position of a name Atom in the
structure (see <link linkend="The_XkbDescRec_Structure">section 6.1</link>). The position of a name Atom in the
<emphasis>names.vmods</emphasis>
array defines the bit position used to represent the virtual modifier and also
the index used when accessing virtual modifier information in arrays: the name
@ -110,8 +110,10 @@ bind those modifiers to any particular key or to each other. Modifier
definitions are included in a number of structures in the keyboard description
to define the collection of modifiers that affect or are affected by some other
entity. A modifier definition is relevant only in the context of some other
entity such as an indicator map, a control, or a key type. (See sections 8.2.2,
10.8, and 15.2.) <!-- xref -->
entity such as an indicator map, a control, or a key type. (See
<link linkend="XkbIndicatorMapRec">section 8.2.2</link>,
<link linkend="The_XkbControlsRec_Structure">section 10.8</link>, and
<link linkend="Key_Types">section 15.2</link>.)
</para>
<para><programlisting>
@ -197,7 +199,7 @@ The
<emphasis>vmods</emphasis>
members of the server map are the "master" virtual modifier definitions. Xkb
automatically propagates any changes to these fields to all other fields that
use virtual modifier mappings (see section 16.4).
use virtual modifier mappings (see <link linkend="Virtual_Modifier_Mapping">section 16.4</link>).
</para>
@ -219,7 +221,7 @@ For example, if
<para>
The virtual modifier mapping is normally updated whenever actions are
automatically applied to symbols (see section 16.4 for details), and few
automatically applied to symbols (see <link linkend="Virtual_Modifier_Mapping">section 16.4</link> for details), and few
applications should need to change the virtual modifier mapping explicitly.
</para>
@ -227,14 +229,14 @@ applications should need to change the virtual modifier mapping explicitly.
<para>
Use
<function>XkbGetMap</function>
(see section 14.2) to get the virtual modifiers from the server or use <!-- xref -->
(see <link linkend="Getting_Map_Components_from_the_Server">section 14.2</link>) to get the virtual modifiers from the server or use <!-- xref -->
<function>XkbGetVirtualMods</function>
(see section 16.4.1) to update a local copy of the virtual modifiers bindings <!-- xref -->
(see <link linkend="Obtaining_Virtual_Modifier_Bindings_from_the_Server">section 16.4.1</link>) to update a local copy of the virtual modifiers bindings <!-- xref -->
from the server. To set the binding of a virtual modifier to a real modifier,
use
<function>XkbSetMap</function>
(see
section 14.3<emphasis> <!-- xref -->
<link linkend="Changing_Map_Components_in_the_Server">section 14.3</link><emphasis> <!-- xref -->
)</emphasis>.
</para>

19
specs/XKB/ch08.xml
View file

@ -53,7 +53,8 @@ specific indicators, use
<function>XkbSetNames</function>
as discussed in <xref linkend="Symbolic_Names" />. Then set the map using
<function>XkbSetMap</function>
(see section 14.3) or
(see <link linkend="Changing_Map_Components_in_the_Server">section 14.3</link>)
or
<function>XkbSetNamedIndicator</function>
(below). To retrieve indicator names, use
<function>XkbGetNames</function>
@ -187,7 +188,7 @@ using the functions
<para>
For more information on the effects of explicit changes to indicators and the
relationship to the indicator map, see section 8.4.1. <!-- xref -->
relationship to the indicator map, see <link linkend="Effects_of_Explicit_Changes_on_Indicators">section 8.4.1</link>. <!-- xref -->
</para>
<sect3 id='XkbIndicatorMapRec_flags_field'>
@ -530,7 +531,7 @@ field specifies what modifiers an indicator watches. The
<emphasis>mods</emphasis>
field is an Xkb modifier definition,
<emphasis>XkbModsRec</emphasis>,
as described in section 7.2, which can specify both real and virtual <!-- xref -->
as described in <link linkend="Modifier_Definitions">section 7.2</link>, which can specify both real and virtual <!-- xref -->
modifiers. The
<emphasis>mods</emphasis>
field takes effect even if some or all of the virtual indicators specified in
@ -1012,7 +1013,7 @@ and
<para>
To free the indicator maps, use
<function>XkbFreeIndicatorMaps</function>
(see section 8.6).
(see <link linkend="Allocating_and_Freeing_Indicator_Maps">section 8.6</link>).
</para>
@ -1583,11 +1584,11 @@ in <emphasis>map</emphasis>.
<errorname>BadImplementation</errorname>
errors. In addition, it can also generate
<emphasis>XkbIndicatorStateNotify</emphasis>
(see section 8.5), <emphasis> <!-- xref -->
(see <link linkend="Tracking_Changes_to_Indicator_State_or_Map">section 8.5</link>), <emphasis> <!-- xref -->
XkbIndicatorMapNotify</emphasis>,
and
<emphasis>XkbNamesNotify</emphasis>
events (see section 18.5). <!-- xref -->
events (see <link linkend="Tracking_Name_Changes">section 18.5</link>). <!-- xref -->
</para>
@ -1716,7 +1717,7 @@ s can generate
<emphasis>XkbIndicatorStateNotify</emphasis>
and
<emphasis>XkbIndicatorMapNotify</emphasis>
events (see section 8.5). <!-- xref -->
events (see <link linkend="Tracking_Changes_to_Indicator_State_or_Map">section 8.5</link>). <!-- xref -->
</para>
@ -1740,7 +1741,7 @@ To receive
<emphasis>XkbIndicatorStateNotify</emphasis>
events, use
<function>XkbSelectEvents</function>
(see section 4.3) with both the <emphasis> <!-- xref -->
(see <link linkend="Selecting_Xkb_Events">section 4.3</link>) with both the <emphasis> <!-- xref -->
bits_to_change </emphasis>
and
<emphasis>values_for_bits</emphasis>
@ -1990,7 +1991,7 @@ If the
<emphasis>indicators</emphasis>
field, use
<emphasis>XkbFreeIndicators</emphasis>
(see section 8.6). <!-- xref -->
(see <link linkend="Allocating_and_Freeing_Indicator_Maps">section 8.6</link>). <!-- xref -->
</para>

18
specs/XKB/ch09.xml
View file

@ -16,7 +16,7 @@ opposed to any other audible sound generated elsewhere in the system.
<para>
You can ask to receive
<emphasis>XkbBellNotify</emphasis>
events (see section 9.4) when any client rings any one of the following: <!-- xref -->
events (see <link linkend="Detecting_Bells">section 9.4</link>) when any client rings any one of the following: <!-- xref -->
</para>
<itemizedlist>
@ -75,7 +75,7 @@ spite of the setting of the
<function>XkbForceDeviceBell</function>
or
<function>XkbForceBell</function>
(see section 9.3.3). In this case the server does not generate a bell event. <!-- xref -->
(see <link linkend="Forcing_a_Server_Generated_Bell">section 9.3.3</link>). In this case the server does not generate a bell event. <!-- xref -->
</para>
@ -85,7 +85,7 @@ or repeating, Xkb can provide feedback for the controls by using special beep
codes. The
<emphasis>AccessXFeedback</emphasis>
control is used to configure the specific types of operations that generate
feedback. See section 10.6.3 for a discussion on <emphasis> <!-- xref -->
feedback. See <link linkend="The_AccessXFeedback_Control">section 10.6.3</link> for a discussion on <emphasis> <!-- xref -->
AccessXFeedback</emphasis>
control.
</para>
@ -109,7 +109,7 @@ any sounds. Any sounds or other effects (such as visual bells on the screen)
must be generated by a client application upon receipt of the bell event
containing the name. There is no default name for the default keyboard bell.
The server does generate some predefined bells for the AccessX controls (see
section 10.6.3). These named bells are shown in Table 9.1; the name is included
<link linkend="The_AccessXFeedback_Control">section 10.6.3</link>). These named bells are shown in Table 9.1; the name is included
in any bell event sent to clients that have requested to receive
<emphasis>XkbBellNotify</emphasis>
events.
@ -202,7 +202,7 @@ bell. This is useful if you need to use an audio server instead of the system
beep. For example, when an audio client starts, it could disable the audible
bell (the system bell) and then listen for
<emphasis>XkbBellNotify</emphasis>
events (see section 9.4). When it receives a <emphasis> <!-- xref -->
events (see <link linkend="Detecting_Bells">section 9.4</link>). When it receives a <emphasis> <!-- xref -->
XkbBellNotify</emphasis>
event, the audio client could then send a request to an audio server to play a
sound.
@ -214,7 +214,7 @@ You can control the audible bells feature by passing the
<emphasis>XkbAudibleBellMask</emphasis>
to
<function>XkbChangeEnabledControls</function>
(see section 10.1.1). If you set <emphasis> <!-- xref -->
(see <link linkend="The_EnabledControls_Control">section 10.1.1</link>). If you set <emphasis> <!-- xref -->
XkbAudibleBellMask</emphasis>
on, the server rings the system bell when a bell event occurs. This is the
default. If you set
@ -224,12 +224,12 @@ you call
<function>XkbForceDeviceBell</function>
or
<function>XkbForceBell</function>
(see section 9.3.3). <!-- xref -->
(see <link linkend="Forcing_a_Server_Generated_Bell">section 9.3.3</link>). <!-- xref -->
</para>
<para>
Audible bells are also part of the per-client auto-reset controls. For more
information on auto-reset controls, see section 10.1.2. <!-- xref -->
information on auto-reset controls, see <link linkend="The_AutoReset_Control">section 10.1.2</link>. <!-- xref -->
</para>
</sect1>
@ -1072,7 +1072,7 @@ and
<emphasis>values_for_bits</emphasis>
parameters to
<function>XkbSelectEvents</function>
(see section 4.3). <!-- xref -->
(see <link linkend="Selecting_Xkb_Events">section 4.3</link>). <!-- xref -->
</para>
<para>

154
specs/XKB/ch10.xml
View file

@ -34,7 +34,7 @@ describing how the control should work, and a state describing whether the
behavior as a whole is enabled or disabled. The attributes and state for most
of these controls are held in the
<emphasis>XkbControlsRec</emphasis>
structure (see section 10.8).
structure (see <link linkend="The_XkbControlsRec_Structure">section 10.8</link>).
</para>
@ -45,7 +45,7 @@ as a whole. To treat them as a group, modify an
structure to describe all of the changes to be made, and then pass that
structure and appropriate flags to an Xkb library function, or use a
<emphasis>XkbControlsChangesRec</emphasis>
(see section 10.10.1) to reduce network traffic. When using a convenience
(see <link linkend="The_XkbControlsChangesRec_Structure">section 10.10.1</link>) to reduce network traffic. When using a convenience
function to manipulate one control individually, you do not use an
<emphasis>XkbControlsRec</emphasis>
structure directly.
@ -221,7 +221,7 @@ control is enabled, and when turned off, disabled. It corresponds to the
<emphasis>enabled_ctrls</emphasis>
field of an
<emphasis>XkbControlsRec</emphasis>
structure (see section 10.8). The bits describing which controls are turned on
structure (see <link linkend="The_XkbControlsRec_Structure">section 10.8</link>). The bits describing which controls are turned on
or off are defined in Table 10.7. <!-- xref -->
</para>
@ -614,10 +614,10 @@ and disable it using either the
<emphasis>EnabledControls</emphasis>
control or the
<emphasis>AutoReset</emphasis>
control discussed in section 10.1.1. When enabled, protocol requests to <!-- xref -->
control discussed in <link linkend="The_EnabledControls_Control">section 10.1.1</link>. When enabled, protocol requests to <!-- xref -->
generate a sound result in the X server actually producing a real sound; when
disabled, requests to the server to generate a sound are ignored unless the
sound is forced. See section 9.2. <!-- xref -->
sound is forced. See <link linkend="Audible_Bells">section 9.2</link>. <!-- xref -->
</para>
@ -661,7 +661,7 @@ control. The
<emphasis>per_key_repeat</emphasis>
field of an
<emphasis>XkbControlsRec</emphasis>
structure, discussed in section 10.8. <!-- xref -->
structure, discussed in <link linkend="The_XkbControlsRec_Structure">section 10.8</link>. <!-- xref -->
</para>
@ -691,7 +691,7 @@ generated repeat event. The second,
<emphasis>interval</emphasis>,
is the delay between all subsequent generated repeat events. As with all
boolean controls, configuring the attributes that determine how the control
operates does not automatically enable the control as a whole; see section 10.1.
operates does not automatically enable the control as a whole; see <link linkend="Controls_that_Enable_and_Disable_Other_Controls">section 10.1</link>.
</para>
@ -1146,7 +1146,7 @@ the
<emphasis>EnabledControls</emphasis>
control or the
<emphasis>AutoReset</emphasis>
control discussed in section 10.1.1. <!-- xref -->
control discussed in <link linkend="The_EnabledControls_Control">section 10.1.1</link>. <!-- xref -->
</para>
@ -1156,7 +1156,7 @@ should generate when that overlay is enabled, assign it either the
<emphasis>XkbKB_Overlay1</emphasis>
or
<emphasis>XkbKB_Overlay2</emphasis>
key behaviors, as described in section 16.2. <!-- xref -->
key behaviors, as described in <link linkend="Key_Behavior">section 16.2</link>. <!-- xref -->
</para>
@ -1179,7 +1179,7 @@ and disable them using either the
<emphasis>EnabledControls</emphasis>
control or the
<emphasis>AutoReset</emphasis>
control discussed in section 10.1.1. The individual keys that simulate <!-- xref -->
control discussed in <link linkend="The_EnabledControls_Control">section 10.1.1</link>. The individual keys that simulate <!-- xref -->
different aspects of the pointer device are determined by the keyboard mapping,
discussed in <xref linkend="Xkb_Server_Keyboard_Mapping" />. <!-- xref -->
</para>
@ -1215,7 +1215,7 @@ or setting the attribute; instead use
<function>XkbGetControls</function>
and
<function>XkbSetControls</function>
(see sections 10.9 and 10.10). <!-- xref -->
(see <link linkend="Querying_Controls">section 10.9</link> and <link linkend="Changing_Controls">section 10.10</link>). <!-- xref -->
</para>
<note><para>
@ -1242,7 +1242,7 @@ mouse-pointer key yields one mouse event. When
<emphasis>XkbSA_MovePtr</emphasis>
action and the following fields in the
<emphasis>XkbControlsRec</emphasis>
structure (see section 10.8). <!-- xref -->
structure (see <link linkend="The_XkbControlsRec_Structure">section 10.8</link>). <!-- xref -->
</para>
<table frame='topbot'>
@ -1291,7 +1291,7 @@ There are no convenience functions to query or change the attributes of the
<function>XkbGetControls</function>
and
<function>XkbSetControls</function>
(see sections 10.9 and 10.10). <!-- xref -->
(see <link linkend="Querying_Controls">section 10.9</link> and <link linkend="Changing_Controls">section 10.10</link>). <!-- xref -->
</para>
@ -1300,7 +1300,7 @@ The effects of the attributes of the
<emphasis>MouseKeysAccel</emphasis>
control depend on whether the
<emphasis>XkbSA_MovePtr</emphasis>
action (see section 16.1) specifies relative or absolute pointer motion. <!-- xref -->
action (see <link linkend="Key_Actions">section 16.1</link>) specifies relative or absolute pointer motion. <!-- xref -->
</para>
<sect3 id='Absolute_Pointer_Motion'>
@ -1498,7 +1498,7 @@ Enabling or disabling the keyboard controls through a graphical user interface
may be impossible for people who need to use the controls. For example, a user
who needs
<emphasis>SlowKeys</emphasis>
(see section 10.6.6) may not even be able to start the graphical application, <!-- xref -->
(see <link linkend="The_SlowKeys_Control">section 10.6.6</link>) may not even be able to start the graphical application, <!-- xref -->
let alone use it, if
<emphasis>SlowKeys</emphasis>
is not enabled. To allow easier access to some of the controls, the
@ -1551,9 +1551,9 @@ When the
<para>
Some of these key sequences optionally generate audible feedback of the change
in state, as described in section 10.6.3, or <!-- xref -->
in state, as described in <link linkend="The_AccessXFeedback_Control">section 10.6.3</link>, or <!-- xref -->
<emphasis>XkbControlsNotify</emphasis>
events, described in section 10.11. <!-- xref -->
events, described in <link linkend="Tracking_Changes_to_Keyboard_Controls">section 10.11</link>. <!-- xref -->
</para>
</sect2>
@ -1585,7 +1585,7 @@ When a timeout as specified by
<emphasis>XkbControlsNotify</emphasis>
event. For more information on
<emphasis>XkbControlsNotify</emphasis>
events, refer to section 10.11. <!-- xref -->
events, refer to <link linkend="Tracking_Changes_to_Keyboard_Controls">section 10.11</link>. <!-- xref -->
</para>
@ -1706,7 +1706,7 @@ The parameters
<emphasis>ax_options</emphasis>,
which is a field in the
<emphasis>XkbControlsRec</emphasis>
structure (see section 10.8). <!-- xref -->
structure (see <link linkend="The_XkbControlsRec_Structure">section 10.8</link>). <!-- xref -->
<function>XkbGetAccessXTimeout</function>
returns
<symbol>True</symbol>
@ -1826,8 +1826,8 @@ are modified.
specifies what controls are to be enabled or disabled, and
<emphasis>ctrls_values</emphasis>
specifies whether those controls are to be enabled or disabled. The bit values
correspond to those for enabling and disabling boolean controls (see section
10.1.1). The
correspond to those for enabling and disabling boolean controls
(see <link linkend="The_EnabledControls_Control">section 10.1.1</link>). The
<emphasis>opts_mask</emphasis>
field specifies which attributes of the
<emphasis>AccessXKeys</emphasis>
@ -1840,7 +1840,7 @@ for the
<emphasis>ax_options</emphasis>
field of an
<emphasis>XkbDescRec</emphasis>
(see section 10.8). <!-- xref -->
(see <link linkend="The_XkbControlsRec_Structure">section 10.8</link>). <!-- xref -->
</para>
@ -1875,14 +1875,14 @@ codes. Use the
There is no convenience function for modifying the
<emphasis>AccessXFeedback</emphasis>
control, although the feedback as a whole can be enabled or disabled just as
other boolean controls are (see section 10.1). Individual beep codes are turned
other boolean controls are (see <link linkend="Controls_that_Enable_and_Disable_Other_Controls">section 10.1</link>). Individual beep codes are turned
on or off by modifying the following bits in the
<emphasis>ax_options</emphasis>
field of an
<emphasis>XkbControlsRec</emphasis>
structure and using
<function>XkbSetControls</function>
(see section 10.10): <!-- xref -->
(see <link linkend="Changing_Controls">section 10.10</link>): <!-- xref -->
</para>
<table frame='topbot'>
@ -1995,7 +1995,7 @@ pitch. In these cases, use the
<para>
When any of the above feedbacks occur, Xkb may generate a
<emphasis>XkbBellNotify</emphasis>
event (see section 9.4). <!-- xref -->
event (see <link linkend="Detecting_Bells">section 9.4</link>). <!-- xref -->
</para>
@ -2108,7 +2108,7 @@ To receive
<emphasis>XkbAccessXNotify</emphasis>
events under all possible conditions, use
<function>XkbSelectEvents</function>
(see section 4.3) and pass <emphasis> <!-- xref -->
(see <link linkend="Selecting_Xkb_Events">section 4.3</link>) and pass <emphasis> <!-- xref -->
XkbAccesXNotifyMask</emphasis>
in both
<emphasis>bits_to_change</emphasis>
@ -2208,13 +2208,13 @@ locking, or unlocking of modifiers using
<emphasis>StickyKeys</emphasis>
generates
<emphasis>XkbStateNotify</emphasis>
events as described in section 5.4. Repeating keys generate normal
events as described in <link linkend="Tracking_Keyboard_State">section 5.4</link>. Repeating keys generate normal
<symbol>KeyPress</symbol>
and
<symbol>KeyRelease</symbol>
events, though the auto-repeat can be detected using
<emphasis>DetectableAutorepeat</emphasis>
(see section 10.3.3). Finally, <emphasis> <!-- xref -->
(see <link linkend="The_DetectableAutorepeat_Control">section 10.3.3</link>). Finally, <emphasis> <!-- xref -->
MouseKeys</emphasis>
generates pointer events identical to those of the core pointer device.
</para>
@ -2248,7 +2248,7 @@ When the
acceptance or rejection, and release of any key to interested clients by
sending an appropriate
<emphasis>AccessXNotify</emphasis>
event (see section 10.6.4). <!-- xref -->
event (see <link linkend="AccessXNotify_Events">section 10.6.4</link>). <!-- xref -->
</para>
<para>
@ -2428,7 +2428,7 @@ When the
control is active, the server reports acceptance or rejection of any key to
interested clients by sending an appropriate
<emphasis>AccessXNotify</emphasis>
event (see section 10.6.4). <!-- xref -->
event (see <link linkend="AccessXNotify_Events">section 10.6.4</link>). <!-- xref -->
</para>
@ -2705,7 +2705,7 @@ The
<emphasis>ax_options</emphasis>
of an
<emphasis>XkbControlsRec</emphasis>
structure (see section 10.8). The first option,
structure (see <link linkend="The_XkbControlsRec_Structure">section 10.8</link>). The first option,
<emphasis>TwoKeys</emphasis>,
specifies whether
<emphasis>StickyKeys</emphasis>
@ -3013,10 +3013,10 @@ There are no convenience functions for manipulating the
<function>XkbSetControls</function>
and
<function>XkbGetControls</function>
(see section 10.9 and section 10.10) to query and change this control. <!-- xref -->
(see <link linkend="Querying_Controls">section 10.9</link> and <link linkend="Changing_Controls">section 10.10</link>) to query and change this control. <!-- xref -->
</para>
<note><para>See also section 15.3.2 or a discussion of the related field, <!-- xref -->
<note><para>See also <link linkend="Per_Key_Group_Information">section 15.3.2</link> or a discussion of the related field, <!-- xref -->
<emphasis>group_info</emphasis>,
which also normalizes a group under certain circumstances.</para></note>
@ -3055,7 +3055,7 @@ Manipulate the
<function>XkbSetControls</function>
and
<function>XkbGetControls</function>
(see sections 10.9 and 10.10) to query and change this control. Alternatively, <!-- xref -->
(see <link linkend="Querying_Controls">section 10.9</link> and <link linkend="Changing_Controls">section 10.10</link>) to query and change this control. Alternatively, <!-- xref -->
use
<function>XkbSetIgnoreLockMods</function>.
</para>
@ -3200,7 +3200,7 @@ be added and removed from the server’s
are removed from the server’s
<emphasis>IgnoreLockMods</emphasis>
control.
See section 7.1 for a discussion of virtual modifier masks to use in <emphasis> <!-- xref -->
See <link linkend="Virtual_Modifier_Names_and_Masks">section 7.1</link> for a discussion of virtual modifier masks to use in <emphasis> <!-- xref -->
affect_virtual</emphasis>
and
<emphasis>virtual_values</emphasis>.
@ -3228,7 +3228,7 @@ passive grabs.
Because
<emphasis>IgnoreGroupLock</emphasis>
is a boolean control with no attributes, use the general boolean controls
functions (see section 10.1) to change its state. <!-- xref -->
functions (see <link linkend="Controls_that_Enable_and_Disable_Other_Controls">section 10.1</link>) to change its state. <!-- xref -->
</para>
@ -3265,7 +3265,8 @@ Manipulate the
<function>XkbSetControls</function>
and
<function>XkbGetControls</function>
(see sections10.9 and 10.10). Alternatively, use
(see <link linkend="Querying_Controls">section 10.9</link>
and <link linkend="Changing_Controls">section 10.10</link>). Alternatively, use
<function>XkbSetServerInternalMods</function>.
</para>
@ -3398,7 +3399,7 @@ selected by both
but not by
<emphasis>virtual_values</emphasis>
are removed from the server’s internal modifiers control.
See section 7.1 for a discussion of virtual modifier masks to use in <emphasis> <!-- xref -->
See <link linkend="Virtual_Modifier_Names_and_Masks">section 7.1</link> for a discussion of virtual modifier masks to use in <emphasis> <!-- xref -->
affect_virtual</emphasis>
and
<emphasis>virtual_values</emphasis>.
@ -3510,14 +3511,14 @@ is described in more detail.
<entry>XkbAccessXFeedbackMask</entry>
<entry>ax_options: XkbAX_*FBMask</entry>
<entry>XkbAccessXFeedback&#xAD;Mask</entry>
<entry>10.6.3</entry> <!-- xref -->
<entry><link linkend="The_AccessXFeedback_Control">10.6.3</link></entry>
</row>
<row>
<entry>AccessXKeys</entry>
<entry></entry>
<entry></entry>
<entry>XkbAccessXKeys&#xAD;Mask</entry>
<entry>10.6.1</entry> <!-- xref -->
<entry><link linkend="The_AccessXKeys_Control">10.6.1</link></entry>
</row>
<row>
<entry>AccessXTimeout</entry>
@ -3530,77 +3531,77 @@ is described in more detail.
<para>axt_ctrls_values</para>
</entry>
<entry>XkbAccessXTimeout&#xAD;Mask</entry>
<entry>10.6.2</entry>
<entry><link linkend="The_AccessXTimeout_Control">10.6.2</link></entry>
</row>
<row>
<entry>AudibleBell</entry>
<entry></entry>
<entry></entry>
<entry>XkbAudibleBellMask</entry>
<entry>9.2</entry>
<entry><link linkend="Audible_Bells">9.2</link></entry>
</row>
<row>
<entry>AutoReset</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry>10.1.2</entry>
<entry><link linkend="The_AutoReset_Control">10.1.2</link></entry>
</row>
<row>
<entry>BounceKeys</entry>
<entry>XkbBounceKeysMask</entry>
<entry>debounce_delay</entry>
<entry>XkbBounceKeysMask</entry>
<entry>10.6.7</entry>
<entry><link linkend="The_BounceKeys_Control">10.6.7</link></entry>
</row>
<row>
<entry>Detectable-Autorepeat</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry>10.3.3</entry>
<entry><link linkend="The_DetectableAutorepeat_Control">10.3.3</link></entry>
</row>
<row>
<entry>EnabledControls</entry>
<entry>XkbControlsEnabledMask</entry>
<entry>enabled_ctrls</entry>
<entry><emphasis>Non-Boolean Control</emphasis></entry>
<entry>10.1.1</entry>
<entry><link linkend="The_EnabledControls_Control">10.1.1</link></entry>
</row>
<row>
<entry>GroupsWrap</entry>
<entry>XkbGroupsWrapMask</entry>
<entry>groups_wrap</entry>
<entry><emphasis>Non-Boolean Control</emphasis></entry>
<entry>10.7.1</entry>
<entry><link linkend="The_GroupsWrap_Control">10.7.1</link></entry>
</row>
<row>
<entry>IgnoreGroupLock</entry>
<entry></entry>
<entry></entry>
<entry>XkbIgnoreGroupLock&#xAD;Mask</entry>
<entry>10.7.3</entry>
<entry><link linkend="The_IgnoreGroupLock_Control">10.7.3</link></entry>
</row>
<row>
<entry>IgnoreLockMods</entry>
<entry>XkbIgnoreLockModsMask</entry>
<entry>ignore_lock</entry>
<entry><emphasis>Non-Boolean Control</emphasis></entry>
<entry>5.1</entry>
<entry><link linkend="Keyboard_State_Description">5.1</link></entry>
</row>
<row>
<entry>InternalMods</entry>
<entry>XkbInternalModsMask</entry>
<entry>internal</entry>
<entry><emphasis>Non-Boolean Control</emphasis></entry>
<entry>5.1</entry>
<entry><link linkend="Keyboard_State_Description">5.1</link></entry>
</row>
<row>
<entry>MouseKeys</entry>
<entry>XkbMouseKeysMask</entry>
<entry>mk_dflt_btn</entry>
<entry>XkbMouseKeysMask</entry>
<entry>10.5.1</entry>
<entry><link linkend="The_MouseKeys_Control">10.5.1</link></entry>
</row>
<row>
<entry>MouseKeysAccel</entry>
@ -3613,28 +3614,28 @@ is described in more detail.
<para>mk_curve</para>
</entry>
<entry>XkbMouseKeysAccel&#xAD;Mask</entry>
<entry>10.5.2</entry>
<entry><link linkend="The_MouseKeysAccel_Control">10.5.2</link></entry>
</row>
<row>
<entry>Overlay1</entry>
<entry></entry>
<entry></entry>
<entry>XkbOverlay1Mask</entry>
<entry>10.4</entry>
<entry><link linkend="Controls_for_Keyboard_Overlays_Overlay1_and_Overlay2_Controls">10.4</link></entry>
</row>
<row>
<entry>Overlay2</entry>
<entry></entry>
<entry></entry>
<entry>XkbOverlay2Mask</entry>
<entry>10.4</entry>
<entry><link linkend="Controls_for_Keyboard_Overlays_Overlay1_and_Overlay2_Controls">10.4</link></entry>
</row>
<row>
<entry>PerKeyRepeat</entry>
<entry>XkbPerKeyRepeatMask</entry>
<entry>per_key_repeat</entry>
<entry><emphasis>Non-Boolean Control</emphasis></entry>
<entry>10.3.1</entry>
<entry><link linkend="The_PerKeyRepeat_Control">10.3.1</link></entry>
</row>
<row>
<entry>RepeatKeys</entry>
@ -3644,14 +3645,14 @@ is described in more detail.
<para>repeat_interval</para>
</entry>
<entry>XkbRepeatKeysMask</entry>
<entry>10.3</entry>
<entry><link linkend="Controls_for_Repeat_Key_Behavior">10.3</link></entry>
</row>
<row>
<entry>SlowKeys</entry>
<entry>XkbSlowKeysMask</entry>
<entry>slow_keys_delay</entry>
<entry>XkbSlowKeysMask</entry>
<entry>10.6.6</entry>
<entry><link linkend="The_SlowKeys_Control">10.6.6</link></entry>
</row>
<row>
<entry>StickyKeys</entry>
@ -3662,7 +3663,7 @@ is described in more detail.
<para>XkbAX_Latch&#xAD;ToLockMask</para>
</entry>
<entry>XkbStickyKeysMask</entry>
<entry>10.6.8</entry>
<entry><link linkend="The_StickyKeys_Control">10.6.8</link></entry>
</row>
</tbody>
</tgroup>
@ -3843,8 +3844,7 @@ The individual fields of the
<emphasis>mk_dflt_btn is an attribute of the </emphasis>
<emphasis>MouseKeys</emphasis>
<emphasis>control</emphasis>
(see section 10.5<emphasis> <!-- xref -->
). It</emphasis>
(see <link linkend="Controls_for_Using_the_Mouse_from_the_Keyboard">section 10.5</link>). It
specifies the mouse button number to use for keyboard simulated mouse button
operations. Its value should be one of the core symbols
<symbol>Button1</symbol>
@ -3875,7 +3875,7 @@ computed automatically by the server whenever the keyboard mapping changes.
<emphasis>groups_wrap</emphasis>
is an attribute of the
<emphasis>GroupsWrap</emphasis>
control (see section 10.7.1). It specifies the handling of illegal groups on a <!-- xref -->
control (see <link linkend="The_GroupsWrap_Control">section 10.7.1</link>). It specifies the handling of illegal groups on a <!-- xref -->
global basis. Valid values for
<emphasis>groups_wrap</emphasis>
are shown in Table 10.8.
@ -3927,7 +3927,7 @@ its four low-order bits specify the index of the group to use.
<emphasis>internal</emphasis>
is an attribute of the
<emphasis>InternalMods</emphasis>
control (see section 10.7.4). It specifies modifiers to be consumed in the <!-- xref -->
control (see <link linkend="The_InternalMods_Control">section 10.7.4</link>). It specifies modifiers to be consumed in the <!-- xref -->
server and not passed on to clients when events are reported. Valid values
consist of any combination of the eight core modifier bits:
<symbol>ShiftMask</symbol>,
@ -3947,7 +3947,7 @@ consist of any combination of the eight core modifier bits:
<emphasis>ignore_lock</emphasis>
is an attribute of the
<emphasis>IgnoreLockMods</emphasis>
control (see section 10.7.2). It specifies modifiers to be ignored in grab <!-- xref -->
control (see <link linkend="The_IgnoreLockMods_Control">section 10.7.2</link>). It specifies modifiers to be ignored in grab <!-- xref -->
calculations. Valid values consist of any combination of the eight core
modifier bits:
<symbol>ShiftMask</symbol>,
@ -3967,7 +3967,7 @@ modifier bits:
<emphasis>enabled_ctrls</emphasis>
is an attribute of the
<emphasis>EnabledControls</emphasis>
control (see section 10.1.1). It contains one bit per boolean control. Each <!-- xref -->
control (see <link linkend="The_EnabledControls_Control">section 10.1.1</link>). It contains one bit per boolean control. Each <!-- xref -->
bit determines whether the corresponding control is enabled or disabled; a one
bit means the control is enabled. The mask bits used to enable these controls
are listed in Table 10.7, using only those masks with "ok" in the
@ -3986,7 +3986,7 @@ are listed in Table 10.7, using only those masks with "ok" in the
<emphasis>repeat_interval</emphasis>
are attributes of the
<emphasis>RepeatKeys</emphasis>
control (see section 10.3.2). <emphasis> <!-- xref -->
control (see <link linkend="The_RepeatKeys_Control">section 10.3.2</link>). <emphasis> <!-- xref -->
repeat_delay</emphasis>
is the initial delay before a key begins repeating, in milliseconds;
<emphasis>repeat_interval</emphasis>
@ -4002,7 +4002,7 @@ repeat_delay</emphasis>
<emphasis>slow_keys_delay</emphasis>
is an attribute of the
<emphasis>SlowKeys</emphasis>
control (see section 10.6.6). Its value specifies the <emphasis> <!-- xref -->
control (see <link linkend="The_SlowKeys_Control">section 10.6.6</link>). Its value specifies the <emphasis> <!-- xref -->
SlowKeys</emphasis>
acceptance delay period in milliseconds before a key press is accepted by the
server.
@ -4017,7 +4017,7 @@ server.
<emphasis>debounce_delay</emphasis>
is an attribute of the
<emphasis>BounceKeys</emphasis>
control (see section 10.6.7). Its value specifies the <emphasis> <!-- xref -->
control (see <link linkend="The_BounceKeys_Control">section 10.6.7</link>). Its value specifies the <emphasis> <!-- xref -->
BounceKeys</emphasis>
delay period in milliseconds for which the key is disabled after having been
pressed before another press of the same key is accepted by the server.
@ -4037,7 +4037,7 @@ and
<emphasis>mk_curve</emphasis>
are attributes of the
<emphasis>MouseKeysAccel</emphasis>
control. Refer to section 10.5.2 for a description of these fields and the <!-- xref -->
control. Refer to <link linkend="The_MouseKeysAccel_Control">section 10.5.2</link> for a description of these fields and the <!-- xref -->
units involved.
</para>
@ -4051,9 +4051,9 @@ The
<emphasis>ax_options</emphasis>
field contains attributes used to configure two different controls, the
<emphasis>StickyKeys</emphasis>
control (see section 10.6.8) and the <emphasis> <!-- xref -->
control (see <link linkend="The_StickyKeys_Control">section 10.6.8</link>) and the <emphasis> <!-- xref -->
AccessXFeedback</emphasis>
control (see section 10.6.3). The <emphasis> <!-- xref -->
control (see <link linkend="The_AccessXFeedback_Control">section 10.6.3</link>). The <emphasis> <!-- xref -->
ax_options</emphasis>
field is a bitmask and may include any combination of the bits defined in
Table 10.9. <!-- xref -->
@ -4254,7 +4254,7 @@ and
<emphasis>axt_ctrls_values</emphasis>
are attributes of the
<emphasis>AccessXTimeout</emphasis>
control. Refer to section 10.6.2 for a description of these fields and the <!-- xref -->
control. Refer to <link linkend="The_AccessXTimeout_Control">section 10.6.2</link> for a description of these fields and the <!-- xref -->
units involved.
</para>
@ -4417,7 +4417,7 @@ To free the
<emphasis>ctrls</emphasis>
member of a keyboard description, use
<function>XkbFreeControls</function>
(see section 10.12)
(see <link linkend="Allocating_and_Freeing_an_XkbControlsRec">section 10.12</link>)
</para>
@ -4552,7 +4552,7 @@ the corresponding values are still updated in the X server. For example, the
set in
<emphasis>enabled_ctrls</emphasis>
). It is permissible to modify the attributes of a control in one call to
XkbSetControls and enable the control in a subsequent call. See section 10.1.1 <!-- xref -->
XkbSetControls and enable the control in a subsequent call. See <link linkend="The_EnabledControls_Control">section 10.1.1</link> <!-- xref -->
for more information on enabling and disabling controls.
</para>
@ -4574,7 +4574,7 @@ Because this is somewhat awkward if all you want to do is enable and disable
controls, and not modify any of their attributes, a convenience function is
also provided for this purpose (
<function>XkbChangeEnabledControls</function>,
section 10.1.1). <!-- xref -->
<link linkend="The_EnabledControls_Control">section 10.1.1</link>). <!-- xref -->
</para>
@ -4709,7 +4709,7 @@ description, the server sends an
<emphasis>XkbControlsNotify</emphasis>
events under all possible conditions, use
<function>XkbSelectEvents</function>
(see section 4.3) and pass
(see <link linkend="Selecting_Xkb_Events">section 4.3</link>) and pass
<emphasis>XkbControlsNotifyMask</emphasis>
in both
<emphasis>bits_to_change</emphasis>
@ -4986,7 +4986,7 @@ results into the
<emphasis>ctrls</emphasis>
field, use
<function>XkbFreeControls</function>
(see section 10.12). <!-- xref -->
(see <link linkend="Allocating_and_Freeing_an_XkbControlsRec">section 10.12</link>). <!-- xref -->
</para>
@ -5197,7 +5197,7 @@ and sets
<para>
You can configure the boolean per-client controls which affect the state
reported in button and key events. See section 12.1.1, 12.3, 12.5, and 16.3.11 <!-- xref -->
reported in button and key events. See <link linkend="Effects_of_Xkb_on_Event_State">section 12.1.1</link>, 12.3, 12.5, and 16.3.11 <!-- xref -->
of the XKB Protocol specification for more details.
</para>

2
specs/XKB/ch11.xml
View file

@ -179,7 +179,7 @@ The
modifiers when processing all keys, even if the definition for the key type
does not specify these modifiers. The
<emphasis>AlwaysConsumeShiftAndLock</emphasis>
control is unset by default. See section 15.2 for a discussion of key types.
control is unset by default. See <link linkend="Key_Types">section 15.2</link> for a discussion of key types.
</para>

10
specs/XKB/ch12.xml
View file

@ -31,7 +31,7 @@ includes ways to control or disable it.
Because
<function>XOpenDisplay</function>
initializes Xkb, some events contain an Xkb description of the keyboard state
instead of that normally used by the core protocol. See section 17.1.1 for more
instead of that normally used by the core protocol. See <link linkend="Xkb_State_to_Core_Protocol_State_Transformation">section 17.1.1</link> for more
information about the differences between Xkb keyboard state and that reported
by the core protocol.
</para>
@ -105,7 +105,7 @@ client’s knowledge. Most clients don’t really care about the range of legal
keycodes, but some clients maintain information about each key and might have
problems with events that come from unexpected keys. Such clients can set the
<emphasis>XkbLC_IgnoreNewKeyboards</emphasis>
library control (see section 11.3.1) to prevent the implicit support from
library control (see <link linkend="IgnoreNewKeyboards">section 11.3.1</link>) to prevent the implicit support from
requesting notification of changes to the legal range of keycodes.
</para>
@ -145,7 +145,7 @@ key. The index specifies a column of symbols in the core keyboard mapping (that
is, as reported by the core protocol
<emphasis>GetKeyboardMapping</emphasis>
request). The order of the symbols in the core mapping does not necessarily
correspond to the order of the symbols used by Xkb; section 17.1.3 describes
correspond to the order of the symbols used by Xkb; <link linkend="Xkb_Keyboard_Mapping_to_Core_Keyboard_Mapping_Transformations">section 17.1.3</link> describes
the differences.
</para>
@ -186,7 +186,7 @@ Xkb is present,
is allowed, but not required, to return strings in character sets other than
ISO Latin-1, depending on the current locale. If any key bindings are defined,
<function>XLookupString</function>
does not use any consumed modifiers (see sections 11.1.2 and 15.2) to
does not use any consumed modifiers (see <link linkend="ConsumeLookupMods">section 11.1.2</link> and <link linkend="Key_Types">section 15.2</link>) to
determine matching bindings.
</para>
@ -859,7 +859,7 @@ To translate a keycode to a key symbol and modifiers, use
<symbol>Mod5Mask</symbol>.
The
<emphasis>AlwaysConsumeShiftAndLock</emphasis>
library control (see section 11.1.3), if enabled, causes
library control (see <link linkend="AlwaysConsumeShiftAndLock">section 11.1.3</link>), if enabled, causes
<function>XkbTranslateKeyCode</function>
to consume shift and lock.
<function>XkbTranslateKeyCode</function>

16
specs/XKB/ch14.xml
View file

@ -177,7 +177,7 @@ exception of compatibility mapping, discussed in <xref linkend="The_Xkb_Compatib
<para>
Xkb handles switching between groups via key actions, independent of any
modifier state information. Key actions are in the server map component and are
described in detail in section 16.1.4.
described in detail in <link linkend="Actions_for_Changing_Group_State">section 16.1.4</link>.
</para>
@ -192,14 +192,14 @@ type and specifies the modifier combinations necessary to access each level.
For example, Xkb allows key types where the
<symbol>Control</symbol>
modifier can be used to access the shift level two of a key. Key types are in
the client map component and are described in detail in section 15.2. <!-- xref -->
the client map component and are described in detail in <link linkend="Key_Types">section 15.2</link>. <!-- xref -->
</para>
<para>
Xkb provides precise specification of the behavior of a key using key
behaviors. Key behaviors are in the server map component and are described in
detail in section 16.2. <!-- xref -->
detail in <link linkend="Key_Behavior">section 16.2</link>. <!-- xref -->
</para>
@ -234,7 +234,7 @@ map, use
<function>XkbGetMap</function>
is similar to
<function>XkbGetKeyboard</function>
(see section 6.2), but is used only for obtaining the address of an
(see <link linkend="Obtaining_a_Keyboard_Description_from_the_Server">section 6.2</link>), but is used only for obtaining the address of an
<emphasis>XkbDescRec</emphasis>
structure that is populated with keyboard mapping components. It allows finer
control over which substructures of the keyboard mapping components are to be
@ -977,7 +977,7 @@ To receive
<emphasis>XkbMapNotify</emphasis>
events under all possible conditions, use
<function>XkbSelectEvents</function>
(see section 4.3) and pass
(see <link linkend="Selecting_Xkb_Events">section 4.3</link>) and pass
<emphasis>XkbMapNotifyMask</emphasis>
in both
<emphasis>bits_to_change</emphasis>
@ -1047,7 +1047,7 @@ The
inclusive OR of the mask bits defined in Table 14.1. The other fields in this
event are interpreted as the like-named fields in an
<emphasis>XkbMapChangesRec</emphasis>
(see section 14.3.1). The
(see <link linkend="The_XkbMapChangesRec_Structure">section 14.3.1</link>). The
<emphasis>XkbMapNotifyEvent</emphasis>
structure also has an additional
<emphasis>resized</emphasis>
@ -1062,7 +1062,7 @@ event are interpreted as the like-named fields in an
<para>
Calling
<function>XkbGetMap</function>
(see section 14.2) should be sufficient for most applications to get client
(see <link linkend="Getting_Map_Components_from_the_Server">section 14.2</link>) should be sufficient for most applications to get client
and server maps. As a result, most applications do not need to directly
allocate client and server maps.
</para>
@ -1185,7 +1185,7 @@ field specifies the number of entries to preallocate for the
<emphasis>type_count </emphasis>
field is less than
<emphasis>XkbNumRequiredTypes</emphasis>
(see section 15.2.1), returns
(see <link linkend="The_Canonical_Key_Types">section 15.2.1</link>), returns
<errorname>BadValue</errorname>.
</entry>
</row>

22
specs/XKB/ch15.xml
View file

@ -31,7 +31,7 @@ Xkb Client Map</H5>
<para>
The
<emphasis>map </emphasis>
field of the complete Xkb keyboard description (see section 6.1) is a pointer
field of the complete Xkb keyboard description (see <link linkend="The_XkbDescRec_Structure">section 6.1</link>) is a pointer
to the Xkb client map, which is of type
<emphasis>XkbClientMapRec</emphasis>
:
@ -106,7 +106,7 @@ The
<emphasis>mods</emphasis>
field of a key type is an
<emphasis>XkbModsRec</emphasis>
(see section 7.2) specifying the modifiers the key type uses when calculating
(see <link linkend="Modifier_Definitions">section 7.2</link>) specifying the modifiers the key type uses when calculating
the shift level, and can be composed of both the core modifiers and virtual
modifiers. To set the modifiers associated with a key type, modify the
<emphasis>real_mods</emphasis>
@ -136,7 +136,7 @@ The
<emphasis>num_levels</emphasis>
directly to change the number if shift levels for a key type. Instead, use
<function>XkbResizeKeyType</function>
(see section 15.2.3).
(see <link linkend="Changing_the_Number_of_Levels_in_a_Key_Type">section 15.2.3</link>).
</para>
@ -197,7 +197,7 @@ Any modifiers specified in
<emphasis>consumed</emphasis>
by
<function>XkbTranslateKeyCode</function>
(see section 12.1.3). For those rare occasions a modifier
(see <link linkend="X_Library_Functions_Affected_by_Xkb">section 12.1.3</link>). For those rare occasions a modifier
<emphasis>should</emphasis>
be considered despite having been used to look up a symbol, key types include
an optional
@ -350,7 +350,7 @@ that the virtual
<note><para>Shift level three can be reached only if the virtual modifier
<emphasis>LevelThree</emphasis>
is bound to a real modifier (see section 16.4). If
is bound to a real modifier (see <link linkend="Virtual_Modifier_Mapping">section 16.4</link>). If
<emphasis>LevelThree</emphasis>
is not bound to a real modifier, the
<emphasis>map</emphasis>
@ -811,7 +811,7 @@ use
bound to individual keys. To obtain the key types bound to an individual key,
refer to the
<emphasis>key_sym_map</emphasis>
field of the client map (see section 15.3.1).</para></note>
field of the client map (see <link linkend="Per_Key_Key_Type_Indices">section 15.3.1</link>).</para></note>
<para>
<function>XkbGetKeyTypes</function>
@ -1279,7 +1279,7 @@ The
<emphasis>kt_index</emphasis>
array of the
<emphasis>XkbSymMapRec</emphasis>
structure contains the indices of the key types (see section 15.2) for each
structure contains the indices of the key types (see <link linkend="Key_Types">section 15.2</link>) for each
possible group of symbols associated with the key. To obtain the index of a key
type or the pointer to a key type, Xkb provides the following macros, to access
the key types:
@ -1430,7 +1430,7 @@ To obtain the number of groups of symbols bound to the key, use
<function>XkbKeyNumGroups</function>.
To change the number of groups bound to a key, use
<function>XkbChangeTypesOfKey</function>
(see section 15.3.6). To obtain a mask that determines the treatment of
(see <link linkend="Changing_the_Number_of_Groups_and_Types_Bound_to_a_Key">section 15.3.6</link>). To obtain a mask that determines the treatment of
out-of-range groups, use
<function>XkbKeyGroupInfo</function>
and
@ -1469,7 +1469,7 @@ Out-of-range groups for individual keys are mapped to a legal group using the
same options as are used for the overall keyboard group. The particular type of
mapping used is controlled by the bits set in the
<emphasis>group_info</emphasis>
flag, as shown in Table 15.2. See section 10.7.1 for more details on the
flag, as shown in Table 15.2. See <link linkend="The_GroupsWrap_Control">section 10.7.1</link> for more details on the
normalization methods in this table.
</para>
@ -2255,7 +2255,7 @@ as appropriate. If the
<emphasis>p_changes</emphasis>
to include the
<emphasis>key</emphasis>
that was changed. See section 14.3.1 for more information on the
that was changed. See <link linkend="The_XkbMapChangesRec_Structure">section 14.3.1</link> for more information on the
<emphasis>XkbMapChangesPtr</emphasis>
structure. If successful,
<function>XkbChangeTypesOfKey</function>
@ -2503,7 +2503,7 @@ the key,
<note><para>A change to the number of symbols bound to a key should be
accompanied by a change in the number of actions bound to a key. Refer to
section 16.1.16 for more information on changing the number of actions bound to
<link linkend="Changing_the_Number_of_Actions_Bound_to_a_Key">section 16.1.16</link> for more information on changing the number of actions bound to
a key.</para></note>

62
specs/XKB/ch16.xml
View file

@ -4,7 +4,7 @@
<para>
The
<emphasis>server</emphasis>
field of the complete Xkb keyboard description (see section 6.1) is a pointer
field of the complete Xkb keyboard description (see <link linkend="The_XkbDescRec_Structure">section 6.1</link>) is a pointer
to the Xkb server map.
</para>
@ -56,9 +56,9 @@ The
<emphasis>acts</emphasis>,
and
<emphasis>key_acts</emphasis>
fields specify the key actions, defined in section 16.1. The
fields specify the key actions, defined in <link linkend="Key_Actions">section 16.1</link>. The
<emphasis>behaviors</emphasis>
field describes the behavior for each key and is defined in section 16.2. The
field describes the behavior for each key and is defined in <link linkend="Key_Behavior">section 16.2</link>. The
<emphasis>explicit</emphasis>
field describes the explicit components for a key and is defined in section
16.3. The
@ -66,7 +66,7 @@ and
and the
<emphasis>vmodmap</emphasis>
fields describe the virtual modifiers and the per-key virtual modifier mapping
and are defined in section 16.4.
and are defined in <link linkend="Virtual_Modifier_Mapping">section 16.4</link>.
</para>
<sect1 id='Key_Actions'>
@ -244,7 +244,7 @@ to key actions:
<emphasis>keycode</emphasis>.
This should be the same value as the result of
<function>XkbKeyNumSyms</function>
(see section 15.3.3).
(see <link linkend="Key_Width">section 15.3.3</link>).
</para>
@ -874,8 +874,8 @@ The
<emphasis>vmods1</emphasis>,
and
<emphasis>vmods2</emphasis>
fields represent the components of an Xkb modifier description (see section
7.2). While the
fields represent the components of an Xkb modifier description
(see <link linkend="Modifier_Definitions">section 7.2</link>). While the
<emphasis>mask</emphasis>
and
<emphasis>real_mods</emphasis>
@ -1044,14 +1044,14 @@ the
field to the base keyboard group. In either case, the resulting effective
keyboard group is brought back into range depending on the value of the
<emphasis>groups_wrap</emphasis>
field of the controls structure (see section 10.7.1).
field of the controls structure (see <link linkend="The_GroupsWrap_Control">section 10.7.1</link>).
</para>
</listitem>
<listitem>
<para>
If a key with an
<emphasis>XkbSA_ISOLock</emphasis>
action (see section 16.1.8) is pressed while this key is down, the key release
action (see <link linkend="Actions_for_Locking_Modifiers_and_Group">section 16.1.8</link>) is pressed while this key is down, the key release
of this key has no effect. Otherwise, the key release cancels the effects of
the key press.
</para>
@ -1306,7 +1306,7 @@ typedef struct _XkbPtrAction {
<para>
If the
<emphasis>MouseKeys</emphasis>
control is not enabled (see section 10.5.1),
control is not enabled (see <link linkend="The_MouseKeys_Control">section 10.5.1</link>),
<symbol>KeyPress</symbol>
and
<symbol>KeyRelease</symbol>
@ -1366,7 +1366,7 @@ The
<entry>
If not set, and the
<emphasis>MouseKeysAccel</emphasis>
control is enabled (see section 10.5.2), the
control is enabled (see <link linkend="The_MouseKeysAccel_Control">section 10.5.2</link>), the
<symbol>KeyPress</symbol>
initiates a mouse keys timer for this key; every time the timer expires, the
cursor moves.
@ -1597,7 +1597,7 @@ typedef struct _XkbPtrBtnAction {
<para>
If the
<emphasis>MouseKeys</emphasis>
(see section 10.5.1) control is not enabled,
(see <link linkend="The_MouseKeys_Control">section 10.5.1</link>) control is not enabled,
<symbol>KeyPress</symbol>
and
<symbol>KeyRelease</symbol>
@ -1639,7 +1639,7 @@ If
<emphasis>mk_dflt_btn</emphasis>
attribute of the
<emphasis>MouseKeys</emphasis>
control (see section 10.5.1). Otherwise, the event is generated for the button
control (see <link linkend="The_MouseKeys_Control">section 10.5.1</link>). Otherwise, the event is generated for the button
specified by the
<emphasis>button</emphasis>
field.
@ -1765,7 +1765,7 @@ If set, the action uses the pointer button specified by the
<emphasis>mk_dflt_btn</emphasis>
attribute of the
<emphasis>MouseKeys</emphasis>
control (see section 10.5.1). Otherwise, the action uses the pointer button
control (see <link linkend="The_MouseKeys_Control">section 10.5.1</link>). Otherwise, the action uses the pointer button
specified by the
<emphasis>button </emphasis>
field.
@ -1802,7 +1802,7 @@ Actions associated with the
<emphasis>mk_dflt_btn</emphasis>
attribute of the
<emphasis>MouseKeys</emphasis>
control (see section 10.5.1):
control (see <link linkend="The_MouseKeys_Control">section 10.5.1</link>):
</para>
<para><programlisting>
@ -1891,7 +1891,7 @@ The
<emphasis>mk_dflt_btn</emphasis>
attribute of the
<emphasis>MouseKeys</emphasis>
control (see section 10.5.1). If
control (see <link linkend="The_MouseKeys_Control">section 10.5.1</link>). If
<emphasis>XkbSA_DfltBtnAbsolute</emphasis>
is set in
<emphasis>flags</emphasis>,
@ -2219,7 +2219,7 @@ the
<emphasis>vmods1</emphasis>,
and
<emphasis>vmods2 </emphasis>
fields (see section 16.1.3). If no other actions are transformed by the
fields (see <link linkend="Actions_for_Changing_Modifiers_State">section 16.1.3</link>). If no other actions are transformed by the
<emphasis>XkbISO_Lock</emphasis>
action, a key release locks the action modifiers. Otherwise, a key release
clears the base modifiers set by the key press.
@ -2319,8 +2319,8 @@ The
<emphasis>vmods1</emphasis>,
and
<emphasis>vmods2</emphasis>
fields represent the components of an Xkb modifier description (see section
7.2). While the
fields represent the components of an Xkb modifier description
(see <link linkend="Modifier_Definitions">section 7.2</link>). While the
<emphasis>mask</emphasis>
and
<emphasis>real_mods</emphasis>
@ -2335,7 +2335,7 @@ and
fields are combined to correspond to the
<emphasis>vmods</emphasis>
field of an Xkb modifier description. Xkb provides macros to convert between
the two formats as shown in section 16.1.3.
the two formats as shown in <link linkend="Actions_for_Changing_Modifiers_State">section 16.1.3</link>.
</para>
@ -2600,7 +2600,7 @@ signed character value for screen numbers in
<para>
Actions associated with the
<emphasis>XkbCtrlsAction</emphasis>
structure change the state of the boolean controls (see section 10.1):
structure change the state of the boolean controls (see <link linkend="Controls_that_Enable_and_Disable_Other_Controls">section 10.1</link>):
</para>
<para><programlisting>
@ -2659,7 +2659,7 @@ A key release disables any controls enabled by the key press.
<para>
This action can cause
<emphasis>XkbControlsNotify</emphasis>
events (see section 10.1).
events (see <link linkend="Controls_that_Enable_and_Disable_Other_Controls">section 10.1</link>).
</para>
</listitem>
</itemizedlist>
@ -2695,7 +2695,7 @@ If the
<para>
This action can cause
<emphasis>XkbControlsNotify</emphasis>
events (see section 10.1).
events (see <link linkend="Controls_that_Enable_and_Disable_Other_Controls">section 10.1</link>).
</para>
</listitem>
</itemizedlist>
@ -2770,7 +2770,7 @@ and
<emphasis>ctrls3</emphasis>
fields represent the boolean controls in the
<emphasis>enabled_ctrls</emphasis>
field of the controls structure (see section 10.1). Xkb provides the following
field of the controls structure (see <link linkend="Controls_that_Enable_and_Disable_Other_Controls">section 10.1</link>). Xkb provides the following
macros, to convert between the two formats:
</para>
@ -2963,7 +2963,7 @@ To receive
<function>XkbSelectEvents</function>
or
<function>XkbSelectEventDetails</function>
(see section 4.3).
(see <link linkend="Selecting_Xkb_Events">section 4.3</link>).
</para>
@ -3930,7 +3930,7 @@ the key,
<note><para>A change to the number of actions bound to a key should be
accompanied by a change in the number of symbols bound to a key. Refer to
section 15.3.7 for more information on changing the number of symbols bound to
<link linkend="Changing_the_Number_of_Symbols_Bound_to_a_Key">section 15.3.7</link> for more information on changing the number of symbols bound to
a key.</para></note>
@ -4086,7 +4086,7 @@ All other key release events are ignored.
<entry>
If the
<emphasis>Overlay1</emphasis>
control is enabled (see section 10.4),
control is enabled (see <link linkend="Controls_for_Keyboard_Overlays_Overlay1_and_Overlay2_Controls">section 10.4</link>),
<emphasis>data</emphasis>
is interpreted as a keycode, and events from this key are reported as if they
came from
@ -4099,7 +4099,7 @@ came from
<entry>
If the
<emphasis>Overlay2</emphasis>
control is enabled (see section 10.4),
control is enabled (see <link linkend="Controls_for_Keyboard_Overlays_Overlay1_and_Overlay2_Controls">section 10.4</link>),
<emphasis>data</emphasis>
is interpreted as a keycode, and events from this key are reported as if they
came from
@ -4255,7 +4255,7 @@ If any allocation errors occur,
<para>
Whenever a client remaps the keyboard using core protocol requests, Xkb
examines the map to determine likely default values for the components that
cannot be specified using the core protocol (see section 17.1.2 for more
cannot be specified using the core protocol (see <link linkend="Core_Keyboard_Mapping_to_Xkb_Keyboard_Mapping_Transformation">section 17.1.2</link> for more
information on how Xkb chooses the default values).
</para>
@ -4517,7 +4517,7 @@ The
<emphasis>vmodmap</emphasis>
member of the server map is similar to the
<emphasis>modmap</emphasis>
array of the client map (see section 15.4), but is used to define the virtual
array of the client map (see <link linkend="The_Per_Key_Modifier_Map">section 15.4</link>), but is used to define the virtual
modifier mapping for each key. Like the
<emphasis>modmap</emphasis>
member, it is indexed by keycode, and each entry is a mask representing the
@ -4644,7 +4644,7 @@ To obtain a subset of the virtual modifier bindings (the
<emphasis>vmods</emphasis>
entries for the virtual modifiers specified in the mask,
<emphasis>which</emphasis>,
and waits for a reply. See section 7.1 for a description of how to determine
and waits for a reply. See <link linkend="Virtual_Modifier_Names_and_Masks">section 7.1</link> for a description of how to determine
the virtual modifier mask. For each bit set in
<emphasis>which</emphasis>,
<function>XkbGetVirtualMods</function>

30
specs/XKB/ch17.xml
View file

@ -132,7 +132,7 @@ contained in an
structure; plus a set of explicit override controls used to prevent particular
components of type 2 (core-to-Xkb keyboard mapping) transformations from
automatically occurring. These explicit override controls are maintained in a
separate data structure discussed in section 16.3. <!-- xref -->
separate data structure discussed in <link linkend="Explicit_ComponentsAvoiding_Automatic_Remapping_by_the_Server">section 16.3</link>. <!-- xref -->
</para>
@ -181,7 +181,7 @@ As shown in Figure 17.3, there are four
[0..3]) in the
<emphasis>XkbCompatMapRec</emphasis>
structure, one per possible Xkb group. Each group compatibility map is a
modifier definition (see section 7.2 for a description of modifier
modifier definition (see <link linkend="Modifier_Definitions">section 7.2</link> for a description of modifier
definitions). The
<emphasis>mask</emphasis>
component of the definition specifies which real modifiers should be set in
@ -258,7 +258,7 @@ Xkb keyboard mapping in the server, this automatic regeneration of the Xkb
keyboard mapping from the core protocol keyboard mapping should not modify any
components of the Xkb keyboard mapping that were explicitly set by a client.
The client must set explicit override controls to prevent this from happening
(see section 16.3). The core-to-Xkb mapping is done as follows:
(see <link linkend="Explicit_ComponentsAvoiding_Automatic_Remapping_by_the_Server">section 16.3</link>). The core-to-Xkb mapping is done as follows:
</para>
<orderedlist>
@ -367,7 +367,7 @@ Apply symbol interpretations to modify key operation. This phase is completely
skipped if the
<emphasis>ExplicitInterpret</emphasis>
override control bit is set in the explicit controls mask for the Xkb key (see
section 16.3).
<link linkend="Explicit_ComponentsAvoiding_Automatic_Remapping_by_the_Server">section 16.3</link>).
</para>
<orderedlist>
<listitem>
@ -407,7 +407,7 @@ Symbol interpretations are used to guide the X server when it modifies the Xkb
keymap in step 2. An initial set of symbol interpretations is loaded by the
server when it starts. A client may add new ones using
<function>XkbSetCompatMap</function>
(see section 17.4).
(see <link linkend="Changing_the_Servers_Compatibility_Map">section 17.4</link>).
</para>
@ -421,7 +421,7 @@ processing may be modified for the particular key involved:
Virtual modifier map
Auto repeat
Key behavior (may be set to <emphasis>XkbKB_Lock</emphasis>)
Key action (see section 16.1)
Key action (see <link linkend="Key_Actions">section 16.1</link>)
</literallayout>
<para>
@ -605,7 +605,7 @@ The
<emphasis>act</emphasis>
field specifies a single action to be bound to the symbol position; any key
event that selects the symbol causes the action to be taken. Valid actions are
defined in section 16.1.
defined in <link linkend="Key_Actions">section 16.1</link>.
</para>
@ -666,7 +666,7 @@ If the Xkb keyboard map for the key does not have its
<emphasis>XkbSI_LockingKey</emphasis>
is set, the key behavior is set to
<emphasis>KB_Lock</emphasis>
; otherwise, it is turned off (see section 16.3).
; otherwise, it is turned off (see <link linkend="Explicit_ComponentsAvoiding_Automatic_Remapping_by_the_Server">section 16.3</link>).
</para>
@ -744,7 +744,7 @@ Use
server. When another client modifies the compatibility map, you are notified if
you have selected for
<emphasis>XkbCompatMapNotify</emphasis>
events (see section 17.5).
events (see <link linkend="Tracking_Changes_to_the_Compatibility_Map">section 17.5</link>).
<function>XkbGetCompatMap</function>
is particularly useful when you receive an event of this type, as it allows
you to update your program’s version of the compatibility map to match the
@ -1150,7 +1150,7 @@ key in a core keyboard mapping. Use
and types in
<emphasis>types_inout</emphasis>
according to the rules specified in section 12 of the core protocol, then
chooses canonical key types (canonical key types are defined in section 15.2.1)
chooses canonical key types (canonical key types are defined in <link linkend="The_Canonical_Key_Types">section 15.2.1</link>)
for groups 1 and 2 using the rules specified by the Xkb protocol and places
them in
<emphasis>xkb_syms_rtrn</emphasis>,
@ -1266,7 +1266,7 @@ semantics updated, use
<para>
<function>XkbApplyCompatMapToKey</function>
essentially performs the operation described in section 17.1.2 to a specific
essentially performs the operation described in <link linkend="Core_Keyboard_Mapping_to_Xkb_Keyboard_Mapping_Transformation">section 17.1.2</link> to a specific
key. This updates the behavior, actions, repeat status, and virtual modifier
bindings of the key.
</para>
@ -1282,7 +1282,7 @@ Xkb compatibility map, then call
<function>XkbSetCompatMap</function>.
You may allocate a new compatibility map for this purpose using
<function>XkbAllocCompatMap</function>
(see section 17.6). You may also use a compatibility map from another server,
(see <link linkend="Allocating_and_Freeing_the_Compatibility_Map">section 17.6</link>). You may also use a compatibility map from another server,
although you need to adjust the
<emphasis>device_spec</emphasis>
field in the
@ -1525,7 +1525,7 @@ To receive
<emphasis>XkbCompatMapNotify</emphasis>
events under all possible conditions, use
<function>XkbSelectEvents</function>
(see section 4.3) and pass
(see <link linkend="Selecting_Xkb_Events">section 4.3</link>) and pass
<emphasis>XkbCompatMapNotifyMask</emphasis>
in both
<emphasis>bits_to_change</emphasis>
@ -1690,7 +1690,7 @@ allocated. The compatibility map is the
<emphasis>which</emphasis>
specifies the compatibility map components to be allocated (see
<function>XkbGetCompatMap</function>,
in section 17.2).
in <link linkend="Getting_Compatibility_Map_Components_From_the_Server">section 17.2</link>).
<emphasis>which</emphasis>
is an inclusive OR of the bits shown in Table 17.2.
</para>
@ -1796,7 +1796,7 @@ To free an entire compatibility map or selected portions of one, use
<emphasis>which</emphasis>
specifies the compatibility map components to be freed (see
<function>XkbGetCompatMap</function>,
in section 17.2).
in <link linkend="Getting_Compatibility_Map_Components_From_the_Server">section 17.2</link>).
<emphasis>which</emphasis>
is an inclusive OR of the bits shown in Table 17.2
</para>

6
specs/XKB/ch18.xml
View file

@ -123,7 +123,7 @@ English US engravings, but that is using Swiss German symbols might have a
<para>
The
<emphasis>types</emphasis>
name provides some information about the set of key types (see section 15.2)
name provides some information about the set of key types (see <link linkend="Key_Types">section 15.2</link>)
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. Although these names are
stored in the map description with each of the types, they are accessed using
@ -485,7 +485,7 @@ and
<para>
To free symbolic names, use
<function>XkbFreeNames</function>
(see section 18.6)
(see <link linkend="Allocating_and_Freeing_Symbolic_Names">section 18.6</link>)
</para>
@ -835,7 +835,7 @@ server sends a
<emphasis>XkbNamesNotify</emphasis>
event to all interested clients. To receive name notify events, use
<function>XkbSelectEvents</function>
(see section 4.3) with
(see <link linkend="Selecting_Xkb_Events">section 4.3</link>) with
<emphasis>XkbNamesNotifyMask</emphasis>
in both the
<emphasis>bits_to_change</emphasis>

4
specs/XKB/ch19.xml
View file

@ -187,7 +187,7 @@ typedef struct _XkbNewKeyboardNotify {
<para>
To receive name notify events, use
<function>XkbSelectEvents</function>
(see section 4.3) with
(see <link linkend="Selecting_Xkb_Events">section 4.3</link>) with
<emphasis>XkbNewKeyboardNotifyMask</emphasis>
in both the
<emphasis>bits_to_change</emphasis>
@ -309,7 +309,7 @@ If the keyboard change is the result of an
<emphasis>X_kbGetKbdByName</emphasis>
request,
<emphasis>req_major</emphasis>
contains the Xkb extension base event code (see section 2.4), and
contains the Xkb extension base event code (see <link linkend="Initializing_the_Keyboard_Extension">section 2.4</link>), and
<emphasis>req_minor</emphasis>
contains the event code for the Xkb extension request
<emphasis>X_kbGetKbdByName</emphasis>.

8
specs/XKB/ch20.xml
View file

@ -253,8 +253,8 @@ composed of characters from the ISO
<emphasis>?</emphasis>
’ and ‘
<emphasis>*</emphasis>
’, and characters permitted in a component class or member name (see section
20.1). A pattern may be
’, and characters permitted in a component class or member name
(see <link linkend="Component_Names">section 20.1</link>). A pattern may be
<emphasis>NULL</emphasis>,
in which case no components for that type is returned. Pattern matches with
component names are case sensitive. The ‘
@ -265,7 +265,7 @@ the ‘
’ wildcard matches any number of characters, except a left or right
parenthesis. If an implementation allows additional characters in a component
class or member name other than those required by the Xkb extension (see
section 20.1), the result of comparing one of the additional characters to
<link linkend="Component_Names">section 20.1</link>), the result of comparing one of the additional characters to
either of the wildcard characters is implementation-dependent.
</para>
@ -1099,7 +1099,7 @@ If you simply want to obtain information about the current keyboard device,
rather than generating a new keyboard description from elements in the server
database, use
<function>XkbGetKeyboard</function>
(see section 6.2).
(see <link linkend="Obtaining_a_Keyboard_Description_from_the_Server">section 6.2</link>).
</para>
<indexterm significance="preferred" zone="XkbGetKeyboard"><primary><function>XkbGetKeyboard</function></primary></indexterm>

8
specs/XKB/ch21.xml
View file

@ -596,8 +596,8 @@ the
function description are updated. The
<emphasis>XkbDeviceInfo</emphasis>
Rec structure used in the function call can be obtained by calling
XkbGetDeviceInfo or can be allocated by calling XkbAllocDeviceInfo (see section
21.3).
XkbGetDeviceInfo or can be allocated by calling XkbAllocDeviceInfo
(see <link linkend="Allocating_Initializing_and_Freeing_the_XkbDeviceInfoRecStructure">section 21.3</link>).
</para>
@ -1407,7 +1407,7 @@ modify a local copy of the device structure and then use either
<function>XkbSetDeviceInfo</function>,
or, to save network traffic, use an
<emphasis>XkbDeviceChangesRec</emphasis>
structure (see section 21.6) and call
structure (see <link linkend="Tracking_Changes_to_Extension_Devices">section 21.6</link>) and call
<function>XkbChangeDeviceInfo</function>
to download the changes to the server.
</para>
@ -1751,7 +1751,7 @@ unsupported features of a device, select to receive
<function>XkbSelectEvents</function>
or
<function>XkbSelectEventDetails</function>
(see section 4.3).
(see <link linkend="Selecting_Xkb_Events">section 4.3</link>).
</para>