libxkbcommon
1.6.0
|
This document describes the XKB_KEYMAP_FORMAT_TEXT_V1
keymap format, as implemented by libxkbcommon.
The standard database of keyboard configuration data is xkeyboard-config.
{html:2}
Code that identifies a physical key on a keyboard.
36
may represent the return key.RTRN
.See xkb_keycodes for further details.
A keysym (short for “key symbol”) is a numeric encoding of a symbol on the cap of a key.
They have a canonical name for convenience. It can be:
a
and A
for Latin scripts, alpha
“α” and ALPHA
“Α” for Greek, etc.A dead key: e.g. dead_grave
and dead_diaeresis
, corresponding respectively to the grave accent and the diaeresis diacritics.
A dead key is a special kind of key that does not generate a character by itself, but modifies the character generated by the key struck(s) immediately after.
Shift_L
, Control_R
, Caps_Lock
. See hereinafter.Left
, Pause
, Escape
, F1
.The complete list of keysyms is defined in xkbcommon/xkbcommon-keysyms.h
.
See xkb_symbols for further details on binding keysyms to keycodes.
A modifier key is a key that modifies the effect of other keys: e.g. Shift, Control, Caps Lock, etc.
The state of a modifier key (active/inactive) is encoded as a modifier index (or modifier bit or simply modifier) and has an associated unique name.
For historical reasons, modifiers are divided in two categories:
They are the 8 predefined (AKA core, X11) modifiers (see usual modifiers hereinafter).
Real modifiers ensure backward compatibility: indeed they are the actual bits used to compute the levels and are communicated via the API of xkbcommon.
Some are generic modifiers (Mod[1-5]
) that do not have a conventional interpretation and are the motivation of the introduction of virtual modifiers.
Each modifier defines a mapping to one or multiple real modifier. Real modifiers map to themselves.
The following table lists the usual modifiers present in the standard keyboard configuration. Note that this is provided for information only, as it may change depending on the user configuration.
Modifier | Type | Usual mapping | Comment |
---|---|---|---|
Shift | Real | Shift | The usual Shift |
Lock | Real | Lock | The usual Caps Lock |
Control | Real | Control | The usual Control |
Mod1 | Real | Mod1 | Not conventional |
Mod2 | Real | Mod2 | Not conventional |
Mod3 | Real | Mod3 | Not conventional |
Mod4 | Real | Mod4 | Not conventional |
Mod5 | Real | Mod5 | Not conventional |
Alt | Virtual | Mod1 | The usual Alt |
Meta | Virtual | Mod1 or Mod4 | The legacy Meta key |
NumLock | Virtual | Mod2 | The usual NumLock |
Super | Virtual | Mod4 | The usual Super/GUI |
LevelThree | Virtual | Mod3 | ISO level 3, aka AltGr |
LevelFive | Virtual | Mod5 | ISO level 5 |
A modifier key can report its state in one of the following 3 ways:
See modifiers bindings for further details.
A key may produce different results depending of the active modifiers: e.g. for a Latin script, pressing the key A produces “a” and holding Shift while pressing A produces “A”.
This various results are organized in an ordered list; the index of each entry is called a shift level or simply level. By convention the lowest level is the result when no modifier is active. Example for the key A
on latin script keyboard:
Level | Description | Keysym | Active key modifiers |
---|---|---|---|
1 | Lower case letters | a | None |
2 | Upper case letters. | A | Shift |
3 | Alternative lower case letters | ae | AltGr |
4 | Alternative upper case letters | AE | Shift + AltGr |
A key shift level is the logical state of a key corresponding to the current shift level it used.
Key shift levels are derived from the modifiers states, but not necessarily in the same way for all keys. For example, for Latin script the Caps Lock modifier selects the level 2 for alphabetic keys such as A
but has no effect on a numeric key.
There are groups of keys with the same characteristics: letters, punctuation, numeric keypad, etc. The meaning of their levels is identical and thus can be shared: this generalization is called a key type (see hereinafter).
A key type defines the levels available for a key and how to derive the active level from the modifiers states. Examples:
ONE_LEVEL
: the key has only one level, i.e. it is not affected by any modifiers. Example: the modifiers themselves.TWO_LEVEL
: the key has two levels:Shift
modifier is not active.Shift
modifier.FOUR_LEVEL
: see the example in the previous section.See xkb_types for further details.
A mapping of keycodes to symbols, actions and key types.
A user who deals with multiple languages may need two or more different layouts: e.g. a layout for Arabic and another one for English. In this context, layouts are called groups in XKB, as defined in the standard ISO/IEC 9995.
Layouts are ordered and identified by their index. Example:
In XKB world, a key action defines the effect a key has on the state of the keyboard or the state of the display server. Examples:
See the section “Key actions” for further details.
A keyboard indicator is a mean to report a specific aspect of the keyboard state.
A customizable derived state of the keyboard. Its changes creates events that can be monitored.
There are two categories:
Real indicators are those associated to a physical indicator. For example, the “Caps Lock” logical modifier controls the corresponding physical LED.
Because indicators are customizable, if one misses a “Num Lock” LED, one could define instead the “Caps Lock” indicator to activate its LED when the “Num Lock” modifier is active.
Note that the meanings of real and virtual is slightly different than the one used for modifier.
See: xkb_keycodes
to define indicators and xkb_compat
to define their effects.
The complete definition of the mapping of raw keycodes to symbols and actions. It fully defines the behavior of a keyboard.
See xkb_keymap for further details.
The XKB text format uses a syntax similar to the C programming language.
A string is surrounded by double quotes: “"
”. The following escape sequences are supported:
Escape sequence | Meaning |
---|---|
\\ | Backslash “\ ” |
\b | Backspace |
\e | Escape |
\f | Form feed |
\n | Line feed (newline) |
\r | Carriage return |
\t | Horizontal tabulation |
\v | Vertical tabulation |
\ + octal number | Corresponding ASCII character: \0 → NULL, \42 → " |
A number can be written in three forms:
1
, 123
, etc.1.23
, etc.0x
: 0x123
, 0xff
, 0xAB
, etc. A keymap consists of a single top-level xkb_keymap
block, under which are nested the following sections:
xkb_keycodes
xkb_types
xkb_compat
xkb_symbols
Overview of a keymap file:
This is the simplest section type, and is the first one to be compiled. The purpose of this is mostly to map between the hardware/evdev scancodes and XKB [keycodes]. Each key is given a name by which it can be referred to later, e.g. in the symbols section.
Statements of the form:
<TLDE> = 49; <AE01> = 10;
The above would let 49 and 10 be valid keycodes in the keymap, and assign them the names TLDE
and AE01
respectively. The format <WXYZ>
is always used to refer to a key by name.
The naming convention <AE01>
is based on the standard ISO/IEC 9995-1. It denotes the position of the key in the keyboard grid. It means: the main alphanumeric section (A
), row E
and column 01
.
The following figure illustrates the grid on a staggered standard US QWERTY keyboard. <AE01>
corresponds to the key 1
.
In the common case this just maps to the evdev scancodes from /usr/include/linux/input.h
, e.g. the following definitions:
#define KEY_GRAVE 41 #define KEY_1 2
correspond to the ones above. Similar definitions appear in the xf86-input-keyboard driver. Note that in all current keymaps there's a constant offset of 8 (for historical reasons).
Note that contrary to xkbcommon, the X11 protocol supports keycodes only up to 255
. Therefore, when interfacing with X11, keymaps and applications using keycodes beyond 255
should expect warnings.
If there's a conflict, like the same name given to different keycodes, or same keycode given different names, it is resolved according to the merge mode which applies to the definitions.
Statements of the form:
alias <MENU> = <COMP>;
Allows to refer to a previously defined key (here <COMP>
) by another name (here <MENU>
). Conflicts are handled similarly to keycode statements.
Statements of the form:
indicator 1 = "Caps Lock"; indicator 2 = "Num Lock"; indicator 3 = "Scroll Lock";
Assigns a name to the keyboard LED (AKA indicator) with the given index. The LED may be referred by this name later in the compat section and by the user.
This section is the second to be processed, after xkb_keycodes
. However, it is completely independent and could have been the first to be processed (it does not refer to specific keys as specified in the xkb_keycodes
section).
This section defines key types, which, given a key and a keyboard state (i.e. modifier state and group), determine the shift level to be used in translating the key to keysyms. These types are assigned to each group in each key, in the xkb_symbols
section.
Key types are called this way because, in a way, they really describe the "type" of the key (or more correctly, a specific group of the key). For example, an ordinary keymap will provide a type called KEYPAD
, which consists of two levels, with the second level being chosen according to the state of the Num Lock (or Shift) modifiers. Another example is a type called ONE_LEVEL
, which is usually assigned to keys such as Escape; these have just one level and are not affected by the modifier state. Yet more common examples are TWO_LEVEL
(with Shift choosing the second level), ALPHABETIC
(where Caps Lock may also choose the second level), etc.
Statements of the form:
type "FOUR_LEVEL" { ... }
The above would create a new type named FOUR_LEVEL
. The body of the definition may include statements of the following forms:
level_name[Level1] = "Base";
Mandatory for each level in the type.
Gives each level in this type a descriptive name. It isn't used for anything.
Note: A level may be specified as Level[1-8] or just a number (can be more than 8).
modifiers = Shift+Lock+LevelThree;
Mandatory, should be specified only once.
A mask of real and virtual modifiers. These are the only modifiers being considered when matching the modifier state against the type. The other modifiers, whether active or not, are masked out in the calculation.
map[Shift+LevelThree] = Level4;
Should have at least as many mappings as there are levels in the type.
If the active modifiers, masked with the type's modifiers (as stated above), match (i.e. equal) the modifiers inside the map[]
statement, then the level in the right hand side is chosen. For example, in the above, if in the current keyboard state the Shift
and LevelThree
modifiers are active, while the Lock
modifier is not, then the keysym(s) in the 4th level of the group will be returned to the user.
map[Shift+Lock+LevelThree] = Level5; preserve[Shift+Lock+LevelThree] = Lock;
When a key type is used for keysym translation, its modifiers are said to be "consumed". For example, in a simple US keymap, the "g" "g" key is assigned an ordinary ALPHABETIC
key type, whose modifiers are Shift and Lock; then for the "g" key, these two modifiers are consumed by the translation. This information is relevant for applications which further process the modifiers, since by then the consumed modifiers have already "done their part" and should be masked out.
However, sometimes even if a modifier had already affected the key translation through the type, it should not be reported as consumed, for various reasons. In this case, a preserve[]
statement can be used to augment the map entry. The modifiers inside the square brackets should match one of the map[] statements in the type (if there is no matching map entry, one mapping to Level1 is implicitly added). The right hand side should consists of modifiers from the type's modifiers; these modifiers are then "preserved" and not reported as consumed.
This section is the third to be processed, after xkb_keycodes
and xkb_types
.
Statements of the form:
interpret Num_Lock+Any { ... } interpret Shift_Lock+AnyOf(Shift+Lock) { ... }
The xkb_symbols
section (see below) allows the keymap author to perform, among other things, the following things for each key:
SetMods
or LockGroup
, to the key. Actions, like symbols, are specified for each level of each group in the key separately.vmodmap
).However, doing this for each key (or level) is tedious and inflexible. Interpret's are a mechanism to apply these settings to a bunch of keys/levels at once.
Each interpret specifies a condition by which it attaches to certain levels. The condition consists of two parts:
Any
or the NoSymbol
keysym, which always matches successfully.A modifier predicate. The predicate consists of:
A mask of real modifiers: a +
-separated list of modifiers or the special value all
, which denotes all the modifiers.
The modifiers are matched against the key's modifier map (modmap
).
AnyOfOrNone
– The modmap must either be empty or include at least one of the specified modifiers.AnyOf
– The modmap must include at least one of the specified modifiers.Any
– Alias for AnyOf(all)
.NoneOf
– The modmap must not include any of the specified modifiers.AllOf
– The modmap must include all of the specified modifiers (but may include others as well).Exactly
– The modmap must be exactly the same as the specified modifiers.Leaving out the predicate is equivalent to using AnyOfOrNone(all)
. Leaving out just the matching condition is equivalent to using Exactly
.
An interpret may also include useModMapMods = level1;
– see below.
If a level fulfils the conditions of several interprets, only the most specific one is used:
NoSymbol
condition.As described above, once an interpret "attaches" to a level, it can bind an action to that level, add one virtual modifier to the key's vmodmap, or set the key's repeat setting. You should note the following:
xkb_symbols
, the explicit setting takes precedence over the interpret.The body of the statement may include statements of the following forms (all of which are optional):
useModMapMods = level1;
When set to level1
, the interpret will only match keysyms which are on the first level of the first group of the keys. This can be useful in conjunction with e.g. a virtualModifier
statement, because virtualModifier
is an attribute of the key rather than a specific level.
Note: the other possible value is any
and is the default value.
action = LockMods(modifiers=NumLock);
Bind this action to the matching levels. See key actions for the list of available key actions.
virtualModifier = NumLock;
Add this virtual modifier to the key's vmodmap
. The given virtual modifier must be declared at the top level of the file with a virtual_modifiers
statement, e.g.:
virtual_modifiers NumLock;
repeat = True;
Set whether the key should repeat or not. Must be a boolean value.
Statements of the form:
indicator "Shift Lock" { ... }
This statement specifies the behavior and binding of the LED (AKA indicator) with the given name ("Shift Lock" above). The name should have been declared previously in the xkb_keycodes
section (see LED name statement), and given an index there. If it wasn't, it is created with the next free index.
The body of the statement describes the conditions of the keyboard state which will cause the LED to be lit. It may include the following statements:
modifiers = ScrollLock;
If the given modifiers are in the required state (see below), the LED is lit.
whichModState = Latched+Locked;
Can be any combination of:
base
, latched
, locked
, effective
any
(i.e. all of the above)none
(i.e. none of the above)compat
(legacy value, treated as effective)This will cause the respective portion of the modifier state (see struct xkb_state
) to be matched against the modifiers given in the modifiers
statement.
Here's a simple example:
indicator "Num Lock" { modifiers = NumLock; whichModState = Locked; };
Whenever the NumLock modifier is locked, the Num Lock LED will light up.
groups = All - group1;
If the given groups are in the required state (see below), the LED is lit.
whichGroupState = Effective;
Can be any combination of:
base
, latched
, locked
, effective
any
(i.e. all of the above)none
(i.e. none of the above)This will cause the respective portion of the group state (see struct xkb_state
) to be matched against the groups given in the groups
statement.
Note: the above conditions are disjunctive, i.e. if any of them are satisfied the LED is lit.
setMods.clearLocks= True;
This section is the fourth to be processed, after xkb_keycodes
, xkb_types
and xkb_compat
.
Statements of the form:
xkb_symbols "basic" { ... }
Declare a symbols map named basic
. Statements inside the curly braces only affect the symbols map.
A map can have various flags applied to it above the statement, separated by whitespace:
partial alphanumeric_keys xkb_symbols "basic" { ... }
The possible flags are:
partial
- Indicates that the map doesn't cover a complete keyboard.default
- Marks the symbol map as the default map in the file when no explicit map is specified. If no map is marked as a default, the first map in the file is the default.hidden
- Variant that can only be used internallyalphanumeric_keys
- Indicates that the map contains alphanumeric keysmodifier_keys
- Indicates that the map contains modifier keyskeypad_keys
- Indicates that the map contains keypad keysfunction_keys
- Indicates that the map contains function keysalternate_group
- Indicates that the map contains keys for an alternate groupIf no *_keys
flags are supplied, then the map is assumed to cover a complete keyboard.
At present, except for default
, none of the flags affect key processing in libxkbcommon, and only serve as metadata.
Statements of the form:
name[Group1] = "US/ASCII"; groupName[1] = "US/ASCII";
Gives the name "US/ASCII" to the first group of symbols. Other groups can be named using a different group index (ex: Group2
), and with a different name. A group must be named.
group
and groupName
mean the same thing, and the Group
in Group1
is optional.
Statements of the form:
include "nokia_vndr/rx-51(nordic_base)"
Will include data from another xkb_symbols
section, possibly located in another file. Here it would include the xkb_symbols
section called nordic_base
, from the file rx-51
located in the nokia_vndr
folder, itself located in an XKB include path.
Statements of the form:
key <AD01> { [ q, Q ] };
Describes the mapping of a keycode <AD01>
to a given group of symbols. The possible keycodes are the keycodes defined in the xkb_keycodes
section.
Symbols are named using the symbolic names from the xkbcommon/xkbcommon-keysyms.h
file. A group of symbols is enclosed in brackets and separated by commas. Each element of the symbol arrays corresponds to a different modifier level. In this example, the symbol (keysym) XKB_KEY_q
for level 1 and XKB_KEY_Q
for level 2.
For further details see key actions.
Each group represents a list of symbols mapped to a keycode:
name[Group1]= "US/ASCII"; name[Group2]= "Russian"; ... key <AD01> { [ q, Q ], [ Cyrillic_shorti, Cyrillic_SHORTI ] };
A long-form syntax can also be used:
key <AD01> { symbols[Group1]= [ q, Q ], symbols[Group2]= [ Cyrillic_shorti, Cyrillic_SHORTI ] };
Groups can also be omitted, but the brackets must be present. The following statement only defines the Group3 of a mapping:
key <AD01> { [], [], [ q, Q ] };
Statements of the form:
virtual_modifiers LControl;
Can appear in the xkb_types
, xkb_compat
, xkb_symbols
sections.
Modifiers are a particularly tricky part of XKB. For historical reasons they are divided in two categories: real modifiers and virtual modifiers.
Note that in X11, the maximum of virtual modifiers is 16 (see XkbNumVirtualMods
).
The following table summarizes the modifiers defined in xkeyboard-config
(this is subject to change).
Modifier | Type | Compat files | Associated keysyms |
---|---|---|---|
Shift | Real | compat/basic | Shift_L , Shift_R |
″ | ″ | compat/iso9995 | Shift_L , Shift_R , ISO_Level2_Latch |
Lock | Real | compat/basic , | Caps_Lock |
″ | ″ | compat/caps | ″ |
Control | Real | compat/basic | Control_L , Control_R |
Alt | Virtual | compat/misc , | Alt_L , Alt_R |
″ | ″ | compat/pc | ″ |
Meta | Virtual | compat/misc | Meta_L , Meta_R |
Super | Virtual | compat/misc | Super_L , Super_R |
Hyper | Virtual | compat/misc | Hyper_L , Hyper_R |
ScrollLock | Virtual | compat/misc | Scroll_Lock |
NumLock | Virtual | compat/basic , | Num_Lock , |
″ | ″ | compat/level5 | (ISO_Level5_Lock ) |
LevelThree | Virtual | compat/iso9995 | ISO_Level3_Shift , ISO_Level3_Latch , ISO_Level3_Lock |
LevelFive | Virtual | compat/level5 | ISO_Level5_Shift , ISO_Level5_Latch , ISO_Level5_Lock |
Kana_Lock | Virtual | compat/japan | Kana_Lock |
Square | Virtual | compat/olpc | KP_Home |
Cross | Virtual | compat/olpc | KP_Next |
Circle | Virtual | compat/olpc | KP_End |
Triangle | Virtual | compat/olpc | KP_Prior |
We will use the example of the real modifier Shift
and the virtual modifier LevelThree
in xkeyboard-config
.
In order to define and use a modifier, one must:
Define its behavior and keysym binding in the xkb_compat
section:
```c // Declare virtual modifiers. Shift being real modifier, // we do not need to add it here. virtual_modifiers LevelThree;
// Set defaults. They are overridden if set directly in the xkb_symbols. interpret.repeat= False; // only applied on first level setMods.clearLocks= True; latchMods.clearLocks= True; latchMods.latchToLock= True;
// Default statement for real modifiers: any key bound to a real // modifier via modifier_map will set this modifier at all its // levels. // Here only to illustrate: do not add it! interpret Any + Any { action= SetMods(modifiers=modMapMods); };
// Shift being real modifier, we do not need a corresponding // interpret statement because the previous one suffices.
// Let’s associate LevelThree to the keysym ISO_Level3_Shift
// First, match the keys and their levels with the // ISO_Level3_Shift keysym and with any real modifier // (Any = AnyOf(all)) in its modmap. interpret ISO_Level3_Shift+Any { // Only match the first level of the first group useModMapMods= level1; // Add the virtual modifier to the key’s vmodmap virtualModifier= LevelThree; // Activate the LevelThree modifier (depressed mode) action= SetMods(modifiers=LevelThree); };
// Then for keys and their levels with the // ISO_Level3_Shift keysym but with either no real modifier // in its modmap or a level higher than 1. // Indeed: // • In case the level is higher than 1 there is no match // in the previous statement. // • The condition is equivalent to // ISO_Level3_Shift+AnyOfOrNone(all), but since // the previous statement ISO_Level3_Shift+Any is more // specific, it will be matched before this one. interpret ISO_Level3_Shift { // Activate the LevelThree modifier (depressed mode) action= SetMods(modifiers=LevelThree); }; ```
Define key types that use it in the xkb_types
section:
```c // Declare virtual modifiers. Shift being real modifier, // we do not need to add it here. virtual_modifiers LevelThree;
type "FOUR_LEVEL" { // Key type modifier mask: all the modifiers used in the key type modifiers = Shift + LevelThree; map[None] = Level1; mapShift = Level2; map[LevelThree] = Level3; map[Shift+LevelThree] = Level4; level_name[Level1] = "Base"; level_name[Level2] = "Shift"; level_name[Level3] = "AltGr"; level_name[Level4] = "Shift AltGr"; }; ```
Bind it to a keycode in the xkb_symbols
section:
xkb_compat
section hereinabove.modifier_map
.Note: Only one key binding to real modifier is required. The corresponding keysym must then be on the first level of the first Group.
Note: One can optionally bind directly a virtual modifier to a key using virtualmodifiers
instead of doing it in the xkb_compat
section. But the recommended way is to use the xkb_compat
section.
```c // Shift: defined in pc symbols key <LFSH> {[ Shift_L ]}; key <RTSH> {[ Shift_R ]}; modifier_map Shift { Shift_L, Shift_R }; // The previous will resolve to: // modifier_map Shift { <LFSH>, <RTSH> }; // Thus the real modifier Shift is added to the modmap of // <LFSH> and <RTSH>. // The “Any + Any” interpret statement matches <LFSH> and <RTSH>, // therefore these keys set the Shift modifier.
// LevelThree: defined in pc symbols // With the following 2 lines: // 1. The modifier keysym is on the first level of the first group. // 2. The real modifier Mod5 is bound to <LVL3>, // i.e. Mod5 is added to its modmap. // 3. It matches the interpret statement “ISO_Level3_Shift+Any”, // which adds the LevelThree modifier to the vmodmap of <LVL3>. // 4. The mapping of LevelThree to real modifiers is the union // of modmaps with corresponding vmodmaps containing // LevelThree. In our case there is only one: therefore // LevelThree maps to Mod5. key <LVL3> {[ ISO_Level3_Shift ]}; modifier_map Mod5 { <LVL3> };
// LevelThree: defined in level3 symbols // Not bound to a real modifier, so interpret statement // “ISO_Level3_Shift” applies. key <RALT> {[ISO_Level3_Shift], type[group1]="ONE_LEVEL" };
// Note: we could have the following line, but it is not necessary // because we have the mappings of <LVL3>. // modifier_map Mod5 { <RALT> };
// Warning: if we had the for example the following line, the // mapping of LevelThree to real modifiers would be “Mod1+Mod5”. // modifier_map Mod1 { <RALT> };
// Alternative definitions, without using interpret statements virtual_modifiers LevelThree; key <LVL3> { virtualmodifiers=LevelThree , repeats=False , symbols[Group1] = [ISO_Level3_Shift] , actions[Group1] = [SetMods(modifiers=LevelThree)] }; modifier_map Mod5 { <LVL3> }; key <RALT> { repeat=False , symbols[Group1] = [ISO_Level3_Shift] , actions[Group1] = [SetMods(modifiers=LevelThree)] , type[group1]="ONE_LEVEL" };
// FOUR_LEVEL key type example from latin symbols key <AB05> {[b, B, leftdoublequotemark, leftsinglequotemark]}; ```
The following table provide an overview of the available actions:
Category | Action | Alias | Description |
---|---|---|---|
NoAction | Do nothing. | ||
Modifier action | SetMods | Modifies the depressed modifiers | |
^ | LatchMods | Modifies the latched modifiers | |
^ | LockMods | Modifies the locked modifiers | |
Group action | SetGroup | TODO | |
^ | LatchGroup | TODO | |
^ | LockGroup | TODO | |
Legacy action | MovePointer | MovePtr | TODO |
^ | PointerButton | PtrBtn | TODO |
^ | LockPointerButton | LockPtrBtn | TODO |
^ | SetPointerDefault | SetPtrDflt | TODO |
^ | SetControls | TODO | |
^ | LockControls | TODO | |
^ | TerminateServer | Terminate | TODO |
^ | SwitchScreen | TODO | |
^ | Private | TODO |
Common syntax:
true
, yes
, on
false
, no
, off
There are 3 modifiers actions:
SetMods
Modifies the depressed modifiers.
Parameters:
modifiers
or mods
: the list of modifiers to modify, separated by +
, or the special value modMapMods
. The latter means the parameter value has to be read from the vmodmap
attribute of the key.clearLocks
: boolean (see its use hereinafter). LatchMods
Modifies the latched modifiers
Parameters:
modifiers
or mods
: see SetMods
.clearLocks
: boolean (see its use hereinafter).latchToLock
: boolean (see its use hereinafter). LockMods
Modifies the locked modifiers.
Parameters:
modifiers
or mods
: see SetMods
.affect
:lock
: the action only locks the modifier, but cannot unlock it.unlock
: the action only unlocks modifier, but cannot lock it.both
: the first key press locks the modifier and the second key press releases the modifier. It is a default mode.neither
: do not lock nor unlock, i.e. do nothing. These actions perform different tasks on key press and on key release:
Action
On key press
On key release
SetMods
clearLocks=yes
and no other key were operated simultaneously with this key, then the modifiers will be removed as well from the locked modifiers. LatchMods
clearLocks=yes
and no other key has been pressed since this key press, then the modifiers will be removed as well from the locked modifiers. latchToLock=yes
then the modifiers are added to the locked modifiers. LockMods
There are 3 group actions:
xkeyboard-config
for both X11 and Wayland.Action | Alias | Description |
---|---|---|
MovePointer | MovePtr | |
PointerButton | PtrBtn | |
LockPtrButton | LockPtrBtn | |
LockPointerButton | LockPointerBtn | |
SetPointerDefault | SetPtrDflt |
SetControls
, LockControls
TerminateServer
, SwitchScreen
Private