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

specs/XKB: Manual fixup of struct name/field markup

Browse source 
Handles typos that caused the scripts to miss matches, misnamed structs, etc.

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This commit is contained in:
Alan Coopersmith 2014-07-10 13:40:40 -07:00
parent c36ee1a4db
commit 5526dce681
15 changed files with 171 additions and 182 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
specs/XKB/ch02.xml
View file

@ -671,9 +671,9 @@ to the core protocol error set. This error code will be reported as the
error is reported in an
<structname>XErrorEvent</structname>,
additional information is reported in the
<emphasis>resource_id</emphasis>
<structfield>resourceid</structfield>
field. The most significant byte of the
<emphasis>resource_id</emphasis>
<structfield>resource_id</structfield>
is a further refinement of the error cause, as defined in
<link linkend="table2.2">Table 2.2</link>. The least
significant byte will contain the device, class, or feedback ID as indicated in

2
specs/XKB/ch04.xml
View file

@ -794,7 +794,7 @@ type and for the core protocol
<structfield>type</structfield>
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>
<structfield>any.xkb_type</structfield>
field to determine the type of Xkb event and thereafter access the
event-dependent components using the union member corresponding to the
particular Xkb event type.

2
specs/XKB/ch05.xml
View file

@ -972,7 +972,7 @@ and
the latched group, and the locked group, respectively. The X
server can set the modifier and compatibility state fields to
a union of the core modifier mask bits; this union represents the
corresponding modifier states. The <emphasis>ptr_button</emphasis>
corresponding modifier states. The <structfield>ptr_buttons</structfield>
field gives the state of the core pointer buttons as a
mask composed of an inclusive OR of zero or more of the
core pointer button masks.

45
specs/XKB/ch07.xml
View file

@ -67,15 +67,15 @@ in effect.
Virtual modifiers are named by converting their string name to an X
<type>Atom</type>
and storing the Atom in the
<emphasis>names.vmods</emphasis>
<structfield>names.vmods</structfield>
array in an
<structname>XkbDescRec</structname>
structure (see <link linkend="The_XkbDescRec_Structure">section 6.1</link>). The position of a name Atom in the
<emphasis>names.vmods</emphasis>
<structfield>names.vmods</structfield>
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
in the i-th (0 relative) entry of
<emphasis>names.vmods</emphasis>
<structfield>names.vmods</structfield>
is the i-th virtual modifier, represented by the mask (1&lt;&lt;i). Throughout
Xkb, various functions have a parameter that is a mask representing virtual
modifier choices. In each case, the i-th bit (0 relative) of the mask
@ -129,27 +129,24 @@ real modifiers */
<para>
An Xkb modifier definition consists of a set of bit masks corresponding to the
eight real modifiers (
<structfield>real_mods</structfield>
); a similar set of bitmasks corresponding to the 16 named virtual modifiers
(
<structfield>vmods</structfield>
); and an effective mask (
<structfield>mask</structfield>
). The effective mask represents the set of all real modifiers that can
eight real modifiers
(<structfield>real_mods</structfield>);
a similar set of bitmasks corresponding to the 16 named virtual modifiers
(<structfield>vmods</structfield>);
and an effective mask
(<structfield>mask</structfield>).
The effective mask represents the set of all real modifiers that can
logically be set either by setting any of the real modifiers or by setting any
of the virtual modifiers in the definition.
<structfield>mask</structfield>
is derived from the real and virtual modifiers and should never be explicitly
changed — it contains all of the real modifiers specified in the definition
(
<structfield>real_mods</structfield>
)
(<structfield>real_mods</structfield>)
<emphasis>plus</emphasis>
any real modifiers that are bound to the virtual modifiers specified in the
definition (
<structfield>vmods</structfield>
). The binding of the virtual modifiers to real modifiers is exterior to the
definition
(<structfield>vmods</structfield>).
The binding of the virtual modifiers to real modifiers is exterior to the
modifier definition. Xkb automatically recomputes the mask field of modifier
definitions as necessary. Whenever you access a modifier definition that has
been retrieved using an Xkb library function, the mask field will be correct
@ -163,7 +160,7 @@ for the keyboard mapping of interest.
<para>
The binding of virtual modifiers to real modifiers is defined by the
<emphasis>server.vmods</emphasis>
<structfield>server.vmods</structfield>
array in an
<structname>XkbDescRec</structname>
structure. Each entry contains the real modifier bits that are bound to the
@ -184,10 +181,10 @@ which lists the virtual modifiers associated with, or bound to, each key. The
real modifiers bound to a virtual modifier always include all of the modifiers
bound to any of the keys that specify that virtual modifier in their virtual
modifier mapping. The
<emphasis>server.vmodmap</emphasis>
<structfield>server.vmodmap</structfield>
array indicates which virtual modifiers are bound to each key; each entry is a
bitmask for the virtual modifier bits. The
<emphasis>server.vmodmap</emphasis>
<structfield>server.vmodmap</structfield>
array is indexed by keycode.
</para>
@ -387,12 +384,12 @@ following names are suggested:
<para>
If the second (0-relative) entry in
<emphasis>names.vmods</emphasis>
<structfield>names.vmods</structfield>
contains the Atom for "NumLock", then 0x4 (1&lt;&lt;2) is the virtual modifier
bit for the
<emphasis>NumLock</emphasis>
virtual modifier. If
<emphasis>server.vmods</emphasis>
<structfield>server.vmods</structfield>
[2] contains
<symbol>Mod3Mask</symbol>,
then the
@ -419,8 +416,8 @@ Continuing the example, if the keyboard has a
keysym bound to the key with keycode 14, and the
<emphasis>NumLock</emphasis>
virtual modifier is bound to this key,
<emphasis>server.vmodmap</emphasis>
[14] contains 0x4.
<structfield>server.vmodmap[14]</structfield>
contains 0x4.
</para>

