From cb49f95af605bd5019e194eeb656d8789d57756a Mon Sep 17 00:00:00 2001 From: Matt Dew Date: Mon, 3 Oct 2011 18:06:16 -0600 Subject: 1 - fix the capitolization of the ID attriutes to match either the or <funcdef> string it goes with. 2 - fix any <linkend>'s that were affected by 1. 3 - any <function> in the docs that has an actual funcdef, will become an olink. Signed-off-by: Matt Dew <marcoz@osource.org> --- specs/appA.xml | 26 +++++----- specs/appB.xml | 10 ++-- specs/appC.xml | 12 ++--- specs/appD.xml | 14 +++--- specs/ch01.xml | 4 +- specs/ch02.xml | 24 ++++----- specs/ch03.xml | 10 ++-- specs/ch04.xml | 64 ++++++++++++------------ specs/ch05.xml | 14 +++--- specs/ch06.xml | 28 +++++------ specs/ch07.xml | 32 ++++++------ specs/ch08.xml | 6 +-- specs/ch09.xml | 18 +++---- specs/ch10.xml | 14 +++--- specs/ch11.xml | 14 +++--- specs/ch12.xml | 54 ++++++++++----------- specs/ch13.xml | 24 ++++----- specs/ch14.xml | 4 +- specs/ch15.xml | 12 ++--- specs/ch16.xml | 150 ++++++++++++++++++++++++++++----------------------------- 20 files changed, 267 insertions(+), 267 deletions(-) diff --git a/specs/appA.xml b/specs/appA.xml index 6bb0dbe..18050eb 100644 --- a/specs/appA.xml +++ b/specs/appA.xml @@ -1,7 +1,7 @@ <appendix id='default_symbol_transformations'> <title>Default Symbol Transformations - + Interpreting the Control Modifier @@ -130,7 +130,7 @@ not listed in this table are application-specific. - + Interpreting the Lock Modifier @@ -144,7 +144,7 @@ Control returned by the event. - + Locale-Sensitive Capitalization @@ -158,7 +158,7 @@ state of the user environment (e.g. locale) into account. - + Locale-Insensitive Capitalization @@ -175,12 +175,12 @@ capitalization behavior. Any keysyms not explicitly listed in these tables are not capitalized by XKB when locale-insensitive capitalization is in effect and are not automatically assigned the ALPHABETIC - type as described in the Alphabetic Key Type. + type as described in the Alphabetic Key Type. - -Capitalization Rules for Latin-1 Keysyms + +Capitalization Rules for Latin-1 Keysyms This table lists the Latin-11 keysyms for which XKB defines upper and lower @@ -355,7 +355,7 @@ case: - + Capitalization Rules for Latin-2 Keysyms @@ -458,7 +458,7 @@ This table lists the Latin-2 keysyms for which XKB defines upper and lower case: - + Capitalization Rules for Latin-3 Keysyms @@ -521,7 +521,7 @@ This table lists the Latin-3 keysyms for which XKB defines upper and lower case: - + Capitalization Rules for Latin-4 Keysyms @@ -600,7 +600,7 @@ This table lists the Latin-4 keysyms for which XKB defines upper and lower case: - + Capitalization Rules for Cyrillic Keysyms @@ -766,7 +766,7 @@ case: - + Capitalization Rules for Greek Keysyms @@ -895,7 +895,7 @@ This table lists the Greek keysyms for which XKB defines upper and lower case: - + Capitalization Rules for Other Keysyms diff --git a/specs/appB.xml b/specs/appB.xml index 179d88c..85137cf 100644 --- a/specs/appB.xml +++ b/specs/appB.xml @@ -1,9 +1,9 @@ Canonical Key Types - + Canonical Key Types - + The ONE_LEVEL Key Type @@ -15,7 +15,7 @@ ONE_LEVEL - + The TWO_LEVEL Key Type @@ -33,7 +33,7 @@ Shift - + The ALPHABETIC Key Type @@ -87,7 +87,7 @@ Lock - + The KEYPAD Key Type diff --git a/specs/appC.xml b/specs/appC.xml index d34c9a6..ec37d35 100644 --- a/specs/appC.xml +++ b/specs/appC.xml @@ -1,9 +1,9 @@ New KeySyms - + New KeySyms - + KeySyms Used by the ISO9995 Standard @@ -241,7 +241,7 @@ - + KeySyms Used to Control The Core Pointer @@ -443,7 +443,7 @@ - + KeySyms Used to Change Keyboard Controls @@ -531,7 +531,7 @@ - + KeySyms Used To Control The Server @@ -583,7 +583,7 @@ - + KeySyms for Non-Spacing Diacritical Keys diff --git a/specs/appD.xml b/specs/appD.xml index abda53c..5251cb4 100644 --- a/specs/appD.xml +++ b/specs/appD.xml @@ -1,7 +1,7 @@ Protocol Encoding - + Syntactic Conventions @@ -123,7 +123,7 @@ for example, the size of the previous structure is written as "4+[4]" bytes. - + Common Types SETofKB_EVENTTYPE @@ -481,7 +481,7 @@ p unused,p=pad(2+l) - + Errors 1 0 Error @@ -501,7 +501,7 @@ class, or feedback - + Key Actions 1 0 type @@ -733,7 +733,7 @@ class, or feedback - + Key Behaviors 1 #x00 type @@ -773,7 +773,7 @@ class, or feedback - + Requests 1 ?? opcode @@ -1884,7 +1884,7 @@ p unused, p=pad(n) - + Events 1 ?? code diff --git a/specs/ch01.xml b/specs/ch01.xml index 7bf0ef4..27dcc88 100644 --- a/specs/ch01.xml +++ b/specs/ch01.xml @@ -1,4 +1,4 @@ - + Overview This extension provides a number of new capabilities and controls for @@ -85,7 +85,7 @@ keyboard. The following sections describe the new capabilities of the extension and the effect of the extension on core protocol requests, events and errors. - + Conventions and Assumptions This document uses the syntactic diff --git a/specs/ch02.xml b/specs/ch02.xml index ab7aa23..0234297 100644 --- a/specs/ch02.xml +++ b/specs/ch02.xml @@ -1,4 +1,4 @@ - + Keyboard State The core protocol description of @@ -73,7 +73,7 @@ a single keyboard, or to access less-commonly used symbols within a character set. - + Locking and Latching Modifiers and Groups With the core protocol, there is no way to @@ -89,7 +89,7 @@ groups apply only to the next key event that does not change keyboard state. - + Fundamental Components of XKB Keyboard State The fundamental components of XKB keyboard state include: @@ -128,7 +128,7 @@ only in response to keyboard or pointer activity. - + Computing Effective Modifier and Group The effective modifiers and group @@ -211,7 +211,7 @@ GroupsWrap - + Computing A State Field from an XKB State Many events report the keyboard state @@ -253,7 +253,7 @@ modifiers and the pointer button state. - + Derived Components of XKB Keyboard State In addition to the fundamental state @@ -273,7 +273,7 @@ ServerInternalModifiers IgnoreLocksModifiers and IgnoreGroupLock - controls, described in Server + controls, described in Server Internal Modifiers and Ignore Locks Behavior, to derive these two states as follows: @@ -295,7 +295,7 @@ effects of any locked groups. - + Server Internal Modifiers and Ignore Locks Behavior The core protocol does not provide any @@ -348,14 +348,14 @@ this behavior without exhaustively grabbing every possible modifier combination. - + Compatibility Components of Keyboard State 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 -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 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; 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 e9ac99c..d71f353 100644 --- a/specs/ch03.xml +++ b/specs/ch03.xml @@ -1,4 +1,4 @@ - + Virtual Modifiers The core protocol specifies that @@ -80,7 +80,7 @@ XKB puts most aspects of the keyboard under user or program control, so it is even more important to clearly and uniformly refer to modifiers by function. - + Modifier Definitions Use an @@ -156,7 +156,7 @@ Meta. - + Inactive Modifier Definitions Some XKB structures ignore modifier @@ -182,7 +182,7 @@ virtual modifiers are bound. - + Virtual Modifier Mapping XKB maintains a @@ -212,7 +212,7 @@ NumLock The virtual modifier mapping is normally updated automatically whenever actions -are assigned to keys (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 ab1547a..4d804e2 100644 --- a/specs/ch04.xml +++ b/specs/ch04.xml @@ -1,4 +1,4 @@ - + Global Keyboard Controls @@ -15,7 +15,7 @@ Wisconsin-Madison WI 53705-2280. Phone: 608-262-6966. e-mail: info@trace.wisc.edu.. - + The RepeatKeys Control @@ -43,7 +43,7 @@ milliseconds. - + The PerKeyRepeat Control @@ -63,7 +63,7 @@ GetKeyboardControl - + Detectable Autorepeat @@ -99,7 +99,7 @@ whether or not it is supported. -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 @@ -109,7 +109,7 @@ which lists the per-client flags that are supported. - + The SlowKeys Control @@ -148,11 +148,11 @@ rejection or release of any key to interested clients using AccessXNotify events. The AccessXNotify - event is described in more detail in Events. + event is described in more detail in Events. - + The BounceKeys Control @@ -183,11 +183,11 @@ interested clients by sending an AccessXNotify event. The AccessXNotify - event is described in more detail in Events. + event is described in more detail in Events. - + The StickyKeys Control @@ -320,7 +320,7 @@ XkbAX_LatchToLock - + The MouseKeys Control @@ -347,7 +347,7 @@ do not explicitly specify a button. - + The MouseKeysAccel Control @@ -375,7 +375,7 @@ When MouseKeys are active and a SA_MovePtr - key action (see Key + key action (see Key Actions) is activated, a pointer motion event is generated immediately. If MouseKeysAccel @@ -388,7 +388,7 @@ mouse keys interval - + Relative Pointer Motion @@ -464,7 +464,7 @@ steps_to_max - + Absolute Pointer Motion @@ -478,7 +478,7 @@ specified in the action. - + The AccessXKeys Control @@ -515,15 +515,15 @@ StickyKeys Some of these key sequences optionally generate audible feedback of the change -in state, as described in The +in state, as described in The AccessXFeedback Control, or cause XkbAccessXNotify - events as described in Events. + events as described in Events. - + The AccessXTimeout Control @@ -568,7 +568,7 @@ AccessX Controls Values - + The AccessXFeedback Control @@ -744,7 +744,7 @@ DumbBellFB - + The Overlay1 and Overlay2 Controls @@ -778,22 +778,22 @@ should generate when that overlay is enabled, assign it either the KB_Overlay1 or KB_Overlay2 - key behaviors, as described in + key behaviors, as described in Key Behavior. - + "Boolean" Controls and The EnabledControls Control All of the controls described above, along with the AudibleBell - control (described in Disabling + control (described in Disabling Server Generated Bells) and the IgnoreGroupLock - control (described in 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 @@ -812,30 +812,30 @@ EnabledControls control or specified in any context that accepts only boolean controls: GroupsWrap - (Computing Effective Modifier and + (Computing Effective Modifier and Group), EnabledControls , InternalMods - (Server Internal Modifiers and + (Server Internal Modifiers and Ignore Locks Behavior), and IgnoreLockMods - (Server Internal Modifiers and + (Server Internal Modifiers and Ignore Locks Behavior) and PerKeyRepeat - (The RepeatKeys Control) + (The RepeatKeys Control) - + Automatic Reset of Boolean Controls The auto-reset controls are a per-client value which consist of two masks that can contain any of the -boolean controls (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 @@ -850,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 (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 fc9a185..5669a39 100644 --- a/specs/ch05.xml +++ b/specs/ch05.xml @@ -1,5 +1,5 @@ - + Key Event Processing Overview @@ -20,7 +20,7 @@ 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 -Global Keyboard Controls. +Global Keyboard Controls. @@ -31,7 +31,7 @@ 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 -Key Behavior. +Key Behavior. @@ -39,7 +39,7 @@ Per-key behaviors are described in detail in 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 Key Actions. +change some aspect of the server. Key actions are described in Key Actions. @@ -52,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 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. 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. @@ -69,7 +69,7 @@ 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 - + 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 6351760..8a673a4 100644 --- a/specs/ch06.xml +++ b/specs/ch06.xml @@ -1,4 +1,4 @@ - + Key Event Processing in the Server @@ -8,7 +8,7 @@ activity and passed to XKB by the DDX layer, or they can be synthesized by another extension, such as XTEST. - + Applying Global Controls @@ -83,7 +83,7 @@ RepeatKeys - + Key Behavior @@ -217,7 +217,7 @@ KB_Default - + Key Actions @@ -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 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 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 The +acceleration as described in The MouseKeysAccel Control. @@ -1627,13 +1627,13 @@ 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 Effects of XKB on Core +state. See Effects of XKB on Core Protocol Events for a description of this compatibility mapping. - + Delivering a Key or Button Event to a Client @@ -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 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 -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 +detectable autorepeat (see Detectable Autorepeat), the event is not delivered to the client. @@ -1697,7 +1697,7 @@ protocol grabs and the reason that the per-client flags are needed. - + XKB Interactions With Core Protocol Grabs @@ -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 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 700f28f..af87587 100644 --- a/specs/ch07.xml +++ b/specs/ch07.xml @@ -1,4 +1,4 @@ - + Key Event Processing in the Client @@ -7,19 +7,19 @@ 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 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 rules to be used to interpret those symbols. - + Notation and Terminology XKB associates a two-dimensional array of symbols with each key. Symbols are -addressed by keyboard group (see +addressed by keyboard group (see Keyboard State) and shift level, where level is defined as in the ISO9995 standard: @@ -75,7 +75,7 @@ for it, but we try to minimize confusion by using "group" and "level" (or "shift level") to refer to symbols regardless of context. - + Determining the KeySym Associated with a Key Event @@ -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 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 -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 Key Types +described in Key Types below. @@ -116,7 +116,7 @@ associated with the key. - + Key Types @@ -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 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 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 @@ -257,7 +257,7 @@ Lock - + Key Symbol Map @@ -382,7 +382,7 @@ key actually yields that code. - + Transforming the KeySym Associated with a Key Event @@ -452,7 +452,7 @@ 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 -client map example; +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 @@ -468,7 +468,7 @@ Control - + Client Map Example @@ -677,7 +677,7 @@ to be used. The key type determines which symbol is chosen from the list. -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 cbf4b78..08524a8 100644 --- a/specs/ch08.xml +++ b/specs/ch08.xml @@ -1,4 +1,4 @@ - + Symbolic Names @@ -87,7 +87,7 @@ 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 - + The Server Database of Keyboard Components, and can be combined to assemble a complete keyboard description. @@ -132,7 +132,7 @@ customizations are straightforward. Key aliases can be specified both in the symbolic names component and in the -keyboard geometry (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 8a0eb87..d3f8510 100644 --- a/specs/ch09.xml +++ b/specs/ch09.xml @@ -1,4 +1,4 @@ - + Keyboard Indicators @@ -42,7 +42,7 @@ keyboard indicators, which makes it straightforward to provide an on-screen "virtual" LED panel. - + Global Information About Indicators @@ -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 Using the Server’s + request (see Using the Server’s Database of Keyboard Components). @@ -78,7 +78,7 @@ GetKeyboardControl - + Per-Indicator Information @@ -88,12 +88,12 @@ 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 Querying and Changing Symbolic + request to change symbolic names. Both requests are described in Querying and Changing Symbolic Names. - + Indicator Maps @@ -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 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 "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 @@ -321,7 +321,7 @@ IM_NoAutomatic - + Effects of Explicit Changes on Indicators diff --git a/specs/ch10.xml b/specs/ch10.xml index bfb99ae..74362b0 100644 --- a/specs/ch10.xml +++ b/specs/ch10.xml @@ -1,4 +1,4 @@ - + Keyboard Bells @@ -13,7 +13,7 @@ symbolic name to a bell request or receive an event when the keyboard bell is rung. - + Client Notification of Bells @@ -46,7 +46,7 @@ sound for each type of bell. - + Disabling Server Generated Bells @@ -87,7 +87,7 @@ XkbBell - + Generating Named Bells @@ -110,14 +110,14 @@ sounds other than simple tones, but it is not required to do so. Aside from those used by the XKB AccessXFeedback - control (see The AccessXFeedback + control (see The AccessXFeedback Control), this extension does not specify bell names or their interpretation. - + Generating Optional Named Bells @@ -147,7 +147,7 @@ to weed out "normal" keyboard bells. - + Forcing a Server Generated Bell diff --git a/specs/ch11.xml b/specs/ch11.xml index 9a32496..39361a4 100644 --- a/specs/ch11.xml +++ b/specs/ch11.xml @@ -1,5 +1,5 @@ - + Keyboard Geometry @@ -79,7 +79,7 @@ structures refer to geometry properties. A list of key aliases -, as described in 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 Shapes and Outlines. +. Shapes and outlines are described in detail in Shapes and Outlines. @@ -136,7 +136,7 @@ a collection of keys and doodads that are physically close together and logically related. - + Shapes and Outlines @@ -194,7 +194,7 @@ to generate a recognizable but degraded image of the keyboard. - + Sections @@ -261,7 +261,7 @@ while the key specified in over must not. - + Doodads @@ -336,7 +336,7 @@ The XKB extension does not specify the interpretation of logo names. - + Keyboard Geometry Example diff --git a/specs/ch12.xml b/specs/ch12.xml index d30a213..f37caf1 100644 --- a/specs/ch12.xml +++ b/specs/ch12.xml @@ -1,5 +1,5 @@ - + Interactions Between XKB and the Core Protocol @@ -49,11 +49,11 @@ This section describes the differences between the core X protocol’s notion of a keyboard mapping and XKB and explains the ways they can interact. - + Group Compatibility Map -As described in 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 @@ -139,7 +139,7 @@ Group4 - + Setting a Passive Grab for an XKB State @@ -192,7 +192,7 @@ or for grabs that are set by some other client. - + Changing the Keyboard Mapping Using the Core Protocol @@ -215,7 +215,7 @@ cannot be described using this mapping should use XKB functions directly. - + Explicit Keyboard Mapping Components @@ -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 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 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 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 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 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 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 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 Assigning +match the key (see Assigning Actions To Keys). @@ -300,7 +300,7 @@ Actions To Keys). - + Assigning Symbols To Groups @@ -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 Assigning Actions To Keys. + requests, but it does choose key actions as described in Assigning Actions To Keys. @@ -364,7 +364,7 @@ little more complicated. - + Assigning Symbols to Groups One and Two with Explicitly Defined Key Types @@ -423,7 +423,7 @@ with the core protocol. - + Assigning Types To Groups of Symbols for a Key @@ -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 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 @@ -592,7 +592,7 @@ Group2 - + Assigning Actions To Keys @@ -733,7 +733,7 @@ locking key field is set in the symbol interpretation, the behavior of the key is changed to KB_Lock - (see Key Behavior). The + (see Key Behavior). The ExplicitBehavior component prevents this change. @@ -766,7 +766,7 @@ XkbSetCompatMap - + Updating Everything Else @@ -780,14 +780,14 @@ indicator maps, internal modifiers or ignore locks modifiers. - + Effects of XKB on Core Protocol Events 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 +clients depending on context (see Keyboard State for a detailed description of each of the keyboard state components): @@ -871,7 +871,7 @@ GrabsUseXKBState - + Effect of XKB on Core Protocol Requests @@ -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 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 @@ -988,7 +988,7 @@ MappingNotify - + Sending Events to Clients diff --git a/specs/ch13.xml b/specs/ch13.xml index 9efa7b2..49a8c2e 100644 --- a/specs/ch13.xml +++ b/specs/ch13.xml @@ -1,4 +1,4 @@ - + The Server Database of Keyboard Components @@ -16,7 +16,7 @@ current keyboard description with a complete keyboard description assembled as described below. - + Component Names @@ -52,7 +52,7 @@ use of other characters is implementation-dependent. - + Partial Components and Combining Multiple Components @@ -155,7 +155,7 @@ where necessary). - + Component Hints @@ -216,7 +216,7 @@ listed in the section below that describes that kind of component. - + Keyboard Components @@ -235,7 +235,7 @@ types - + The Keycodes Component @@ -266,7 +266,7 @@ XKB defines no hints that are specific to the keycodes component. - + The Types Component @@ -276,7 +276,7 @@ types with the various keyboard keys. It affects the types symbolic name and the list of types associated with the keyboard (see -Key Types). The types component +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. @@ -294,7 +294,7 @@ XKB defines no hints that are specific to the types component. - + The Compatibility Map Component @@ -315,7 +315,7 @@ XKB defines no hints that are specific to the compatibility map component. - + The Symbols Component @@ -400,7 +400,7 @@ LC_AlternateGroup may be combined with any of the other flags). - + The Geometry Component @@ -422,7 +422,7 @@ XKB defines no hints that are specific to the geometry component. - + Complete Keymaps diff --git a/specs/ch14.xml b/specs/ch14.xml index 2da16db..6a2f45a 100644 --- a/specs/ch14.xml +++ b/specs/ch14.xml @@ -1,4 +1,4 @@ - + Replacing the Keyboard "On-the-Fly" @@ -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 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 6c56ad6..ec0ce72 100644 --- a/specs/ch15.xml +++ b/specs/ch15.xml @@ -1,4 +1,4 @@ - + Interactions Between XKB and the X Input Extension @@ -79,7 +79,7 @@ supported XKB features for extension devices, or if a request from the client that is receiving the event attempted to use an unsupported feature. - + Using XKB Functions with Input Extension Keyboards @@ -108,12 +108,12 @@ Keyboard - + Pointer and Device Button Actions The XKB extension optionally allows clients to assign any key action (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. @@ -141,7 +141,7 @@ cause an error condition. - + Indicator Maps for Extension Devices @@ -186,7 +186,7 @@ XkbGetDeviceInfo - + Indicator Names for Extension Devices diff --git a/specs/ch16.xml b/specs/ch16.xml index 643ebce..83cc8f8 100644 --- a/specs/ch16.xml +++ b/specs/ch16.xml @@ -1,5 +1,5 @@ - + XKB Protocol Requests @@ -8,7 +8,7 @@ specification of the core X protocol with a number of additions, which are detailed below. - + Errors @@ -23,7 +23,7 @@ extension. - + Keyboard Errors @@ -85,7 +85,7 @@ indicated id - + Side-Effects of Errors @@ -103,7 +103,7 @@ ignored. - + Common Types @@ -820,7 +820,7 @@ maps: LISTofKB_INDICATORMAP ] - + Requests @@ -829,7 +829,7 @@ separated into categories of related requests. - + Initializing the X Keyboard Extension @@ -897,7 +897,7 @@ XkbUseExtension - + Selecting Events @@ -1215,13 +1215,13 @@ 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. 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. - + Generating Named Keyboard Bells @@ -1406,7 +1406,7 @@ honor them. - + Querying and Changing Keyboard State @@ -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. 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 +group states, as described in Group Compatibility Map. @@ -1694,7 +1694,7 @@ If any errors occur, this request has no effect. - + Querying and Changing Keyboard Controls @@ -1821,14 +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 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 +locks modifiers as described in Keyboard State. Both are modifier definitions ( -Modifier Definitions) which +Modifier Definitions) which report the real modifiers, virtual modifiers, and the resulting combination of real modifiers that are bound to the corresponding control. @@ -1855,7 +1855,7 @@ mouseKeysMaxSpeed and mouseKeysCurve return values report the current acceleration applied to mouse keys, as -described in The MouseKeysAccel +described in The MouseKeysAccel Control. All times are reported in milliseconds. @@ -2223,7 +2223,7 @@ repeatDelay and repeatInterval change the autorepeat characteristics of the keyboard, as described in -The RepeatKeys Control. If +The RepeatKeys Control. If specified, repeatDelay and @@ -2239,7 +2239,7 @@ If applied, the slowKeysDelay field specifies a new delay for the SlowKeys - control, as defined in The + control, as defined in The SlowKeys Control. If specified, slowKeysDelay must be non-zero, or a @@ -2253,7 +2253,7 @@ If applied, the debounceDelay field specifies a new delay for the BounceKeys - control, as described in The + control, as described in The BounceKeys Control. If present, the debounceDelay must be non-zero or a @@ -2274,7 +2274,7 @@ SA_LockPtrBtn mouseKeysDfltBtn must specify a legal button for the core pointer device, or a Value - error results. Key + error results. Key Actions describes the SA_PtrBtn and @@ -2297,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. The + action is held down. The MouseKeysAccel Control describes these MouseKeysAccel parameters in more detail. If defined, the @@ -2324,7 +2324,7 @@ Value If applied, the accessXOptions field sets the AccessX options, which are described in detail in -The AccessXKeys Control. If +The AccessXKeys Control. If either one of XkbStickyKeysMask and @@ -2358,7 +2358,7 @@ accessXTimeoutOptionsMask and accessXTimeoutOptionsValues fields change the behavior of the AccessX Timeout control, as described in -The AccessXTimeout +The AccessXTimeout Control. The accessXTimeout must be greater than zero, or a @@ -2386,7 +2386,7 @@ Match If present, the groupsWrap field specifies the treatment of out-of-range keyboard groups, as described in -Key Symbol Map. If the +Key Symbol Map. If the groupsWrap field does not specify a legal treatment for out-of-range groups, a @@ -2471,7 +2471,7 @@ Value - + Querying and Changing the Keyboard Mapping @@ -3326,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 +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 @@ -3740,7 +3740,7 @@ XkbSetMapRecomputeActions flags , the actions associated with any keys for which symbol or modifier bindings were changed by this request are recomputed as described in -Assigning Actions To Keys. Note +Assigning Actions To Keys. Note that actions are recomputed after any actions specified in this request are bound to keys, so the actions @@ -3818,7 +3818,7 @@ XkbIndicatorStateNotify - + Querying and Changing the Compatibility Map @@ -4086,13 +4086,13 @@ 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 Assigning Actions To +described in Assigning Actions To Keys. - + Querying and Changing Indicators @@ -4243,7 +4243,7 @@ XkbIndicatorStateNotify The maps return value reports the requested indicator maps. Indicator maps are -described in Indicator Maps +described in Indicator Maps @@ -4717,7 +4717,7 @@ If setMap is True -, XKB changes the map for the indicator (see Indicator Maps) to reflect the +, XKB changes the map for the indicator (see Indicator Maps) to reflect the values specified in map . @@ -4753,7 +4753,7 @@ map and the current state of the keyboard. - + Querying and Changing Symbolic Names @@ -5426,7 +5426,7 @@ Atom - + Querying and Changing Keyboard Geometry @@ -5526,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 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 @@ -5566,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 Keyboard +described in detail in Keyboard Geometry @@ -5762,7 +5762,7 @@ keyboard definition, but XKB does not check for or guarantee it. - + Querying and Changing Per-Client Flags @@ -5859,35 +5859,35 @@ per-client-flags are: XkbPCF_DetectableAutorepeat - Detectable + Detectable Autorepeat XkbPCF_GrabsUseXKBStateMask - Setting a Passive Grab + Setting a Passive Grab for an XKB State XkbPCF_AutoResetControlsMask - Automatic Reset of + Automatic Reset of Boolean Controls XkbPCF_LookupStateWhenGrabbed - Effects of XKB on Core + Effects of XKB on Core Protocol Events XkbPCF_SendEventUsesXKBState - Sending Events to + Sending Events to Clients @@ -5987,7 +5987,7 @@ autoCtrlValues - + Using the Server’s Database of Keyboard Components @@ -6113,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 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. @@ -6157,14 +6157,14 @@ compatMaps symbols and geometries - return the hints (see Component + return the hints (see Component Hints) and names of any components from the server database that match the corresponding pattern. -The Server Database of Keyboard +The Server Database of Keyboard Components describes the X server database of keyboard components in more detail. @@ -6304,7 +6304,7 @@ compatMapSpec symbolsSpec and geometrySpec - component expressions (see + component expressions (see Partial Components and Combining Multiple Components) specify the database components to be used to assemble the keyboard description. @@ -6414,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 -Partial Components and Combining +Partial Components and Combining Multiple Components. @@ -6439,7 +6439,7 @@ 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 -Replacing the Keyboard +Replacing the Keyboard "On-the-Fly" for more information about the effects of replacing the keyboard description on the fly. @@ -6609,7 +6609,7 @@ description. - + Querying and Changing Input Extension Devices @@ -6891,7 +6891,7 @@ 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 - + Interactions Between XKB and the X Input Extension) for the specified device, and the unsupported return value reports any @@ -7231,7 +7231,7 @@ for it and, if generated, is not sent to any other clients. - + Debugging the X Keyboard Extension @@ -7382,7 +7382,7 @@ Length - + Events @@ -7396,7 +7396,7 @@ distinguish XKB event type. - + Tracking Keyboard Replacement @@ -7539,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 +reported to that client. See Replacing the Keyboard "On-the-Fly" for a more detailed explanation. @@ -7595,7 +7595,7 @@ both fields have the value - + Tracking Keyboard Mapping Changes @@ -7835,7 +7835,7 @@ modifier mappings. Otherwise, both fields are - + Tracking Keyboard State Changes @@ -7907,7 +7907,7 @@ requestMajor, requestMinor: CARD8 An XkbStateNotify event reports that some component of the XKB state (see -Keyboard State) has changed. +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 @@ -7922,7 +7922,7 @@ deviceID changed field reports the XKB state components (see -Keyboard State) that have changed +Keyboard State) that have changed and contain any combination of: @@ -8114,7 +8114,7 @@ change in state and have the value - + Tracking Keyboard Control Changes @@ -8171,9 +8171,9 @@ requestMinor: CARD8 An XkbControlsNotify event reports a change in one or more of the global keyboard controls (see -Global Keyboard Controls) +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 @@ -8265,7 +8265,7 @@ change in state and have the value - + Tracking Keyboard Indicator State Changes @@ -8355,7 +8355,7 @@ client. - + Tracking Keyboard Indicator Map Changes @@ -8424,7 +8424,7 @@ state - + Tracking Keyboard Name Changes @@ -8643,7 +8643,7 @@ changed - + Tracking Compatibility Map Changes @@ -8750,7 +8750,7 @@ XkbGroupCompatMask - + Tracking Application Bell Requests @@ -8896,7 +8896,7 @@ XkbBell - + Tracking Messages Generated by Key Actions @@ -9012,7 +9012,7 @@ message - + Tracking Changes to AccessX State and Keys @@ -9178,14 +9178,14 @@ slowKeysDelay and debounceDelay fields always reports the current slow keys acceptance delay (see -The SlowKeys Control) and -debounce delay (see The BounceKeys +The SlowKeys Control) and +debounce delay (see The BounceKeys Control) for the specified keyboard. - + Tracking Changes To Extension Devices @@ -9344,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 Interactions Between +device. See Interactions Between XKB and the X Input Extension for more information about possible XKB interactions with the X Input Extension. -- cgit v1.2.1