diff --git a/specs/ch02.xml b/specs/ch02.xml index e3558d1..ab7aa23 100644 --- a/specs/ch02.xml +++ b/specs/ch02.xml @@ -273,7 +273,7 @@ ServerInternalModifiers IgnoreLocksModifiers and IgnoreGroupLock - controls, described in See Server + controls, described in Server Internal Modifiers and Ignore Locks Behavior, to derive these two states as follows: @@ -355,7 +355,7 @@ The core protocol interpretation of keyboard modifiers does not include direct support for multiple groups, so XKB reports the effective keyboard group to XKB-aware clients using some of the reserved bits in the state field of some core protocol events, as described in -See Computing A State Field from an +Computing A State Field from an XKB State. @@ -363,7 +363,7 @@ XKB State. This modified state field would not be interpreted correctly by XKB-unaware clients, so XKB provides a group compatibility mapping -(see See Group Compatibility Map) which +(see Group Compatibility Map) which remaps the keyboard group into a core modifier mask that has similar effects, when possible. XKB maintains three compatibility state components that are used to make non-XKB clients work as well as possible: @@ -398,7 +398,7 @@ of the grab state. Compatibility states are essentially the corresponding XKB state, but with -keyboard group possibly encoded as one or more modifiers; See Group Compatibility Map describes +keyboard group possibly encoded as one or more modifiers; Group Compatibility Map describes the group compatibility map, which specifies the modifier(s) that correspond to each keyboard group. diff --git a/specs/ch03.xml b/specs/ch03.xml index 66b3353..e9ac99c 100644 --- a/specs/ch03.xml +++ b/specs/ch03.xml @@ -212,7 +212,7 @@ NumLock The virtual modifier mapping is normally updated automatically whenever actions -are assigned to keys (see See Changing +are assigned to keys (see Changing the Keyboard Mapping Using the Core Protocol for details) and few applications should need to change the virtual modifier mapping explicitly. diff --git a/specs/ch04.xml b/specs/ch04.xml index 631d1b0..ab1547a 100644 --- a/specs/ch04.xml +++ b/specs/ch04.xml @@ -99,7 +99,7 @@ whether or not it is supported. -See Querying and Changing Per-Client +Querying and Changing Per-Client Flags describes the XkbPerClientFlags request, which reports or changes values for all of the per-client flags, and @@ -148,7 +148,7 @@ rejection or release of any key to interested clients using AccessXNotify events. The AccessXNotify - event is described in more detail in See Events. + event is described in more detail in Events. @@ -183,7 +183,7 @@ interested clients by sending an AccessXNotify event. The AccessXNotify - event is described in more detail in See Events. + event is described in more detail in Events. @@ -375,7 +375,7 @@ When MouseKeys are active and a SA_MovePtr - key action (see See Key + key action (see Key Actions) is activated, a pointer motion event is generated immediately. If MouseKeysAccel @@ -515,11 +515,10 @@ StickyKeys Some of these key sequences optionally generate audible feedback of the change -in state, as described in See The +in state, as described in The AccessXFeedback Control, or cause XkbAccessXNotify - events as described in See -Events. + events as described in Events. @@ -779,7 +778,7 @@ should generate when that overlay is enabled, assign it either the KB_Overlay1 or KB_Overlay2 - key behaviors, as described in See + key behaviors, as described in Key Behavior. @@ -791,10 +790,10 @@ Key Behavior. All of the controls described above, along with the AudibleBell - control (described in See Disabling + control (described in Disabling Server Generated Bells) and the IgnoreGroupLock - control (described in See Server + control (described in Server Internal Modifiers and Ignore Locks Behavior) comprise the boolean controls . In addition to any parameters listed in the descriptions of the individual @@ -813,18 +812,18 @@ EnabledControls control or specified in any context that accepts only boolean controls: GroupsWrap - (See Computing Effective Modifier and + (Computing Effective Modifier and Group), EnabledControls , InternalMods - (See Server Internal Modifiers and + (Server Internal Modifiers and Ignore Locks Behavior), and IgnoreLockMods - (See Server Internal Modifiers and + (Server Internal Modifiers and Ignore Locks Behavior) and PerKeyRepeat - (See The RepeatKeys Control) + (The RepeatKeys Control) @@ -836,7 +835,7 @@ PerKeyRepeat The auto-reset controls are a per-client value which consist of two masks that can contain any of the -boolean controls (see See "Boolean" +boolean controls (see "Boolean" Controls and The EnabledControls Control). Whenever the client exits for any reason, any boolean controls specified in the auto-reset mask @@ -851,7 +850,7 @@ automatically, even if abnormally terminated. For example, a client that replace the keyboard bell with some other audible cue might want to turn off the AudibleBell - control (See Disabling Server + control (Disabling Server Generated Bells) to prevent the server from also generating a sound and thus avoid cacophony. If the client were to exit without resetting the diff --git a/specs/ch05.xml b/specs/ch05.xml index e712d56..fc9a185 100644 --- a/specs/ch05.xml +++ b/specs/ch05.xml @@ -19,7 +19,8 @@ elapsed while the RepeatKeys control can cause multiple X events from a single physical key press if the key is held down for an extended period. The global keyboard controls affect -all of the keys on the keyboard and are described in See Global Keyboard Controls. +all of the keys on the keyboard and are described in +Global Keyboard Controls. @@ -29,7 +30,8 @@ keyboard overlays, in which a key generates an alternate keycode under certain circumstances, can be implemented using per-key behavior. Every key has a single behavior, so the effect of key behavior does not depend on keyboard modifier or group state, though it might depend on global keyboard controls. -Per-key behaviors are described in detail in See Key Behavior. +Per-key behaviors are described in detail in +Key Behavior. @@ -37,7 +39,7 @@ Per-key behaviors are described in detail in See Ke keyboard has some action associated with it. The key action tells the server what to do when an event which yields the corresponding keysym is generated. Key actions might change or suppress the event, generate some other event, or -change some aspect of the server. Key actions are described in See Key Actions. +change some aspect of the server. Key actions are described in Key Actions. @@ -50,13 +52,13 @@ event, the client which receives the event processes it in several steps. First the client extracts the effective keyboard group and a set of -modifiers from the state field of the event. See See Computing A State Field from an XKB +modifiers from the state field of the event. See Computing A State Field from an XKB State for details. Using the modifiers and effective keyboard group, the client selects a -symbol from the list of keysyms bound to the key. See Determining the KeySym Associated with a +symbol from the list of keysyms bound to the key. Determining the KeySym Associated with a Key Event discusses symbol selection. @@ -66,7 +68,9 @@ using any modifiers that are "left over" from the process of looking up a symbol. For example, if the Lock modifier is left over, the resulting keysym is capitalized according to the -capitalization rules specified by the system. See See Transforming the KeySym Associated with a +capitalization rules specified by the system. See + +Transforming the KeySym Associated with a Key Event for a more detailed discussion of the transformations defined by XKB. diff --git a/specs/ch06.xml b/specs/ch06.xml index 6476750..6351760 100644 --- a/specs/ch06.xml +++ b/specs/ch06.xml @@ -262,7 +262,7 @@ list of symbols associated with the key (i.e. it has one action per symbol associated with the key). For key press events, the server looks up the action to be applied from this list using the key symbol mapping associated with the event key, just as a client looks up symbols as described in See Determining the KeySym Associated with a +linkend="determining_the_keysym_associated_with_a_key_event">Determining the KeySym Associated with a Key Event; if the event key does not have any actions, the server uses the SA_NoAction @@ -292,7 +292,7 @@ delay between the activation of one and the other. Most actions which affect keyboard modifier state accept a modifier definition -(see See Virtual Modifiers) +(see Virtual Modifiers) named mods and a boolean flag name @@ -679,7 +679,7 @@ MouseKeysAccel keyboard control is enabled, key press also initiates the mouse keys timer for this key; every time this timer expires, the cursor moves again. The distance the cursor moves in these subsequent events is determined by the mouse keys -acceleration as described in See The +acceleration as described in The MouseKeysAccel Control. @@ -1627,7 +1627,7 @@ event that caused them. Events sent to clients that have not issued an XkbUseExtension request contain a compatibility state in place of the actual XKB keyboard -state. See See Effects of XKB on Core +state. See Effects of XKB on Core Protocol Events for a description of this compatibility mapping. @@ -1647,7 +1647,7 @@ the following changes: A passive grab triggers if the modifier state specified in the grab matches the grab compatibility state (described in See Compatibility Components of Keyboard +linkend="compatibility_components_of_keyboard_state">Compatibility Components of Keyboard State). Clients can choose to use the XKB grab state instead by setting the GrabsUseXKBState @@ -1678,14 +1678,14 @@ LookupStateWhenGrabbed Otherwise, the state field of events that do not trigger a passive grab report is derived from the XKB effective modifiers and group, as described in -See Computing A State Field from an +Computing A State Field from an XKB State. If a key release event is the result of an autorepeating key that is being held down, and the client to which the event is reported has requested -detectable autorepeat (see See +detectable autorepeat (see Detectable Autorepeat), the event is not delivered to the client. @@ -1720,7 +1720,7 @@ interact. The largest problems arise from the fact that an XKB state field encodes an explicit keyboard group in bits 13-14 (as described in See Computing A State Field from an XKB +linkend="computing_a_state_field_from_an_xkb_state">Computing A State Field from an XKB State), while pre-XKB clients use one of the eight keyboard modifiers to select an alternate keyboard group. To make existing clients behave reasonably, XKB normally uses the compatibility grab state instead of the XKB diff --git a/specs/ch07.xml b/specs/ch07.xml index 500357f..700f28f 100644 --- a/specs/ch07.xml +++ b/specs/ch07.xml @@ -7,7 +7,7 @@ client map for a keyboard is the collection of information a client needs to interpret key events that come from that keyboard. It contains a global list of key types -, described in See Key Types, +, described in Key Types, and an array of key symbol map s, each of which describes the symbols bound to one particular key and the @@ -19,7 +19,7 @@ rules to be used to interpret those symbols. XKB associates a two-dimensional array of symbols with each key. Symbols are -addressed by keyboard group (see See +addressed by keyboard group (see Keyboard State) and shift level, where level is defined as in the ISO9995 standard: @@ -86,13 +86,13 @@ group and shift level that correspond to the event. Group is reported in bits 13-14 of the state field of the key event, as -described in See Computing A State +described in Computing A State Field from an XKB State. The keyboard group reported in the event might be out-of-range for any particular key because the number of groups can vary from key to key. The XKB description of each key contains a group info field which is interpreted identically to the global groups wrap control (see -See Computing Effective Modifier and +Computing Effective Modifier and Group) and which specifies the interpretation of groups that are out-of-range for that key. @@ -104,7 +104,7 @@ determine the shift level. The description of a key includes a key type for each group of symbols bound to the key. Given the modifiers from the key event, this key type yields a shift level and a set of "leftover" modifiers, as -described in See Key Types +described in Key Types below. @@ -125,7 +125,7 @@ map field specifies the shift level that corresponds to some XKB modifier definition; any combination of modifiers that is not explicitly listed somewhere in the map yields shift level one. Map entries which specify unbound -virtual modifiers (see See Inactive +virtual modifiers (see Inactive Modifier Definitions) are not considered; each entry contains an automatically-updated active @@ -161,7 +161,7 @@ Any modifiers specified in modifiers are normally consumed - (see See Transforming the KeySym + (see Transforming the KeySym Associated with a Key Event), which means that they are not considered during any of the later stages of event processing. For those rare occasions that a modifier @@ -427,7 +427,9 @@ Control Report the control character associated with the symbol. This extension defines the control characters associated with the ASCII alphabetic characters (both upper and lower case) and for a small set of punctuation -characters (see Default Symbol Transformations). Applications are +characters (see +Default Symbol Transformations). +Applications are free to associate control characters with any symbols that are not specified by this extension. @@ -449,11 +451,9 @@ Interpretation of other modifiers is application dependent. This definition of capitalization is fundamentally different from the core protocol’s, which uses the lock modifier to select from the symbols -bound to the key. Consider key 9 in the example keyboard on See Consider a simple, if -unlikely, keyboard with the following keys (gray characters indicate symbols -that are implied or expected but are not actually engraved on the -key):; the core protocol provides no way to generate the capital form +bound to the key. Consider key 9 in the +client map example; +the core protocol provides no way to generate the capital form of either symbol bound to this key. XKB specifies that we first look up the symbol and then capitalize, so XKB yields the capital form of the two symbols when caps lock is active. @@ -677,7 +677,7 @@ to be used. The key type determines which symbol is chosen from the list. -See Determining the KeySym Associated +Determining the KeySym Associated with a Key Event details the procedure to map from a key event to a symbol and/or a string. diff --git a/specs/ch08.xml b/specs/ch08.xml index 2dd04a9..cbf4b78 100644 --- a/specs/ch08.xml +++ b/specs/ch08.xml @@ -86,7 +86,9 @@ symbols geometry names typically correspond to the keyboard components from which the current keyboard description was assembled. These components are stored individually in -the server’s database of keyboard components, described in See The Server Database of Keyboard +the server’s database of keyboard components, described in + +The Server Database of Keyboard Components, and can be combined to assemble a complete keyboard description. @@ -130,7 +132,7 @@ customizations are straightforward. Key aliases can be specified both in the symbolic names component and in the -keyboard geometry (see See Keyboard +keyboard geometry (see Keyboard Geometry). Both sets of aliases are always valid, but key alias definitions in the keyboard geometry have priority; if both symbolic names and geometry include aliases, applications should consider the definitions from the diff --git a/specs/ch09.xml b/specs/ch09.xml index c78eba9..8a0eb87 100644 --- a/specs/ch09.xml +++ b/specs/ch09.xml @@ -60,7 +60,7 @@ keyboard, it cannot be directly changed under program control. It is possible, however, for the set of physical indicators to be change if a new keyboard is attached or if a completely new keyboard description is loaded by the XkbGetKeyboardByName - request (see See Using the Server’s + request (see Using the Server’s Database of Keyboard Components). @@ -88,7 +88,7 @@ XkbGetNames request reports the symbolic names for all keyboard components, including the indicators. Use the XkbSetNames - request to change symbolic names. Both requests are described in See Querying and Changing Symbolic + request to change symbolic names. Both requests are described in Querying and Changing Symbolic Names. @@ -232,7 +232,7 @@ mods fields of an indicator map determine how the state of the keyboard modifiers affect the corresponding indicator. The mods - field is an XKB modifier definition, as described in See Modifier Definitions, which can + field is an XKB modifier definition, as described in Modifier Definitions, which can specify both real and virtual modifiers. The mods field takes effect even if some or all of the virtual indicators specified in mods @@ -305,7 +305,7 @@ IM_UseCompat The controls - field specifies a subset of the boolean keyboard controls (see See "Boolean" Controls and The + field specifies a subset of the boolean keyboard controls (see "Boolean" Controls and The EnabledControls Control). The indicator is lit whenever any of the boolean controls specified in controls diff --git a/specs/ch10.xml b/specs/ch10.xml index c20622b..bfb99ae 100644 --- a/specs/ch10.xml +++ b/specs/ch10.xml @@ -110,7 +110,7 @@ sounds other than simple tones, but it is not required to do so. Aside from those used by the XKB AccessXFeedback - control (see See The AccessXFeedback + control (see The AccessXFeedback Control), this extension does not specify bell names or their interpretation. diff --git a/specs/ch11.xml b/specs/ch11.xml index 1be90dd..9a32496 100644 --- a/specs/ch11.xml +++ b/specs/ch11.xml @@ -79,7 +79,7 @@ structures refer to geometry properties. A list of key aliases -, as described in See Symbolic +, as described in Symbolic Names. @@ -89,7 +89,7 @@ shapes ; other keyboard components refer to shapes by their index in this list. A shape consists of a name and one or more closed-polygons called outlines -. Shapes and outlines are described in detail in See Shapes and Outlines. +. Shapes and outlines are described in detail in Shapes and Outlines. diff --git a/specs/ch12.xml b/specs/ch12.xml index cd21a48..d30a213 100644 --- a/specs/ch12.xml +++ b/specs/ch12.xml @@ -53,7 +53,7 @@ of a keyboard mapping and XKB and explains the ways they can interact. Group Compatibility Map -As described in See Keyboard +As described in Keyboard State, the current keyboard group is reported to XKB-aware clients in bits 13-14 of the state field of many core protocol events. XKB-unaware clients cannot interpret those bits, but they might use a keyboard modifier to @@ -243,40 +243,40 @@ field for a key can contain any combination of the following values: ExplicitKeyType1 Automatic determination of the key type associated with Group1 - (see See Assigning Types To Groups of + (see Assigning Types To Groups of Symbols for a Key) ExplicitKeyType2 Automatic determination of the key type associated with Group2 -(see See Assigning Types To Groups of +(see Assigning Types To Groups of Symbols for a Key) ExplicitKeyType3 Automatic determination of the key type associated with Group3 -(see See Assigning Types To Groups of +(see Assigning Types To Groups of Symbols for a Key). ExplicitKeyType4 Automatic determination of the key type associated with Group4 -(see See Assigning Types To Groups of +(see Assigning Types To Groups of Symbols for a Key). ExplicitInterpret Application of any of the fields of a symbol interpretation to the -key in question (see See Assigning +key in question (see Assigning Actions To Keys). ExplicitAutoRepeat Automatic determination of autorepeat status for the key, as -specified in a symbol interpretation (see See Assigning Actions To +specified in a symbol interpretation (see Assigning Actions To Keys). @@ -285,14 +285,14 @@ Keys). KB_Lock behavior to the key, if the LockingKey - flag is set in a symbol interpretation (see See Assigning Actions To + flag is set in a symbol interpretation (see Assigning Actions To Keys). ExplicitVModMap Automatic determination of the virtual modifier map for the key based on the actions assigned to the key and the symbol interpretations which -match the key (see See Assigning +match the key (see Assigning Actions To Keys). @@ -310,7 +310,7 @@ ChangeKeyboardMapping groups that are defined for the key and the width of each group. The XKB extension does not change key types in response to core protocol SetModifierMapping - requests, but it does choose key actions as described in See Assigning Actions To Keys. + requests, but it does choose key actions as described in Assigning Actions To Keys. @@ -487,7 +487,7 @@ ALPHABETIC Describes alphabetic keys that have exactly two symbols per group. The default definition of the ALPHABETIC - type provides shift-cancels-caps behavior as described in See Key Types. Index + type provides shift-cancels-caps behavior as described in Key Types. Index 2 in any key symbol map specifies key type ALPHABETIC @@ -733,7 +733,7 @@ locking key field is set in the symbol interpretation, the behavior of the key is changed to KB_Lock - (see See Key Behavior). The + (see Key Behavior). The ExplicitBehavior component prevents this change. @@ -787,7 +787,7 @@ indicator maps, internal modifiers or ignore locks modifiers. After applying server actions which modify the base, latched or locked modifier or group state of the keyboard, the X server recomputes the effective group and state. Several components of the keyboard state are reported to XKB-aware -clients depending on context (see See +clients depending on context (see Keyboard State for a detailed description of each of the keyboard state components): @@ -963,7 +963,7 @@ by all of the actions associated with the key plus all of the modifiers associated with any virtual modifiers bound to the key by the virtual modifier mapping. If any of the actions associated with a key affect any component of the keyboard group, any modifiers specified in any entry of the group -compatibility map (see See Group +compatibility map (see Group Compatibility Map) are reported in the modifier mask. The SA_ISOLock action can theoretically affect any modifier, but the modifier map of an diff --git a/specs/ch13.xml b/specs/ch13.xml index f00a467..9efa7b2 100644 --- a/specs/ch13.xml +++ b/specs/ch13.xml @@ -275,7 +275,8 @@ types component of a keyboard mapping specifies the key types that can be associated with the various keyboard keys. It affects the types - symbolic name and the list of types associated with the keyboard (see See Key Types). The types component + symbolic name and the list of types associated with the keyboard (see +Key Types). The types component of a keyboard mapping can also optionally contain real modifier bindings and symbolic names for one or more virtual modifiers. diff --git a/specs/ch14.xml b/specs/ch14.xml index fcf127a..2da16db 100644 --- a/specs/ch14.xml +++ b/specs/ch14.xml @@ -9,7 +9,7 @@ keycodes. The server can generate an XkbNewKeyboardNotify event when it detects a new keyboard, or in response to an XkbGetKeyboardByName - request (see See Using the Server’s + request (see Using the Server’s Database of Keyboard Components) which loads a new keyboard description. diff --git a/specs/ch15.xml b/specs/ch15.xml index 7cca36a..6c56ad6 100644 --- a/specs/ch15.xml +++ b/specs/ch15.xml @@ -113,7 +113,7 @@ Keyboard The XKB extension optionally allows clients to assign any key action (see -See Key Actions) to core +Key Actions) to core pointer or input extension device buttons. This makes it possible to control the keyboard or generate keyboard key events from extension devices or from the core pointer. diff --git a/specs/ch16.xml b/specs/ch16.xml index aeaec30..643ebce 100644 --- a/specs/ch16.xml +++ b/specs/ch16.xml @@ -1215,7 +1215,7 @@ affectWhich If any components are specified in a client’s event masks, the X server sends the client an appropriate event whenever any of those components change state. -Unless explicitly modified, all event detail masks are empty. See Events describes all XKB events +Unless explicitly modified, all event detail masks are empty. Events describes all XKB events and the conditions under which the server generates them. @@ -1532,7 +1532,7 @@ effective modifiers minus any server internal modifiers. The grabMods return value reports the grab modifiers, which consist of the lookup modifiers minus any members of the ignore locks mask that are not either latched or -logically depressed. See Keyboard +logically depressed. Keyboard State describes the lookup modifiers and grab modifiers in more detail. @@ -1556,7 +1556,7 @@ compatGrabMods return values report the core protocol compatibility states that correspond to the XKB lookup and grab state. All of the compatibility states are computed by applying the group compatibility mapping to the corresponding XKB modifier and -group states, as described in See +group states, as described in Group Compatibility Map. @@ -1821,13 +1821,14 @@ The numGroups return value reports the current number of groups, and groupsWrap - reports the treatment of out-of-range groups, as described in See Key Symbol Map. The + reports the treatment of out-of-range groups, as described in Key Symbol Map. The internalMods and ignoreLockMods return values report the current values of the server internal and ignore -locks modifiers as described in See -Keyboard State. Both are modifier definitions (See Modifier Definitions) which +locks modifiers as described in +Keyboard State. Both are modifier definitions ( +Modifier Definitions) which report the real modifiers, virtual modifiers, and the resulting combination of real modifiers that are bound to the corresponding control. @@ -1854,7 +1855,7 @@ mouseKeysMaxSpeed and mouseKeysCurve return values report the current acceleration applied to mouse keys, as -described in See The MouseKeysAccel +described in The MouseKeysAccel Control. All times are reported in milliseconds. @@ -2221,7 +2222,8 @@ If applied, repeatDelay and repeatInterval - change the autorepeat characteristics of the keyboard, as described in See The RepeatKeys Control. If + change the autorepeat characteristics of the keyboard, as described in +The RepeatKeys Control. If specified, repeatDelay and @@ -2237,7 +2239,7 @@ If applied, the slowKeysDelay field specifies a new delay for the SlowKeys - control, as defined in See The + control, as defined in The SlowKeys Control. If specified, slowKeysDelay must be non-zero, or a @@ -2251,7 +2253,7 @@ If applied, the debounceDelay field specifies a new delay for the BounceKeys - control, as described in See The + control, as described in The BounceKeys Control. If present, the debounceDelay must be non-zero or a @@ -2272,7 +2274,7 @@ SA_LockPtrBtn mouseKeysDfltBtn must specify a legal button for the core pointer device, or a Value - error results. See Key + error results. Key Actions describes the SA_PtrBtn and @@ -2295,7 +2297,7 @@ mouseKeysCurve fields change the rate at which the pointer moves when a key which generates a SA_MovePtr - action is held down. See The + action is held down. The MouseKeysAccel Control describes these MouseKeysAccel parameters in more detail. If defined, the @@ -2321,7 +2323,8 @@ Value If applied, the accessXOptions - field sets the AccessX options, which are described in detail in See The AccessXKeys Control. If + field sets the AccessX options, which are described in detail in +The AccessXKeys Control. If either one of XkbStickyKeysMask and @@ -2355,7 +2358,7 @@ accessXTimeoutOptionsMask and accessXTimeoutOptionsValues fields change the behavior of the AccessX Timeout control, as described in -See The AccessXTimeout +The AccessXTimeout Control. The accessXTimeout must be greater than zero, or a @@ -2383,7 +2386,7 @@ Match If present, the groupsWrap field specifies the treatment of out-of-range keyboard groups, as described in -See Key Symbol Map. If the +Key Symbol Map. If the groupsWrap field does not specify a legal treatment for out-of-range groups, a @@ -3323,7 +3326,7 @@ flags last key type specified by this request is the last element in the list. If the list of key types is shrunk, any existing key definitions that use key types that eliminated are automatically assigned key types from the list of canonical -key types as described in See +key types as described in Assigning Types To Groups of Symbols for a Key. The list of key types bound to a keyboard must always include the four canonical types and cannot have more than @@ -3736,7 +3739,8 @@ XkbSetMapRecomputeActions bit is set in flags , the actions associated with any keys for which symbol or modifier bindings -were changed by this request are recomputed as described in See Assigning Actions To Keys. Note +were changed by this request are recomputed as described in +Assigning Actions To Keys. Note that actions are recomputed after any actions specified in this request are bound to keys, so the actions @@ -4082,7 +4086,7 @@ recomputeActions True , the server regenerates recalculates the actions bound to all keyboard keys by applying the new symbol interpretations to the entire key symbol map, as -described in See Assigning Actions To +described in Assigning Actions To Keys. @@ -4239,7 +4243,7 @@ XkbIndicatorStateNotify The maps return value reports the requested indicator maps. Indicator maps are -described in See Indicator Maps +described in Indicator Maps @@ -4713,7 +4717,7 @@ If setMap is True -, XKB changes the map for the indicator (see See Indicator Maps) to reflect the +, XKB changes the map for the indicator (see Indicator Maps) to reflect the values specified in map . @@ -5522,7 +5526,7 @@ name is a valid atom other than None , the server returns the keyboard geometry description with that name in the -server database of keyboard components (see See The Server Database of Keyboard +server database of keyboard components (see The Server Database of Keyboard Components) if one exists. If deviceSpec does not specify a valid keyboard device, a @@ -5562,7 +5566,7 @@ found True , the remaining fields of the reply describe the requested keyboard geometry. The interpretation of the components that make up a keyboard geometry is -described in detail in See Keyboard +described in detail in Keyboard Geometry @@ -5855,35 +5859,35 @@ per-client-flags are: XkbPCF_DetectableAutorepeat - See Detectable + Detectable Autorepeat XkbPCF_GrabsUseXKBStateMask - See Setting a Passive Grab + Setting a Passive Grab for an XKB State XkbPCF_AutoResetControlsMask - See Automatic Reset of + Automatic Reset of Boolean Controls XkbPCF_LookupStateWhenGrabbed - See Effects of XKB on Core + Effects of XKB on Core Protocol Events XkbPCF_SendEventUsesXKBState - See Sending Events to + Sending Events to Clients @@ -6109,7 +6113,7 @@ components. Each pattern uses the ISO Latin-1 encoding and should contain only parentheses, the wildcard characters "?" and "*" or characters that are permitted in a -component class or member name (see See Component Names). Illegal +component class or member name (see Component Names). Illegal characters in a pattern are simply ignored; no error results if a pattern contains illegal characters. @@ -6153,14 +6157,14 @@ compatMaps symbols and geometries - return the hints (see See Component + return the hints (see Component Hints) and names of any components from the server database that match the corresponding pattern. -See The Server Database of Keyboard +The Server Database of Keyboard Components describes the X server database of keyboard components in more detail. @@ -6300,7 +6304,7 @@ compatMapSpec symbolsSpec and geometrySpec - component expressions (see See + component expressions (see Partial Components and Combining Multiple Components) specify the database components to be used to assemble the keyboard description. @@ -6410,7 +6414,7 @@ If either field contains a GBN component that depends on some database component for which the request does not supply an expression, XKB automatically substitutes the special pattern "%" which copies the corresponding component from the current keyboard description, as described in -See Partial Components and Combining +Partial Components and Combining Multiple Components. @@ -6434,7 +6438,8 @@ If all necessary components are both specified and found, the new keyboard description is loaded. If the new keyboard description has a different geometry or keycode range than the previous keyboard description, XKB sends XkbNewKeyboardNotify - events to all interested clients. See See Replacing the Keyboard + events to all interested clients. See +Replacing the Keyboard "On-the-Fly" for more information about the effects of replacing the keyboard description on the fly. @@ -6885,7 +6890,9 @@ deviceID which values are being returned. The supported return value reports the set of optional XKB extension device features that -are supported by this implementation (see See Interactions Between XKB and the X Input +are supported by this implementation (see + +Interactions Between XKB and the X Input Extension) for the specified device, and the unsupported return value reports any unsupported @@ -7532,7 +7539,7 @@ Once a client receives a new keyboard notify event which reports a new keycode range, the X server reports events from all keys in the new range to that client. Clients that do not request or receive new keyboard notify events receive events only from keys that fall in the last range for legal keys -reported to that client. See See +reported to that client. See Replacing the Keyboard "On-the-Fly" for a more detailed explanation. @@ -7898,9 +7905,9 @@ requestMajor, requestMinor: CARD8 -An -XkbStateNotify - event reports that some component of the XKB state (see See Keyboard State) has changed. +An XkbStateNotify +event reports that some component of the XKB state (see +Keyboard State) has changed. State notify events are usually caused by key or pointer activity, but they can also result from explicit state changes requested by the XkbLatchLockState @@ -7914,7 +7921,8 @@ deviceID field reports the keyboard on which some state component changed. The changed - field reports the XKB state components (see See Keyboard State) that have changed + field reports the XKB state components (see +Keyboard State) that have changed and contain any combination of: @@ -8163,8 +8171,10 @@ requestMinor: CARD8 An XkbControlsNotify event reports a change in one or more of the global keyboard controls (see -See Global Keyboard Controls) -or in the internal modifiers or ignore locks masks (see See Server Internal Modifiers and Ignore +Global Keyboard Controls) +or in the internal modifiers or ignore locks masks (see + +Server Internal Modifiers and Ignore Locks Behavior). Controls notify events are usually caused by and XkbSetControls @@ -9167,8 +9177,9 @@ detail slowKeysDelay and debounceDelay - fields always reports the current slow keys acceptance delay (see See The SlowKeys Control) and -debounce delay (see See The BounceKeys + fields always reports the current slow keys acceptance delay (see +The SlowKeys Control) and +debounce delay (see The BounceKeys Control) for the specified keyboard. @@ -9333,7 +9344,7 @@ extension device feature that is not supported by the XKB implementation in the server for the specified device. The unsupported mask reports the requested features that are not available on the specified -device. See See Interactions Between +device. See Interactions Between XKB and the X Input Extension for more information about possible XKB interactions with the X Input Extension.