30
specs/XKB/ch08.xml
View file

@ -16,12 +16,12 @@ the logical state of the
<para>
Furthermore, the core X implementation does not provide clients with the
ability to determine what bits in the
<emphasis>led_mask</emphasis>
<structfield>led_mask</structfield>
field of the
<structname>XKeyboardState</structname>
map to the particular LEDs on the keyboard. For example, X does not provide a
method for a client to determine what bit to set in the
<emphasis>led_mask</emphasis>
<structfield>led_mask</structfield>
field to turn on the
<guilabel>Scroll Lock</guilabel>
LED or whether the keyboard even has a
@ -538,11 +538,11 @@ modifiers. The
<structfield>mods</structfield>
are unbound. To specify the mods field, in general, assign the modifiers of
interest to
<emphasis>mods.real_mods</emphasis>
<structfield>mods.real_mods</structfield>
and the virtual modifiers of interest to
<emphasis>mods.vmods</emphasis>.
<structfield>mods.vmods</structfield>.
You can disregard the
<emphasis>mods.mask</emphasis>
<structfield>mods.mask</structfield>
field unless your application needs to interpret the indicator map directly
(that is, to simulate automatic indicator behavior on its own). Relatively few
applications need to do so, but if you find it necessary, you can either read
@ -627,9 +627,9 @@ The indicator is lit when any of the modifiers specified in the
field of
<structfield>mods</structfield>
are on in the keyboard base state. If both
<emphasis>mods.real_mods</emphasis>
<structfield>mods.real_mods</structfield>
and
<emphasis>mods.vmods</emphasis>
<structfield>mods.vmods</structfield>
are zero, the indicator is lit when the base keyboard state contains no
modifiers.
</entry>
@ -642,9 +642,9 @@ The indicator is lit when any of the modifiers specified in the
field of
<structfield>mods</structfield>
are latched. If both
<emphasis>mods.real_mods</emphasis>
<structfield>mods.real_mods</structfield>
and
<emphasis>mods.vmods</emphasis>
<structfield>mods.vmods</structfield>
are zero, the indicator is lit when none of the modifier keys are latched.
</entry>
</row>
@ -656,9 +656,9 @@ The indicator is lit when any of the modifiers specified in the
field of
<structfield>mods</structfield>
are locked. If both
<emphasis>mods.real_mods</emphasis>
<structfield>mods.real_mods</structfield>
and
<emphasis>mods.vmods</emphasis>
<structfield>mods.vmods</structfield>
are zero, the indicator is lit when none of the modifier keys are locked.
</entry>
</row>
@ -670,9 +670,9 @@ The indicator is lit when any of the modifiers specified in the
field of
<structfield>mods</structfield>
are in the effective keyboard state. If both
<emphasis>mods.real_mods</emphasis>
<structfield>mods.real_mods</structfield>
and
<emphasis>mods.vmods</emphasis>
<structfield>mods.vmods</structfield>
are zero, the indicator is lit when the effective keyboard state contains no
modifiers.
</entry>
@ -685,9 +685,9 @@ The indicator is lit when any of the modifiers specified in the
field of
<structfield>mods</structfield>
are in the keyboard compatibility state. If both
<emphasis>mods.real_mods</emphasis>
<structfield>mods.real_mods</structfield>
and
<emphasis>mods.vmods</emphasis>
<structfield>mods.vmods</structfield>
are zero, the indicator is lit when the keyboard compatibility state contains
no modifiers.
</entry>

30
specs/XKB/ch10.xml
View file

