diff --git a/specs/XKB/ch02.xml b/specs/XKB/ch02.xml index 2d71a46a..b140e42f 100644 --- a/specs/XKB/ch02.xml +++ b/specs/XKB/ch02.xml @@ -671,9 +671,9 @@ to the core protocol error set. This error code will be reported as the error is reported in an XErrorEvent, additional information is reported in the -resource_id +resourceid field. The most significant byte of the -resource_id +resource_id is a further refinement of the error cause, as defined in Table 2.2. The least significant byte will contain the device, class, or feedback ID as indicated in diff --git a/specs/XKB/ch04.xml b/specs/XKB/ch04.xml index 34108733..f02c4b71 100644 --- a/specs/XKB/ch04.xml +++ b/specs/XKB/ch04.xml @@ -794,7 +794,7 @@ type and for the core protocol type equals the Xkb base event code; see section 2.4). If the event is an Xkb event, you may then use the -any.xkb_type +any.xkb_type 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. diff --git a/specs/XKB/ch05.xml b/specs/XKB/ch05.xml index 0259b710..4b84f15c 100644 --- a/specs/XKB/ch05.xml +++ b/specs/XKB/ch05.xml @@ -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 ptr_button +corresponding modifier states. The ptr_buttons 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. diff --git a/specs/XKB/ch07.xml b/specs/XKB/ch07.xml index 759c67b6..79ced8d7 100644 --- a/specs/XKB/ch07.xml +++ b/specs/XKB/ch07.xml @@ -67,15 +67,15 @@ in effect. Virtual modifiers are named by converting their string name to an X Atom and storing the Atom in the -names.vmods +names.vmods array in an XkbDescRec structure (see section 6.1). The position of a name Atom in the -names.vmods +names.vmods 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 -names.vmods +names.vmods is the i-th virtual modifier, represented by the mask (1<<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 */ An Xkb modifier definition consists of a set of bit masks corresponding to the -eight real modifiers ( -real_mods -); a similar set of bitmasks corresponding to the 16 named virtual modifiers -( -vmods -); and an effective mask ( -mask -). The effective mask represents the set of all real modifiers that can +eight real modifiers +(real_mods); + a similar set of bitmasks corresponding to the 16 named virtual modifiers +(vmods); + and an effective mask +(mask). + 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. mask 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 -( -real_mods -) +(real_mods) plus any real modifiers that are bound to the virtual modifiers specified in the -definition ( -vmods -). The binding of the virtual modifiers to real modifiers is exterior to the +definition +(vmods). + 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. The binding of virtual modifiers to real modifiers is defined by the -server.vmods +server.vmods array in an XkbDescRec 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 -server.vmodmap +server.vmodmap array indicates which virtual modifiers are bound to each key; each entry is a bitmask for the virtual modifier bits. The -server.vmodmap +server.vmodmap array is indexed by keycode. @@ -387,12 +384,12 @@ following names are suggested: If the second (0-relative) entry in -names.vmods +names.vmods contains the Atom for "NumLock", then 0x4 (1<<2) is the virtual modifier bit for the NumLock virtual modifier. If -server.vmods +server.vmods [2] contains Mod3Mask, then the @@ -419,8 +416,8 @@ Continuing the example, if the keyboard has a keysym bound to the key with keycode 14, and the NumLock virtual modifier is bound to this key, -server.vmodmap -[14] contains 0x4. +server.vmodmap[14] +contains 0x4. diff --git a/specs/XKB/ch08.xml b/specs/XKB/ch08.xml index 8600af20..c6f07677 100644 --- a/specs/XKB/ch08.xml +++ b/specs/XKB/ch08.xml @@ -16,12 +16,12 @@ the logical state of the Furthermore, the core X implementation does not provide clients with the ability to determine what bits in the -led_mask +led_mask field of the XKeyboardState 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 -led_mask +led_mask field to turn on the Scroll Lock LED or whether the keyboard even has a @@ -538,11 +538,11 @@ modifiers. The mods are unbound. To specify the mods field, in general, assign the modifiers of interest to -mods.real_mods +mods.real_mods and the virtual modifiers of interest to -mods.vmods. +mods.vmods. You can disregard the -mods.mask +mods.mask 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 mods are on in the keyboard base state. If both -mods.real_mods +mods.real_mods and -mods.vmods +mods.vmods are zero, the indicator is lit when the base keyboard state contains no modifiers. @@ -642,9 +642,9 @@ The indicator is lit when any of the modifiers specified in the field of mods are latched. If both -mods.real_mods +mods.real_mods and -mods.vmods +mods.vmods are zero, the indicator is lit when none of the modifier keys are latched. @@ -656,9 +656,9 @@ The indicator is lit when any of the modifiers specified in the field of mods are locked. If both -mods.real_mods +mods.real_mods and -mods.vmods +mods.vmods are zero, the indicator is lit when none of the modifier keys are locked. @@ -670,9 +670,9 @@ The indicator is lit when any of the modifiers specified in the field of mods are in the effective keyboard state. If both -mods.real_mods +mods.real_mods and -mods.vmods +mods.vmods are zero, the indicator is lit when the effective keyboard state contains no modifiers. @@ -685,9 +685,9 @@ The indicator is lit when any of the modifiers specified in the field of mods are in the keyboard compatibility state. If both -mods.real_mods +mods.real_mods and -mods.vmods +mods.vmods are zero, the indicator is lit when the keyboard compatibility state contains no modifiers. diff --git a/specs/XKB/ch10.xml b/specs/XKB/ch10.xml index 619d3ff1..c537759d 100644 --- a/specs/XKB/ch10.xml +++ b/specs/XKB/ch10.xml @@ -658,7 +658,7 @@ protocol. There are no convenience functions in Xkb for manipulating this control. The PerKeyRepeat control settings are carried in the -per_key_repeat +per_key_repeat field of an XkbControlsRec structure, discussed in section 10.8. @@ -4158,7 +4158,7 @@ enabled ( or XkbStickyKeysMask bit is turned on in the -enabled_cntrls +enabled_ctrls field). @@ -4256,7 +4256,7 @@ id='ax_timeout_axt_opts_mask_axt_opts_values_axt_ctrls_mask_and_axt_ctrls_values ax_timeout, -act_opts_mask, +axt_opts_mask, axt_opts_values, axt_ctrls_mask, and @@ -4274,29 +4274,29 @@ units involved. The -per_key_repeat +per_key_repeat field mirrors the -auto_repeats +auto_repeats field of the core protocol XKeyboardState structure: changing the -auto_repeats +auto_repeats field automatically changes -per_key_repeat +per_key_repeat 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 XkbGetControls. If the -per_key_repeat +per_key_repeat were not in this structure, you would have to call both XGetKeyboardControl and XkbGetControls to get this information. The bits correspond to keycodes. The first seven keys (keycodes 1-7) are indicated in -per_key_repeat -[0], with bit position 0 (low order) corresponding to the fictitious keycode 0. +per_key_repeat[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. @@ -4557,7 +4557,7 @@ the corresponding values are still updated in the X server. For example, the fields are ignored unless the RepeatKeys control is enabled (that is, the X server’s equivalent of -xkb->ctrls +xkb->ctrls has XkbRepeatKeysMask set in @@ -4680,7 +4680,7 @@ match those in the changed keyboard description. - keyboard description with changed xkb->ctrls + keyboard description with changed xkb->ctrls @@ -4690,7 +4690,7 @@ match those in the changed keyboard description. - which parts of xkb->ctrls have changed + which parts of xkb->ctrls have changed @@ -4965,7 +4965,7 @@ noted by one or more calls to - xkb->ctrls will be updated + xkb->ctrls will be updated @@ -4975,7 +4975,7 @@ noted by one or more calls to - indicates which parts of xkb->ctrls to update + indicates which parts of xkb->ctrls to update diff --git a/specs/XKB/ch13.xml b/specs/XKB/ch13.xml index 89084e3d..155e64ee 100644 --- a/specs/XKB/ch13.xml +++ b/specs/XKB/ch13.xml @@ -137,7 +137,7 @@ override those defined in the keycodes component of the server database, which are stored in the XkbNamesRec ( -xkb->names +xkb->names ). Therefore, consider the key aliases defined by the geometry before considering key aliases supplied by the keycodes. @@ -1002,12 +1002,12 @@ relative to the keyboard’s origin if the doodad is in the and off_color_ndx fields are color indices into the -XkbGeometryRec -’s color array and are the colors to draw the doodads with. Similarly, the +XkbGeometryRec’s + color array and are the colors to draw the doodads with. Similarly, the shape_ndx fields are indices into the -XkbGeometryRec -’s shape array. +XkbGeometryRec’s + shape array. @@ -1559,12 +1559,10 @@ to look up the alternate name, which it returns. Xkb provides functions to add a single new element to the top-level keyboard geometry. In each case the -num_ -* +num_* fields of the corresponding structure is incremented by 1. These functions do not change -sz_ -* +sz_* 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 -sz_ -* +sz_* but never touch -num_ -* +num_* (unless there is an allocation failure, in which case they reset both -sz_ -* +sz_* and -num_ -* +num_* to zero). These functions return Success if they succeed, diff --git a/specs/XKB/ch14.xml b/specs/XKB/ch14.xml index f43d6671..5c6baffa 100644 --- a/specs/XKB/ch14.xml +++ b/specs/XKB/ch14.xml @@ -789,83 +789,83 @@ server and are always updated by the server whenever it returns the data for an XkbKeyTypesMask -first_type, -num_types +first_type, +num_types -map->type[first_type] .. -map->type[first_type + num_types - 1] +map->type[first_type] .. +map->type[first_type + num_types - 1] XkbKeySymsMask -first_key_sym, -num_key_syms +first_key_sym, +num_key_syms -map->key_sym_map[first_key_sym] .. -map->key_sym_map[first_key_sym + num_key_syms - 1] +map->key_sym_map[first_key_sym] .. +map->key_sym_map[first_key_sym + num_key_syms - 1] XkbModifierMapMask -first_modmap_key, -num_modmap_keys +first_modmap_key, +num_modmap_keys -map->modmap[first_modmap_key] .. -map->modmap[first_modmap_key + num_modmap_keys-1] +map->modmap[first_modmap_key] .. +map->modmap[first_modmap_key + num_modmap_keys-1] XkbExplicitComponentsMask -first_key_explicit, -num_key_explicit +first_key_explicit, +num_key_explicit -server->explicit[first_key_explicit] .. -server->explicit[first_key_explicit + num_key_explicit - 1] +server->explicit[first_key_explicit] .. +server->explicit[first_key_explicit + num_key_explicit - 1] XkbKeyActionsMask -first_key_act, -num_key_acts +first_key_act, +num_key_acts -server->key_acts[first_key_act] .. -server->key_acts[first_key_act + num_key_acts - 1] +server->key_acts[first_key_act] .. +server->key_acts[first_key_act + num_key_acts - 1] XkbKeyBehaviorsMask -first_key_behavior, -num_key_behaviors +first_key_behavior, +num_key_behaviors -server->behaviors[first_key_behavior] .. -server->behaviors[first_key_behavior + num_key_behaviors - 1] +server->behaviors[first_key_behavior] .. +server->behaviors[first_key_behavior + num_key_behaviors - 1] XkbVirtualModsMask - vmods - server->vmods[*] + vmods + server->vmods[*] XkbVirtualModMapMask -first_vmodmap_key, -num_vmodmap_keys +first_vmodmap_key, +num_vmodmap_keys -server->vmodmap[first_vmodmap_key] .. -server->vmodmap[first_vmodmap_key + num_vmodmap_keys - 1] +server->vmodmap[first_vmodmap_key] .. +server->vmodmap[first_vmodmap_key + num_vmodmap_keys - 1] @@ -1046,7 +1046,7 @@ typedef struct { int num_key_explicit; /* # explicit entries changed */ int num_modmap_keys; /* # modmap entries changed */ int num_vmodmap_keys; /* # vmodmap entries changed */ - unsigned in t vmods; /* mask indicating which vmods changed */ + unsigned int vmods; /* mask indicating which vmods changed */ } XkbMapNotifyEvent; @@ -1061,7 +1061,7 @@ event are interpreted as the like-named fields in an (see section 14.3.1). The XkbMapNotifyEvent structure also has an additional -resized +resized field that is reserved for future use. diff --git a/specs/XKB/ch15.xml b/specs/XKB/ch15.xml index e885e757..3dd23ec8 100644 --- a/specs/XKB/ch15.xml +++ b/specs/XKB/ch15.xml @@ -819,7 +819,7 @@ refer to the XkbGetKeyTypes queries the server for the desired types, waits for a reply, and returns the desired types in the -xkb->map->types. +xkb->map->types. If successful, it returns Success. @@ -925,7 +925,7 @@ To change the number of levels in a key type, use changes the type specified by xkb -> -map->types +map->types [ type_ndx ], 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. The -kt_index +kt_index array of the XkbSymMapRec structure contains the indices of the key types (see section 15.2) 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 first. It waits for a reply and returns the keysyms in the -map.syms +map.syms field of xkb. If successful, @@ -2247,7 +2247,7 @@ as appropriate. If the adds the XkbKeySymsMask to the -changes +changes field of p_changes and modifies the @@ -2291,7 +2291,7 @@ Each entry represents the type to use for the associated group and is an index into xkb -> -map->types. +map->types. The new_types_in array is indexed by group index; if @@ -2457,9 +2457,7 @@ keysyms. It adjusts the and size_syms fields of -xkb -- ->map +xkb->map if it is necessary to reallocate the syms array. diff --git a/specs/XKB/ch16.xml b/specs/XKB/ch16.xml index ad1ddb59..819863ee 100644 --- a/specs/XKB/ch16.xml +++ b/specs/XKB/ch16.xml @@ -130,15 +130,15 @@ the entry represents an index into the The reason the acts field is a linear list of -XkbAction -s is to reduce the memory consumption associated with a keymap. Because Xkb +XkbActions + 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 KeySyms would potentially be very large and sparse. Instead, Xkb provides a small two-dimensional array of -XkbAction -s for each key. To store all of these individual arrays, Xkb concatenates each +XkbActions + for each key. To store all of these individual arrays, Xkb concatenates each array together in the acts field of the server map. @@ -588,7 +588,7 @@ have an associated data structure. XkbSA_ActionMessage - XkbMessgeAction + XkbMessageAction msg 16.1.11 @@ -810,9 +810,9 @@ modifier mapping of the key. Otherwise, the action modifiers are set to the modifiers specified by the mask, real_mods, -vmod1, +vmods1, and -vmod2 +vmods2 fields. @@ -1751,8 +1751,7 @@ The Table 16.8. A general meaning is given in the table, but the exact meaning depends on the action -type. -: +type: @@ -2245,9 +2244,9 @@ modifier mapping of the key. Otherwise, the action modifiers are set to the modifiers specified by the mask, real_mods, -vmod1, +vmods1, and -vmod2 +vmods2 fields. @@ -2440,7 +2439,7 @@ If Actions associated with the -XkbSwitchScreen +XkbSwitchScreenAction action structure change the active screen on a multiscreen display: @@ -3062,8 +3061,8 @@ The is False ) event is also sent to the client. As with all other Xkb events, -XkbActionMessageEvent -s are delivered to all clients requesting them, regardless of the current +XkbActionMessageEvents + are delivered to all clients requesting them, regardless of the current keyboard focus. However, the KeyPress or @@ -3587,7 +3586,7 @@ The low four bits of and v2_what specify the corresponding scale value (denoted -val<n>Scale +val<n>Scale in Table 16.17), if needed. The high four bits of v1_what @@ -3599,7 +3598,7 @@ The low four bits of v2_what can have the values shown in Table 16.17; the use of -val<n>Scale +val<n>Scale is shown in that table also. @@ -3623,34 +3622,34 @@ The low four bits of XkbSA_SetValMin -v<n>_value is set to its minimum legal value. +v<n>_value is set to its minimum legal value. XkbSA_SetValCenter -v<n>_valueis centered (to (max-min)/2). +v<n>_valueis centered (to (max-min)/2). XkbSA_SetValMax -v<n>_value is set to its maximum legal value. +v<n>_value is set to its maximum legal value. XkbSA_SetValRelative -v<n>_value * (2 -val<n>Scale) is added to -v<n>_value. +v<n>_value * (2 +val<n>Scale) is added to +v<n>_value. XkbSA_SetValAbsolute -v<n>_value - is set to (2 val<n>Scale). +v<n>_value + is set to (2 val<n>Scale). @@ -3978,7 +3977,7 @@ Keys that belong to the same radio group have the structure. If the radio group has a name in the XkbNamesRec structure, the radio group index is the index into the -radio_group +radio_group array in the XkbNamesRec structure. A radio group key when pressed stays logically down until another @@ -4106,8 +4105,8 @@ If the data is interpreted as a keycode, and events from this key are reported as if they came from -data -’s keycode. Otherwise, press and release events are processed normally. +data’s + keycode. Otherwise, press and release events are processed normally. @@ -4119,8 +4118,8 @@ If the data is interpreted as a keycode, and events from this key are reported as if they came from -data -’s keycode. Otherwise, press and release events are processed normally. +data’s + keycode. Otherwise, press and release events are processed normally. @@ -4667,7 +4666,7 @@ the virtual modifier mask. For each bit set in which, XkbGetVirtualMods updates the corresponding virtual modifier definition in the -server->vmods +server->vmods array of xkb. The diff --git a/specs/XKB/ch17.xml b/specs/XKB/ch17.xml index 388da5e8..93a1537f 100644 --- a/specs/XKB/ch17.xml +++ b/specs/XKB/ch17.xml @@ -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 -XkbCompatMap +XkbCompatMapRec 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 ( XkbDescRec ) points to the -XkbCompatMap +XkbCompatMapRec structure: @@ -1623,7 +1623,7 @@ server using and num_total_si are appropriate for use with the -compat.sym_interpret +compat.sym_interpret vector in this structure. @@ -1708,7 +1708,7 @@ in section num_si specifies the total number of entries to allocate in the symbol interpretation vector ( -xkb.compat.sym_interpret +xkb.compat.sym_interpret ). @@ -1793,7 +1793,7 @@ To free an entire compatibility map or selected portions of one, use - True => free XkbCompatMap + True => free XkbCompatMapRec structure itself @@ -1814,7 +1814,7 @@ in section free_map indicates whether the -XkbCompatMap +XkbCompatMapRec structure itself should be freed. If free_map is diff --git a/specs/XKB/ch18.xml b/specs/XKB/ch18.xml index 0d67f107..cc2969f8 100644 --- a/specs/XKB/ch18.xml +++ b/specs/XKB/ch18.xml @@ -181,9 +181,9 @@ total number of entries in the array is held in num_key_aliases. For each real and alias key name pair, the -real +real field refers to the a name in the keys array, and the -alias +alias 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 XkbNamesRec ( -xkb->names +xkb->names ). Therefore, consider the key aliases defined by the geometry before considering key aliases supplied by the XkbNamesRec. @@ -943,7 +943,7 @@ When your application receives a - XkbNameChanges structure to be updated + XkbNameChangesRec structure to be updated diff --git a/specs/XKB/ch20.xml b/specs/XKB/ch20.xml index 6b58fceb..232a92e5 100644 --- a/specs/XKB/ch20.xml +++ b/specs/XKB/ch20.xml @@ -97,7 +97,7 @@ There may be multiple entries for each of the component types. An entry may be either complete or -partial. +partial. 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 -any +any ASCII keyboard to use a national layout. @@ -123,13 +123,11 @@ later definitions override earlier ones. Component Names -Component names have the form " -class(member) -" where -class +Component names have the form “class(member)” where +class describes a subset of the available components for a particular type and the optional -member +member 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. The -class +class and -member +member 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. For example, if -names->symbols +names->symbols 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)"). diff --git a/specs/XKB/ch21.xml b/specs/XKB/ch21.xml index 0fb48620..378b452c 100644 --- a/specs/XKB/ch21.xml +++ b/specs/XKB/ch21.xml @@ -134,9 +134,9 @@ keyboard feedback and the core indicator feedback may be obtained by calling as the device_spec ; the values will be returned in -dflt_kbd_id +dflt_kbd_fb and -dflt_led_id. +dflt_led_fb. @@ -476,9 +476,9 @@ The supported, unsupported, has_own_state, -dflt_kbd_fd, +dflt_kbd_fb, and -dflt_kbd_fb. +dflt_led_fb. Other fields are filled in as specified by which. @@ -598,8 +598,8 @@ the device_spec field of the structure. Only the parts of the structure indicated in the function description are updated. The -XkbDeviceInfo -Rec structure used in the function call can be obtained by calling +XkbDeviceInfoRec +structure used in the function call can be obtained by calling XkbGetDeviceInfo or can be allocated by calling XkbAllocDeviceInfo (see section 21.3). @@ -859,7 +859,9 @@ and The fields of device_info that are filled in when this request succeeds are -name, type, supported, +name, +type, +supported, and unsupported, and portions of the @@ -871,7 +873,7 @@ and portions of the as indicated by the bits set in which. The -device_info->leds +device_info->leds vector is allocated if necessary and sz_leds and @@ -1016,7 +1018,7 @@ To obtain an n_buttons is nonzero, n_buttons -XkbActions +XkbActions are linked into the XkbDeviceInfoRec structure and initialized to zero. If sz_leds is nonzero, @@ -1147,7 +1149,7 @@ To initialize an and led_id already exists in the -device_info->leds +device_info->leds 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 device_info @@ -1537,8 +1539,8 @@ extension devices other than the core keyboard device. If the is set in which, the actions for all buttons specified in device_info are set to the -XkbAction -s specified in +XkbActions + specified in device_info -> btn_acts. @@ -1604,9 +1606,7 @@ feedback for the device in question, a error results. If any of the values in device_info -> -leds --> -names +leds->names are not a valid Atom or None, a diff --git a/specs/XKB/glossary.xml b/specs/XKB/glossary.xml index f5e89a43..c4f2c204 100644 --- a/specs/XKB/glossary.xml +++ b/specs/XKB/glossary.xml @@ -580,7 +580,10 @@ keyboard bell. Some input devices may have more than one bell, identified by There are five types of components stored in the X server database of keyboard components. They correspond to the -symbols, geometry, keycodes, compat, +>symbols, +geometry, +keycodes, +compat, and types symbolic names associated with a keyboard.