X keyboard extension
From Wikipedia, the free encyclopedia
In the X Window System, the X keyboard extension or XKB extends the ability to control the keyboard over what is offered by the X Window System core protocol. The main features of this extension are:
- enhanced support for modifiers;
- better treatment of key groups;
- extended control of keyboard indicators (LEDs) and bells;
- various new keyboard parameters (controls);
- association of actions (of a particular kind) to keys;
The extension is composed of two parts: a server extension and a client library. Modern versions of Xlib contain the keyboard extension, which is active by default. Client programs not using this extension can deactivate it before connecting with the server, or can simply work normally as the extension simulates the core protocol by default.
Contents |
[edit] Latched and locked modifiers
The X keyboard extension allows a modifier to be locked or latched, other than being in its regular state. Normally, a modifier is active exactly when it is pressed, like the Shift. However, a modifier may also be locked, like the caps lock modifier. In particular, when a modifier is locked it remains active until it is explicitly deactivated. An intermediate condition between regular and locked is the latched state: when a modifier is latched it remains active, but only until the next non-modifier key is pressed.
The keyboard extension allows a client application to explicitly latch or lock a modifier. Moreover, an application can bind a key press or release to a modifier state change. This way, a modifier may automatically become latched or locked whenever a key is pressed or released.
[edit] Key groups
The X keyboard extension allows for the keyboard to switch between different character groups. This is usually done for making a keyboard behave like a keyboard of a different language. In this context, the set of characters that are generated by the keyboard are called a group, and a keyboard can switch to a different group at any time.
Like for modifier, the X keyboard extension define some group selectors (called simply group in the specification). Like for modifiers, a group selector can be associated to a key, but can also be latched or locked.
[edit] Controls
The behavior of the keyboard depends on a number of parameters that can be changed by the clients. These parameters are called controls. For example, the SlowKey control can be used to ignore short keypresses. Another control is the MouseKeys, which makes some keypresses to simulate mouse movements. The control only indicates whether this simulation is active or not; which keys produce the movement is not considered a part of the control, but is specified by attaching actions to these keys.
The above two controls are boolean: they are either active or not. The PerKeyRepeat is a control that is not boolean. Namely, it is a mask that says which keys are in autorepeat mode. According to the specification, non-boolean controls are "always active": that means that they always depends on a set of parameters (in this case, the mask), but that there is no single bit that can be used to deactivate the effects of the control completely.
Other than being Boolean or non-Boolean, controls also classifies as affecting the behavior of the server and affecting the behavior of the client library. The two above are server controls. Client library controls affect the translation of a keycode or a sequence of keycodes into a string (XLookupString) and event delivery.
[edit] Actions
The keyboard extension allows for associating some actions to key presses. This partly solves the problem of the X Window System that any input activity noticed by the server has to be reported to the client, which decides the correct action to take. The actions that can be associated to keys are however limited to the following ones:
- Change the state of a modifier, making it active, deactive, latched or locked
- Change the state of the group selectors (same as modifiers)
- Simulate a mouse event (movement or button activity)
- Change the active screen (this kind of action is optional, that is, not necessarily supported by the server)
- Change the state of boolean controls
- Generate a message event (that is, a packet that is sent to the client)
- Generate a different keycode
Moreover, there are some actions related to devices, if the server supports the X Input extension.
[edit] Other
The keyboard extension allows for a better handling of keyboard indicators (LEDs). In particular, XKB provides symbolic names for indicators, allows bounding them to keyboard activity, and allows checking which LEDs are actually present on the keyboard.
The keyboard extension also improves over the core protocol on the handling of bells. The core protocol only supports one bell and the only action a client can perform is to ring the bell. XKB supports multiple named bells and allows a client to deactivate some of them and being informed of when a bell is rung.
One of the feature of this extension is that a client can ask the server what is the physical shape of the keyboard and of the individual keys. In particular, keys are arranged into sections, possibly rotated (as an example, the numeric keypad is typically considered a section). Within a section, keys are arranged into rows. Keys and sections have a geometry, which comprise the approximate outline of the key, its bounding box, and the precise form. Other than keys, the geometry also includes doodads, which are elements on the keyboard that are not keys. The overall shape of the keyboard is a doodad. Other doodads are, I presume, the leds. Other information about doodads are their color, the text printed on them (if any) and its font.
[edit] References
[edit] External links
- Creating custom keyboard layouts for X11 using XKB
- Detailed information on the various XKB Configuration files
- An Unreliable Guide to XKB Configuration
|
||||||||||||||||||||