@ -658,7 +658,7 @@ protocol. There are no convenience functions in Xkb for manipulating this
control. The
<emphasis>PerKeyRepeat</emphasis>
control settings are carried in the
<emphasis>per_key_repeat</emphasis>
<structfield>per_key_repeat</structfield>
field of an
<structname>XkbControlsRec</structname>
structure, discussed in <link linkend="The_XkbControlsRec_Structure">section 10.8</link>.
@ -4158,7 +4158,7 @@ enabled (
or
<symbol>XkbStickyKeysMask</symbol>
bit is turned on in the
<emphasis>enabled_cntrls</emphasis>
<structfield>enabled_ctrls</structfield>
field).
</para>
@ -4256,7 +4256,7 @@ id='ax_timeout_axt_opts_mask_axt_opts_values_axt_ctrls_mask_and_axt_ctrls_values
<para>
<structfield>ax_timeout</structfield>,
<emphasis>act_opts_mask</emphasis>,
<structfield>axt_opts_mask</structfield>,
<structfield>axt_opts_values</structfield>,
<structfield>axt_ctrls_mask</structfield>,
and
@ -4274,29 +4274,29 @@ units involved.
<para>
The
<emphasis>per_key_repeat</emphasis>
<structfield>per_key_repeat</structfield>
field mirrors the
<emphasis>auto_repeats</emphasis>
<structfield>auto_repeats</structfield>
field of the core protocol
<structname>XKeyboardState</structname>
structure: changing the
<emphasis>auto_repeats</emphasis>
<structfield>auto_repeats</structfield>
field automatically changes
<emphasis>per_key_repeat</emphasis>
<structfield>per_key_repeat</structfield>
and vice versa. It is provided for convenience and to reduce protocol traffic.
For example, to obtain the individual repeat key behavior as well as the repeat
delay and rate, use
<function>XkbGetControls</function>.
If the
<emphasis>per_key_repeat</emphasis>
<structfield>per_key_repeat</structfield>
were not in this structure, you would have to call both
<function>XGetKeyboardControl</function>
and
<function>XkbGetControls</function>
to get this information. The bits correspond to keycodes. The first seven keys
(keycodes 1-7) are indicated in
<emphasis>per_key_repeat</emphasis>
[0], with bit position 0 (low order) corresponding to the fictitious keycode 0.
<structfield>per_key_repeat</structfield>[0],
with bit position 0 (low order) corresponding to the fictitious keycode 0.
Following array elements correspond to 8 keycodes per element. A 1 bit
indicates that the key is a repeating key.
</para>
@ -4557,7 +4557,7 @@ the corresponding values are still updated in the X server. For example, the
fields are ignored unless the
<emphasis>RepeatKeys</emphasis>
control is enabled (that is, the X server’s equivalent of
<emphasis>xkb-&gt;ctrls</emphasis>
<structfield>xkb-&gt;ctrls</structfield>
has
<symbol>XkbRepeatKeysMask</symbol>
set in
@ -4680,7 +4680,7 @@ match those in the changed keyboard description.
</term>
<listitem>
<para>
keyboard description with changed <emphasis>xkb-&gt;ctrls</emphasis>
keyboard description with changed <structfield>xkb-&gt;ctrls</structfield>
</para>
</listitem>
</varlistentry>
@ -4690,7 +4690,7 @@ match those in the changed keyboard description.
</term>
<listitem>
<para>
which parts of <emphasis>xkb-&gt;ctrls</emphasis> have changed
which parts of <structfield>xkb-&gt;ctrls</structfield> have changed
</para>
</listitem>
</varlistentry>
@ -4965,7 +4965,7 @@ noted by one or more calls to
</term>
<listitem>
<para>
<emphasis>xkb-&gt;ctrls</emphasis> will be updated
<structfield>xkb-&gt;ctrls</structfield> will be updated
</para>
</listitem>
</varlistentry>
@ -4975,7 +4975,7 @@ noted by one or more calls to
</term>
<listitem>
<para>
indicates which parts of <emphasis>xkb-&gt;ctrls</emphasis> to update
indicates which parts of <structfield>xkb-&gt;ctrls</structfield> to update
</para>
</listitem>
</varlistentry>

28
specs/XKB/ch13.xml
View file

@ -137,7 +137,7 @@ override those defined in the keycodes component of the server database, which
are stored in the
<structname>XkbNamesRec</structname>
(
<emphasis>xkb-&gt;names</emphasis>
<structfield>xkb-&gt;names</structfield>
). Therefore, consider the key aliases defined by the geometry before
considering key aliases supplied by the keycodes.</para></note>
</listitem>
@ -1002,12 +1002,12 @@ relative to the keyboard’s origin if the doodad is in the
and
<structfield>off_color_ndx</structfield>
fields are color indices into the
<structname>XkbGeometryRec</structname>
’s color array and are the colors to draw the doodads with. Similarly, the
<structname>XkbGeometryRec</structname>’s
color array and are the colors to draw the doodads with. Similarly, the
<structfield>shape_ndx</structfield>
fields are indices into the
<structname>XkbGeometryRec</structname>
’s shape array.
<structname>XkbGeometryRec</structname>’s
shape array.
</para>
<para><programlisting>
@ -1559,12 +1559,10 @@ to look up the alternate name, which it returns.
<para>
Xkb provides functions to add a single new element to the top-level keyboard
geometry. In each case the
<emphasis>num_</emphasis>
<emphasis>*</emphasis>
<structfield>num_<replaceable>*</replaceable></structfield>
fields of the corresponding structure is incremented by 1. These functions do
not change
<emphasis>sz_</emphasis>
<emphasis>*</emphasis>
<structfield>sz_<replaceable>*</replaceable></structfield>
unless there is no more room in the array. Some of these functions fill in the
values of the element’s structure from the arguments. For other functions,
you must explicitly write code to fill the structure’s elements.
@ -2455,17 +2453,13 @@ keyboard geometry. Use these functions to create or modify keyboard geometries.
Note that these functions merely allocate space for the new element(s), and it
is up to you to fill in the values explicitly in your code. These allocation
functions increase
<emphasis>sz_</emphasis>
<emphasis>*</emphasis>
<structfield>sz_<replaceable>*</replaceable></structfield>
but never touch
<emphasis>num_</emphasis>
<emphasis>*</emphasis>
<structfield>num_<replaceable>*</replaceable></structfield>
(unless there is an allocation failure, in which case they reset both
<emphasis>sz_</emphasis>
<emphasis>*</emphasis>
<structfield>sz_<replaceable>*</replaceable></structfield>
and
<emphasis>num_</emphasis>
<emphasis>*</emphasis>
<structfield>num_<replaceable>*</replaceable></structfield>
to zero). These functions return
<symbol>Success</symbol>
if they succeed,

64
specs/XKB/ch14.xml
View file

@ -789,83 +789,83 @@ server and are always updated by the server whenever it returns the data for an
<row>
<entry><symbol>XkbKeyTypesMask</symbol></entry>
<entry>
<para>first_type</para>,
<para>num_types</para>
<structfield>first_type</structfield>,
<structfield>num_types</structfield>
</entry>
<entry>
<para>map-&gt;type[first_type] ..</para>
<para>map-&gt;type[first_type + num_types - 1]</para>
<structfield>map-&gt;type[first_type]</structfield> ..
<structfield>map-&gt;type[first_type + num_types - 1]</structfield>
</entry>
</row>
<row>
<entry><symbol>XkbKeySymsMask</symbol></entry>
<entry>
<para>first_key_sym</para>,
<para>num_key_syms</para>
<structfield>first_key_sym</structfield>,
<structfield>num_key_syms</structfield>
</entry>
<entry>
<para>map-&gt;key_sym_map[first_key_sym] ..</para>
<para>map-&gt;key_sym_map[first_key_sym + num_key_syms - 1]</para>
<structfield>map-&gt;key_sym_map[first_key_sym]</structfield> ..
<structfield>map-&gt;key_sym_map[first_key_sym + num_key_syms - 1]</structfield>
</entry>
</row>
<row>
<entry><symbol>XkbModifierMapMask</symbol></entry>
<entry>
<para>first_modmap_key</para>,
<para>num_modmap_keys</para>
<structfield>first_modmap_key</structfield>,
<structfield>num_modmap_keys</structfield>
</entry>
<entry>
<para>map-&gt;modmap[first_modmap_key] ..</para>
<para>map-&gt;modmap[first_modmap_key + num_modmap_keys-1]</para>
<structfield>map-&gt;modmap[first_modmap_key]</structfield> ..
<structfield>map-&gt;modmap[first_modmap_key + num_modmap_keys-1]</structfield>
</entry>
</row>
<row>
<entry><symbol>XkbExplicitComponentsMask</symbol></entry>
<entry>
<para>first_key_explicit</para>,
<para>num_key_explicit</para>
<structfield>first_key_explicit</structfield>,
<structfield>num_key_explicit</structfield>
</entry>
<entry>
<para>server-&gt;explicit[first_key_explicit] ..</para>
<para>server-&gt;explicit[first_key_explicit + num_key_explicit - 1]</para>
<structfield>server-&gt;explicit[first_key_explicit]</structfield> ..
<structfield>server-&gt;explicit[first_key_explicit + num_key_explicit - 1]</structfield>
</entry>
</row>
<row>
<entry><symbol>XkbKeyActionsMask</symbol></entry>
<entry>
<para>first_key_act,</para>
<para>num_key_acts</para>
<structfield>first_key_act</structfield>,
<structfield>num_key_acts</structfield>
</entry>
<entry>
<para>server-&gt;key_acts[first_key_act] ..</para>
<para>server-&gt;key_acts[first_key_act + num_key_acts - 1]</para>
<structfield>server-&gt;key_acts[first_key_act]</structfield> ..
<structfield>server-&gt;key_acts[first_key_act + num_key_acts - 1]</structfield>
</entry>
</row>
<row>
<entry><symbol>XkbKeyBehaviorsMask</symbol></entry>
<entry>
<para>first_key_behavior,</para>
<para>num_key_behaviors</para>
<structfield>first_key_behavior</structfield>,
<structfield>num_key_behaviors</structfield>
</entry>
<entry>
<para>server-&gt;behaviors[first_key_behavior] ..</para>
<para>server-&gt;behaviors[first_key_behavior + num_key_behaviors - 1]</para>
<structfield>server-&gt;behaviors[first_key_behavior]</structfield> ..
<structfield>server-&gt;behaviors[first_key_behavior + num_key_behaviors - 1]</structfield>
</entry>
</row>
<row>
<entry><symbol>XkbVirtualModsMask</symbol></entry>
<entry>vmods</entry>
<entry>server-&gt;vmods[*]</entry>
<entry><structfield>vmods</structfield></entry>
<entry><structfield>server-&gt;vmods[*]</structfield></entry>
</row>
<row>
<entry><symbol>XkbVirtualModMapMask</symbol></entry>
<entry>
<para>first_vmodmap_key,</para>
<para>num_vmodmap_keys</para>
<structfield>first_vmodmap_key</structfield>,
<structfield>num_vmodmap_keys</structfield>
</entry>
<entry>
<para>server-&gt;vmodmap[first_vmodmap_key] ..</para>
<para>server-&gt;vmodmap[first_vmodmap_key + num_vmodmap_keys - 1]</para>
<structfield>server-&gt;vmodmap[first_vmodmap_key]</structfield> ..
<structfield>server-&gt;vmodmap[first_vmodmap_key + num_vmodmap_keys - 1]</structfield>
</entry>
</row>
</tbody>
@ -1046,7 +1046,7 @@ typedef struct {
int num_key_explicit; /* # <structfield>explicit</structfield> entries changed */
int num_modmap_keys; /* # <structfield>modmap</structfield> entries changed */
int num_vmodmap_keys; /* # <structfield>vmodmap</structfield> entries changed */
unsigned in t vmods; /* mask indicating which <structfield>vmods</structfield> changed */
unsigned int vmods; /* mask indicating which <structfield>vmods</structfield> changed */
} <structname>XkbMapNotifyEvent</structname>;
</programlisting></para>
@ -1061,7 +1061,7 @@ event are interpreted as the like-named fields in an
(see <link linkend="The_XkbMapChangesRec_Structure">section 14.3.1</link>). The
<structname>XkbMapNotifyEvent</structname>
structure also has an additional
<emphasis>resized</emphasis>
<structfield>resized</structfield>
field that is reserved for future use.
</para>

16
specs/XKB/ch15.xml
View file

@ -819,7 +819,7 @@ refer to the
<function>XkbGetKeyTypes</function>
queries the server for the desired types, waits for a reply, and returns the
desired types in the
<emphasis>xkb-&gt;map-&gt;types</emphasis>.
<structfield>xkb-&gt;map-&gt;types</structfield>.
If successful, it returns Success.
</para>
@ -925,7 +925,7 @@ To change the number of levels in a key type, use
changes the type specified by
<parameter>xkb</parameter>
-&gt;
<emphasis>map-&gt;types</emphasis>
<structfield>map-&gt;types</structfield>
[
<parameter>type_ndx</parameter>
], and reallocates the symbols and actions bound to all keys that use the type,
@ -1278,7 +1278,7 @@ These fields are described in detail in the following sections.
<para>
The
<emphasis>kt_index</emphasis>
<structfield>kt_index</structfield>
array of the
<structname>XkbSymMapRec</structname>
structure contains the indices of the key types (see <link linkend="Key_Types">section 15.2</link>) for each
@ -2094,7 +2094,7 @@ To obtain the symbols for a subset of the keys in a keyboard description, use
keys starting with the key whose keycode is
<parameter>first</parameter>.
It waits for a reply and returns the keysyms in the
<emphasis>map.syms</emphasis>
<structfield>map.syms</structfield>
field of
<parameter>xkb</parameter>.
If successful,
@ -2247,7 +2247,7 @@ as appropriate. If the
adds the
<symbol>XkbKeySymsMask</symbol>
to the
<emphasis>changes</emphasis>
<structfield>changes</structfield>
field of
<parameter>p_changes</parameter>
and modifies the
@ -2291,7 +2291,7 @@ Each entry represents the type to use for the associated group and is an
index into
<parameter>xkb</parameter>
-&gt;
<emphasis>map-&gt;types</emphasis>.
<structfield>map-&gt;types</structfield>.
The
<parameter>new_types_in</parameter>
array is indexed by group index; if
@ -2457,9 +2457,7 @@ keysyms. It adjusts the
and
<structfield>size_syms</structfield>
fields of
<parameter>xkb</parameter>
-
<emphasis>&gt;map</emphasis>
<structfield>xkb-&gt;map</structfield>
if it is necessary to reallocate the
<structfield>syms</structfield>
array.

59
specs/XKB/ch16.xml
View file

@ -130,15 +130,15 @@ the entry represents an index into the
The reason the
<structfield>acts</structfield>
field is a linear list of
<structname>XkbAction</structname>
s is to reduce the memory consumption associated with a keymap. Because Xkb
<structname>XkbAction</structname>s
is to reduce the memory consumption associated with a keymap. Because Xkb
allows individual keys to have multiple shift levels and a different number of
groups per key, a single two-dimensional array of
<emphasis>KeySyms</emphasis>
would potentially be very large and sparse. Instead, Xkb provides a small
two-dimensional array of
<structname>XkbAction</structname>
s for each key. To store all of these individual arrays, Xkb concatenates each
<structname>XkbAction</structname>s
for each key. To store all of these individual arrays, Xkb concatenates each
array together in the
<structfield>acts</structfield>
field of the server map.
@ -588,7 +588,7 @@ have an associated data structure.
</row>
<row>
<entry><symbol>XkbSA_ActionMessage</symbol></entry>
<entry><emphasis>XkbMessgeAction</emphasis></entry>
<entry><structname>XkbMessageAction</structname></entry>
<entry>msg</entry>
<entry>16.1.11</entry>
</row>
@ -810,9 +810,9 @@ modifier mapping of the key. Otherwise, the action modifiers are set to the
modifiers specified by the
<structfield>mask</structfield>,
<structfield>real_mods</structfield>,
<emphasis>vmod1</emphasis>,
<structfield>vmods1</structfield>,
and
<emphasis>vmod2</emphasis>
<structfield>vmods2</structfield>
fields.
</entry>
</row>
@ -1751,8 +1751,7 @@ The
<link linkend="table16.8">Table 16.8</link>.
A general meaning is given in the table, but the exact meaning depends on
the action
<structfield>type</structfield>.
:
<structfield>type</structfield>:
</para>
<table id='table16.8' frame='topbot'>
@ -2245,9 +2244,9 @@ modifier mapping of the key. Otherwise, the action modifiers are set to the
modifiers specified by the
<structfield>mask</structfield>,
<structfield>real_mods</structfield>,
<emphasis>vmod1</emphasis>,
<structfield>vmods1</structfield>,
and
<emphasis>vmod2</emphasis>
<structfield>vmods2</structfield>
fields.
</entry>
</row>
@ -2440,7 +2439,7 @@ If
<para>
Actions associated with the
<emphasis>XkbSwitchScreen</emphasis>
<structname>XkbSwitchScreenAction</structname>
action structure change the active screen on a multiscreen display:
</para>
@ -3062,8 +3061,8 @@ The
is
<symbol>False</symbol>
) event is also sent to the client. As with all other Xkb events,
<structname>XkbActionMessageEvent</structname>
s are delivered to all clients requesting them, regardless of the current
<structname>XkbActionMessageEvent</structname>s
are delivered to all clients requesting them, regardless of the current
keyboard focus. However, the
<symbol>KeyPress</symbol>
or
@ -3587,7 +3586,7 @@ The low four bits of
and
<structfield>v2_what</structfield>
specify the corresponding scale value (denoted
<emphasis>val&lt;n&gt;Scale</emphasis>
<structfield>val&lt;n&gt;Scale</structfield>
in <link linkend="table16.17">Table 16.17</link>), if needed.
The high four bits of
<structfield>v1_what</structfield>
@ -3599,7 +3598,7 @@ The low four bits of
<structfield>v2_what</structfield>
can have the values shown in <link linkend="table16.17">Table 16.17</link>;
the use of
<emphasis>val&lt;n&gt;Scale</emphasis>
<structfield>val&lt;n&gt;Scale</structfield>
is shown in that table also.
</para>
@ -3623,34 +3622,34 @@ The low four bits of
<row>
<entry><symbol>XkbSA_SetValMin</symbol></entry>
<entry>
<emphasis>v&lt;n&gt;_value</emphasis> is set to its minimum legal value.
<structfield>v&lt;n&gt;_value</structfield> is set to its minimum legal value.
</entry>
</row>
<row>
<entry><symbol>XkbSA_SetValCenter</symbol></entry>
<entry>
<emphasis>v&lt;n&gt;_value</emphasis>is centered (to (max-min)/2).
<structfield>v&lt;n&gt;_value</structfield>is centered (to (max-min)/2).
</entry>
</row>
<row>
<entry><symbol>XkbSA_SetValMax</symbol></entry>
<entry>
<emphasis>v&lt;n&gt;_value</emphasis> is set to its maximum legal value.
<structfield>v&lt;n&gt;_value</structfield> is set to its maximum legal value.
</entry>
</row>
<row>
<entry><symbol>XkbSA_SetValRelative</symbol></entry>
<entry>
<emphasis>v&lt;n&gt;_value</emphasis> * (2
<emphasis>val&lt;n&gt;Scale</emphasis>) is added to
<emphasis>v&lt;n&gt;_value</emphasis>.
<structfield>v&lt;n&gt;_value</structfield> * (2
<structfield>val&lt;n&gt;Scale</structfield>) is added to
<structfield>v&lt;n&gt;_value</structfield>.
</entry>
</row>
<row>
<entry><symbol>XkbSA_SetValAbsolute</symbol></entry>
<entry>
<emphasis>v&lt;n&gt;_value</emphasis>
is set to (2 <emphasis>val&lt;n&gt;Scale</emphasis>).
<structfield>v&lt;n&gt;_value</structfield>
is set to (2 <structfield>val&lt;n&gt;Scale</structfield>).
</entry>
</row>
</tbody>
@ -3978,7 +3977,7 @@ Keys that belong to the same radio group have the
structure. If the radio group has a name in the
<structname>XkbNamesRec</structname>
structure, the radio group index is the index into the
<emphasis>radio_group</emphasis>
<structfield>radio_group</structfield>
array in the
<structname>XkbNamesRec</structname>
structure. A radio group key when pressed stays logically down until another
@ -4106,8 +4105,8 @@ If the
<structfield>data</structfield>
is interpreted as a keycode, and events from this key are reported as if they
came from
<structfield>data</structfield>
’s keycode. Otherwise, press and release events are processed normally.
<structfield>data</structfield>’s
keycode. Otherwise, press and release events are processed normally.
</entry>
</row>
<row>
@ -4119,8 +4118,8 @@ If the
<structfield>data</structfield>
is interpreted as a keycode, and events from this key are reported as if they
came from
<structfield>data</structfield>
’s keycode. Otherwise, press and release events are processed normally.
<structfield>data</structfield>’s
keycode. Otherwise, press and release events are processed normally.
</entry>
</row>
</tbody>
@ -4667,7 +4666,7 @@ the virtual modifier mask. For each bit set in
<parameter>which</parameter>,
<function>XkbGetVirtualMods</function>
updates the corresponding virtual modifier definition in the
<emphasis>server-&gt;vmods</emphasis>
<structfield>server-&gt;vmods</structfield>
array of
<parameter>xkb</parameter>.
The

