The X Keyboard Extension supports a number of global key controls , which affect the way that XKB handles the keyboard as a whole. Many of these controls make the keyboard more accessible to the physically impaired and are based on the AccessDOS package AccessDOS provides access to the DOS operating system for people with physical impairments and was developed by the Trace R&D Center at the University of Wisconsin. For more information on AccessDOS, contact the Trace R&D Center, Waisman Center and Department of Industrial Engineering, University of Wisconsin-Madison WI 53705-2280. Phone: 608-262-6966. e-mail: info@trace.wisc.edu.. The core protocol only allows control over whether or not the entire keyboard or individual keys should autorepeat when held down. The RepeatKeys control extends this capability by adding control over the delay until a key begins to repeat and the rate at which it repeats. RepeatKeys is also coupled with the core autorepeat control; changes to one are always reflected in the other. The RepeatKeys control has two parameters. The autorepeat delay specifies the delay between the initial press of an autorepeating key and the first generated repeat event in milliseconds. The autorepeat interval specifies the delay between all subsequent generated repeat events in milliseconds. When RepeatKeys are active, the PerKeyRepeat control specifies whether or not individual keys should autorepeat when held down. XKB provides the PerKeyRepeat for convenience only, and it always parallels the auto-repeats field of the core protocol GetKeyboardControl request — changes to one are always reflected in the other. The X server usually generates both press and release events whenever an autorepeating key is held down. If an XKB-aware client enables the DetectableAutorepeat per-client option for a keyboard, the server sends that client a key release event only when the key is physically released. For example, holding down a key to generate three characters without detectable autorepeat yields: Press -> Release -> Press -> Release -> Press -> Release If detectable autorepeat is enabled, the client instead receives: Press-> Press -> Press -> Release Note that only clients that request detectable autorepeat are affected; other clients continue to receive both press and release events for autorepeating keys. Also note that support for detectable autorepeat is optional; servers are not required to support detectable autorepeat, but they must correctly report whether or not it is supported. Querying and Changing Per-Client Flags describes the XkbPerClientFlags request, which reports or changes values for all of the per-client flags, and which lists the per-client flags that are supported. Some users often bump keys accidentally while moving their hand or typing stick toward the key they want. Usually, the keys that are bumped accidentally are hit only for a very short period of time. The SlowKeys control helps filter these accidental bumps by telling the server to wait a specified period, called the SlowKeys acceptance delay , before delivering key events. If the key is released before this period elapses, no key events are generated. The user can then bump any number of keys on their way to the one they want without generating unwanted characters. Once they have reached the key they want, they can then hold it long enough for SlowKeys to accept it. The SlowKeys control has one parameter; the slow keys delay specifies the length of time, in milliseconds, that a key must be held down before it is accepted. When SlowKeys are active, the X Keyboard Extension reports the initial press, acceptance, rejection or release of any key to interested clients using AccessXNotify events. The AccessXNotify event is described in more detail in Events. Some people with physical impairments accidentally "bounce" on a key when they press it. That is, they press it once, then accidentally press it again immediately. The BounceKeys control temporarily disables a key after it has been pressed, effectively "debouncing" the keyboard. The BounceKeys has a single parameter. The BounceKeys delay specifies the period of time, in milliseconds, that the key is disabled after it is pressed. When BounceKeys are active, the server reports the acceptance or rejection of any key to interested clients by sending an AccessXNotify event. The AccessXNotify event is described in more detail in Events. Some people find it difficult or impossible to press two keys at once. The StickyKeys control makes it easier for them to type by changing the behavior of the modifier keys. When StickyKeys are enabled, a modifier is latched when the user presses it just once, so the user can first press a modifier, release it, then press another key. For example, to get an exclamation point (!) on a PC-style keyboard, the user can press the Shift key, release it, then press the 1 key. By default, StickyKeys also allows users to lock modifier keys without requiring special locking keys. The user can press a modifier twice in a row to lock it, and then unlock it by pressing it one more time. Modifiers are automatically unlatched when the user presses a non-modifier key. For instance, to enter the sequence Shift + Ctrl + Z the user could press and release the Shift key to latch the Shift modifier, then press and release the Ctrl key to latch the Control modifier — the Ctrl key is a modifier key, so pressing it does not unlatch the Shift modifier, but leaves both the Shift and Control modifiers latched, instead. When the user presses the Z key, it will be as though the user pressed Shift + Ctrl + Z simultaneously. The Z key is not a modifier key, so the Shift and Control modifiers are unlatched after the event is generated. A locked a modifier remains in effect until the user unlocks it. For example, to enter the sequence ("XKB") on a PC-style keyboard with a typical US/ASCII layout, the user could press and release the Shift key twice to lock the Shift modifier. Then, when the user presses the 9 , ‘ , x , k , b , ‘ , and 0 keys in sequence, it will generate ("XKB"). To unlock the Shift modifier, the user can press and release the Shift key. Two option flags modify the behavior of the StickyKeys control: If the XkbAX_TwoKeys flag is set, XKB automatically turns StickyKeys off if the user presses two or more keys at once. This serves to automatically disable StickyKeys when a user who does not require sticky keys is using the keyboard. The XkbAX_LatchToLock controls the locking behavior of StickyKeys ; the StickyKeys control only locks modifiers as described above if the XkbAX_LatchToLock flag is set. The MouseKeys control lets a user control all the mouse functions from the keyboard. When MouseKeys are enabled, all keys with MouseKeys actions bound to them generate core pointer events instead of normal key press and release events. The MouseKeys control has a single parameter, the mouse keys default button , which specifies the core pointer button to be used by mouse keys actions that do not explicitly specify a button. If the MouseKeysAccel control is enabled, the effect of a pointer motion action changes as a key is held down. The mouse keys delay specifies the amount of time between the initial key press and the first repeated motion event. The mouse keys interval specifies the amount of time between repeated mouse keys events. The steps to maximum acceleration field specifies the total number of events before the key is travelling at maximum speed. The maximum acceleration field specifies the maximum acceleration. The curve parameter controls the ramp used to reach maximum acceleration. When MouseKeys are active and a SA_MovePtr key action (see Key Actions) is activated, a pointer motion event is generated immediately. If MouseKeysAccel is enabled and if acceleration is enabled for the key in question, a second event is generated after mouse keys delay milliseconds, and additional events are generated every mouse keys interval milliseconds for as long as the key is held down. If the SA_MovePtr action specifies relative motion, events are generated as follows: The initial event always moves the cursor the distance specified in the action; after steps to maximum acceleration events have been generated, all subsequent events move the pointer the distance specified in the action times the maximum acceleration. Events after the first but before maximum acceleration has been achieved are accelerated according to the formula: Where action_delta is the offset specified by the mouse keys action, max_accel and steps_to_max are parameters to the MouseKeysAccel ctrl, and the curveFactor is computed using the MouseKeysAccel curve parameter as follows: With the result that a curve of 0 causes the distance moved to increase linearly from action_delta to , and the minimum legal curve of - 1000 causes all events after the first move at max_accel . A negative curve causes an initial sharp increase in acceleration which tapers off, while a positive curve yields a slower initial increase in acceleration followed by a sharp increase as the number of pointer events generated by the action approaches steps_to_max . If an SA_MovePtr action specifies an absolute position for one of the coordinates but still allows acceleration, all repeated events contain any absolute coordinates specified in the action. If AccessXKeys is enabled many controls can also be turned on or off from the keyboard by entering the following standard key sequences: Holding down a shift key by itself for eight seconds toggles the SlowKeys control. Pressing and releasing a shift key five times in a row without any intervening key events and with less than 30 seconds delay between consecutive presses toggles the state of the StickyKeys control. Simultaneously operating two or more modifier keys deactivates the StickyKeys control. Some of these key sequences optionally generate audible feedback of the change in state, as described in The AccessXFeedback Control, or cause XkbAccessXNotify events as described in Events. In environments where computers are shared, features such as SlowKeys present a problem: if SlowKeys is on, the keyboard can appear to be unresponsive because keys have no effect unless they are held for a certain period of time. To help address this problem, XKB provides an AccessXTimeout control to automatically change the value of any global controls or AccessX options if the keyboard is idle for a specified period of time. The AccessXTimeout control has a number of parameters which affect the duration of the timeout and the features changed when the timeout expires. The AccessX Timeout field specifies the number of seconds the keyboard must be idle before the global controls and AccessX options are modified. The AccessX Options Mask field specifies which values in the AccessX Options field are to be changed, and the AccessX Options Values field specifies the new values for those options. The AccessX Controls Mask field specifies which controls are to be changed in the global set of enabled controls , and the AccessX Controls Values field specifies the new values for those controls. If AccessXFeedback is enabled, special beep-codes indicate changes in keyboard controls (or some key events when SlowKeys or StickyKeys are active). Many beep codes sound as multiple tones, but XKB reports a single XkbBellNotify event for the entire sequence of tones. All feedback tones are governed by the AudibleBell control. Individual feedback tones can be explicitly enabled or disabled using the accessX options mask or set to deactivate after an idle period using the accessX timeout options mask . XKB defines the following feedback tones: Feedback Name Bell Name Default Sound Indicates FeatureFB AX_FeatureOn rising tone Keyboard control enabled AX_FeatureOff falling tone Keyboard control disabled AX_FeatureChange two tones Several controls changed state IndicatorFB AX_IndicatorOn high tone Indicator Lit AX_IndicatorOff low tone Indicator Extinguished AX_IndicatorChange two high tones Several indicators changed state SlowWarnFB AX_SlowKeysWarning three high tones Shift key held for four seconds SKPressFB AX_SlowKeyPress single tone Key press while SlowKeys are on SKReleaseFB AX_SlowKeyRelease single tone Key release while SlowKeys are on SKAcceptFB AX_SlowKeyAccept single tone Key event accepted by SlowKeys SKRejectFB AX_SlowKeyReject low tone Key event rejected by SlowKeys StickyKeysFB AX_StickyLatch low tone then high tone Modifier latched by StickyKeys AX_StickyLock high tone Modifier locked by StickyKeys AX_StickyUnlock low tone Modifier unlocked by StickyKeys BKRejectFB AX_BounceKeysReject low tone Key event rejected by BounceKeys Implementations that cannot generate continuous tones may generate multiple beeps instead of falling and rising tones; for example, they can generate a high-pitched beep followed by a low-pitched beep instead of a continuous falling tone. If the physical keyboard bell is not very capable, attempts to simulate a continuous tone with multiple bells can sound horrible. Set the DumbBellFB AccessX option to inform the server that the keyboard bell is not very capable and that XKB should use only simple bell combinations. Keyboard capabilities vary wildly, so the sounds generated for the individual bells when the DumbBellFB option is set are implementation specific. A keyboard overlay allows some subset of the keyboard to report alternate keycodes when the overlay is enabled. For example a keyboard overlay can be used to simulate a numeric or editing keypad on keyboard that does not actually have one by generating alternate of keycodes for some keys when the overlay is enabled. This technique is very common on portable computers and embedded systems with small keyboards. XKB includes direct support for two keyboard overlays, using the Overlay1 and Overlay2 controls. When Overlay1 is enabled, all of the keys that are members of the first keyboard overlay generate an alternate keycode. When Overlay2 is enabled, all of the keys that are members of the second keyboard overlay generate an alternate keycode. To specify the overlay to which a key belongs and the alternate keycode it should generate when that overlay is enabled, assign it either the KB_Overlay1 or KB_Overlay2 key behaviors, as described in Key Behavior. All of the controls described above, along with the AudibleBell control (described in Disabling Server Generated Bells) and the IgnoreGroupLock 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 controls, the boolean controls can be individually enabled or disabled by changing the value of the EnabledControls control. The following non-boolean controls are always active and cannot be changed using the EnabledControls control or specified in any context that accepts only boolean controls: GroupsWrap (Computing Effective Modifier and Group), EnabledControls , InternalMods (Server Internal Modifiers and Ignore Locks Behavior), and IgnoreLockMods (Server Internal Modifiers and Ignore Locks Behavior) and PerKeyRepeat (The RepeatKeys Control) The auto-reset controls are a per-client value which consist of two masks that can contain any of the 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 are set to the corresponding value from the auto-reset values mask. This makes it possible for clients to "clean up after themselves" 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 Generated Bells) to prevent the server from also generating a sound and thus avoid cacophony. If the client were to exit without resetting the AudibleBell control, the user would be left without any feedback at all. Setting AudibleBell in both the auto-reset mask and auto-reset values guarantees that the audible bell will be turned back on when the client exits.