12
specs/XKB/ch17.xml
View file

@ -132,7 +132,7 @@ subsequent transformations have a particular result.
All configurable aspects of mapping Xkb state and configuration to and from
core protocol state and configuration are defined by a compatibility map,
contained in an
<emphasis>XkbCompatMap</emphasis>
<structname>XkbCompatMapRec</structname>
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
@ -146,7 +146,7 @@ The
member of an Xkb keyboard description (
<structname>XkbDescRec</structname>
) points to the
<emphasis>XkbCompatMap</emphasis>
<structname>XkbCompatMapRec</structname>
structure:
</para>
@ -1623,7 +1623,7 @@ server using
and
<structfield>num_total_si</structfield>
are appropriate for use with the
<emphasis>compat.sym_interpret</emphasis>
<structfield>compat.sym_interpret</structfield>
vector in this structure.
</para>
@ -1708,7 +1708,7 @@ in <link linkend="Getting_Compatibility_Map_Components_From_the_Server">section
<parameter>num_si</parameter>
specifies the total number of entries to allocate in the symbol interpretation
vector (
<emphasis>xkb.compat.sym_interpret</emphasis>
<structfield>xkb.compat.sym_interpret</structfield>
).
</para>
@ -1793,7 +1793,7 @@ To free an entire compatibility map or selected portions of one, use
</term>
<listitem>
<para>
<symbol>True</symbol> =&gt; free <emphasis>XkbCompatMap</emphasis>
<symbol>True</symbol> =&gt; free <structname>XkbCompatMapRec</structname>
structure itself
</para>
</listitem>
@ -1814,7 +1814,7 @@ in <link linkend="Getting_Compatibility_Map_Components_From_the_Server">section
<para>
<parameter>free_map</parameter>
indicates whether the
<emphasis>XkbCompatMap</emphasis>
<structname>XkbCompatMapRec</structname>
structure itself should be freed. If
<parameter>free_map</parameter>
is

8
specs/XKB/ch18.xml
View file

@ -181,9 +181,9 @@ total number of entries in the
array is held in
<structfield>num_key_aliases</structfield>.
For each real and alias key name pair, the
<emphasis>real</emphasis>
<structfield>real</structfield>
field refers to the a name in the keys array, and the
<emphasis>alias</emphasis>
<structfield>alias</structfield>
field refers to the alias for that key. Using the previous example, the
keyboard designer may use the name A31 in the keys array, but also define the
name LEFT as an alias for A31 in the
@ -196,7 +196,7 @@ name LEFT as an alias for A31 in the
database, which are stored in the
<structname>XkbNamesRec</structname>
(
<emphasis>xkb-&gt;names</emphasis>
<structfield>xkb-&gt;names</structfield>
). Therefore, consider the key aliases defined by the geometry before
considering key aliases supplied by the
<structname>XkbNamesRec</structname>.
@ -943,7 +943,7 @@ When your application receives a
</term>
<listitem>
<para>
<emphasis>XkbNameChanges</emphasis> structure to be updated
<structname>XkbNameChangesRec</structname> structure to be updated
</para>
</listitem>
</varlistentry>

18
specs/XKB/ch20.xml
View file

@ -97,7 +97,7 @@ There may be multiple entries for each of the component types. An entry may be
either
<emphasis>complete</emphasis>
or
<structfield>partial</structfield>.
<emphasis>partial</emphasis>.
Partial entries describe only a piece of the corresponding keyboard component
and are designed to be combined with other entries of the same type to form a
complete entry.
@ -109,7 +109,7 @@ common ASCII keyboard and some national layout. Such a partial map is not
useful on its own because it does not include those symbols that are the same
on both the ASCII and national layouts (such as function keys). On the other
hand, this partial map can be used to configure
<structfield>any</structfield>
<emphasis>any</emphasis>
ASCII keyboard to use a national layout.
</para>
@ -123,13 +123,11 @@ later definitions override earlier ones.
<title>Component Names</title>
<para>
Component names have the form "
<emphasis>class(member)</emphasis>
" where
<structfield>class</structfield>
Component names have the form “<replaceable>class(member)</replaceable>” where
<replaceable>class</replaceable>
describes a subset of the available components for a particular type and the
optional
<emphasis>member</emphasis>
<replaceable>member</replaceable>
identifies a specific component from that subset. For example, the name
"atlantis(acme)" for a symbols component might specify the symbols used for the
atlantis national keyboard layout by the vendor "acme." Each class has an
@ -142,9 +140,9 @@ interpretation of the class and member names used in component names.
<para>
The
<structfield>class</structfield>
<replaceable>class</replaceable>
and
<emphasis>member</emphasis>
<replaceable>member</replaceable>
names are both specified using characters from the Latin-1 character set. Xkb
implementations must accept all alphanumeric characters, minus (‘-’) and
underscore (‘_’) in class or member names, and must not accept parentheses,
@ -725,7 +723,7 @@ entire expression is invalid and is ignored.
<para>
For example, if
<emphasis>names-&gt;symbols</emphasis>
<structfield>names-&gt;symbols</structfield>
contained the expression "+de", it specifies that the default member of the
"de" class of symbols should be applied to the current keyboard mapping,
overriding any existing definitions (it could also be written "+de(default)").

30
specs/XKB/ch21.xml
View file

@ -134,9 +134,9 @@ keyboard feedback and the core indicator feedback may be obtained by calling
as the
<parameter>device_spec</parameter>
; the values will be returned in
<emphasis>dflt_kbd_id</emphasis>
<structfield>dflt_kbd_fb</structfield>
and
<emphasis>dflt_led_id</emphasis>.
<structfield>dflt_led_fb</structfield>.
</para>
@ -476,9 +476,9 @@ The
<structfield>supported</structfield>,
<structfield>unsupported</structfield>,
<structfield>has_own_state</structfield>,
<emphasis>dflt_kbd_fd</emphasis>,
<structfield>dflt_kbd_fb</structfield>,
and
<structfield>dflt_kbd_fb</structfield>.
<structfield>dflt_led_fb</structfield>.
Other fields are filled in as specified by
<parameter>which</parameter>.
</para>
@ -598,8 +598,8 @@ the
<parameter>device_spec</parameter>
field of the structure. Only the parts of the structure indicated in the
function description are updated. The
<emphasis>XkbDeviceInfo</emphasis>
Rec structure used in the function call can be obtained by calling
<structname>XkbDeviceInfoRec</structname>
structure used in the function call can be obtained by calling
XkbGetDeviceInfo or can be allocated by calling XkbAllocDeviceInfo
(see <link linkend="Allocating_Initializing_and_Freeing_the_XkbDeviceInfoRecStructure">section 21.3</link>).
</para>
@ -859,7 +859,9 @@ and
The fields of
<parameter>device_info</parameter>
that are filled in when this request succeeds are
<emphasis>name, type, supported</emphasis>,
<structfield>name</structfield>,
<structfield>type</structfield>,
<structfield>supported</structfield>,
and
<structfield>unsupported</structfield>,
and portions of the
@ -871,7 +873,7 @@ and portions of the
as indicated by the bits set in
<parameter>which</parameter>.
The
<emphasis>device_info-&gt;leds</emphasis>
<structfield>device_info-&gt;leds</structfield>
vector is allocated if necessary and
<structfield>sz_leds</structfield>
and
@ -1016,7 +1018,7 @@ To obtain an
<parameter>n_buttons</parameter>
is nonzero,
<parameter>n_buttons</parameter>
<emphasis>XkbActions</emphasis>
<structname>XkbAction</structname>s
are linked into the
<structname>XkbDeviceInfoRec</structname>
structure and initialized to zero. If sz_leds is nonzero,
@ -1147,7 +1149,7 @@ To initialize an
and
<parameter>led_id</parameter>
already exists in the
<emphasis>device_info-&gt;leds</emphasis>
<structfield>device_info-&gt;leds</structfield>
array. If it finds a matching entry, it returns a pointer to that entry.
Otherwise, it checks to be sure there is at least one empty entry in
<parameter>device_info</parameter>
@ -1537,8 +1539,8 @@ extension devices other than the core keyboard device. If the
is set in
<parameter>which</parameter>,
the actions for all buttons specified in device_info are set to the
<structname>XkbAction</structname>
s specified in
<structname>XkbAction</structname>s
specified in
<parameter>device_info</parameter>
-&gt;
<structfield>btn_acts</structfield>.
@ -1604,9 +1606,7 @@ feedback for the device in question, a
error results. If any of the values in
<parameter>device_info</parameter>
-&gt;
<structfield>leds</structfield>
<emphasis>-&gt;</emphasis>
<structfield>names</structfield>
<structfield>leds-&gt;names</structfield>
are not a valid Atom or
<symbol>None</symbol>,
a

5
specs/XKB/glossary.xml
View file

@ -580,7 +580,10 @@ keyboard bell. Some input devices may have more than one bell, identified by
<para>
There are five types of components stored in the X server database of keyboard
components. They correspond to the
<emphasis>symbols, geometry, keycodes, compat</emphasis>,
<structfield>>symbols</structfield>,
<structfield>geometry</structfield>,
<structfield>keycodes</structfield>,
<structfield>compat</structfield>,
and
<structfield>types</structfield>
symbolic names associated with a keyboard.