Next: Character Representation, Previous: Meta Key, Up: Keystrokes [Contents][Index]
Most keyboards do not, by default, have SUPER or HYPER
modifier keys. Under X, you can simulate the SUPER or
HYPER key if you want to bind keys to sequences using super
and hyper. You can use the xmodmap
program to do this.
For example, to turn your CAPS-LOCK key into a SUPER key, do the following:
Create a file called ~/.xmodmap
. In this file, place the lines
remove Lock = Caps_Lock keysym Caps_Lock = Super_L add Mod2 = Super_L
The first line says that the key that is currently called Caps_Lock
should no longer behave as a “lock” key. The second line says that
this should now be called Super_L
instead. The third line says that
the key called Super_L
should be a modifier key, which produces the
Mod2
modifier.
To create a META or HYPER key instead of a SUPER key,
replace the word Super
above with Meta
or Hyper
.
Just after you start up X, execute the command xmodmap /.xmodmap
.
You can add this command to the appropriate initialization file to have
the command executed automatically.
If you have problems, see the documentation for the xmodmap
program. The X keyboard model is quite complicated, and explaining
it is beyond the scope of this manual. However, we reprint the
following description from the X Protocol document for your convenience:
A list of keysyms is associated with each keycode. If that list
(ignoring trailing NoSymbol
entries) is a single keysym ‘K’,
then the list is treated as if it were the list
``K NoSymbol K NoSymbol''
. If the list (ignoring trailing
NoSymbol
entries) is a pair of keysyms ‘K1 K2’, then the
list is treated as if it were the list ``K1 K2 K1 K2''
. If the
list (ignoring trailing NoSymbol
entries) is a triple of keysyms
‘K1 K2 K3’, then the list is treated as if it were the list
``K1 K2 K3 NoSymbol''
.
The first four elements of the list are split into two groups of keysyms. Group 1 contains the first and second keysyms; Group 2 contains third and fourth keysyms. Within each group, if the second element of the group is NoSymbol, then the group should be treated as if the second element were the same as the first element, except when the first element is an alphabetic keysym ‘K’ for which both lowercase and uppercase forms are defined. In that case, the group should be treated as if the first element were the lowercase form of ‘K’ and the second element were the uppercase form of ‘K’.
The standard rules for obtaining a keysym from a KeyPress event make use of only the Group 1 and Group 2 keysyms; no interpretation of other keysyms in the list is given here. (That is, the last four keysyms are unused.)
Which group to use is determined by modifier state. Switching between
groups is controlled by the keysym named Mode_switch
. Attach that
keysym to some keycode and attach that keycode to any one of the
modifiers Mod1 through Mod5. This modifier is called the group
modifier. For any keycode, Group 1 is used when the group modifier is
off, and Group 2 is used when the group modifier is on.
Within a group, which keysym to use is also determined by modifier
state. The first keysym is used when the Shift
and Lock
modifiers are off. The second keysym is used when the Shift
modifier is on, or when the Lock
modifier is on and the second
keysym is uppercase alphabetic, or when the Lock
modifier is on
and is interpreted as ShiftLock
. Otherwise, when the Lock
modifier is on and is interpreted as CapsLock
, the state of the
Shift
modifier is applied first to select a keysym,
but if that keysym is lower-case alphabetic, then the corresponding
upper-case keysym is used instead.
In addition to the above information on keysyms, we also provide the following description of modifier mapping from the InterClient Communications Conventions Manual:
X11 supports 8 modifier bits, of which 3 are pre-assigned to
Shift
, Lock
, and Control
. Each modifier bit is
controlled by the state of a set of keys, and these sets are specified
in a table accessed by GetModifierMapping()
and
SetModifierMapping()
.
A client needing to use one of the pre-assigned modifiers should assume
that the modifier table has been set up correctly to control these
modifiers. The Lock
modifier should be interpreted as Caps
Lock
or Shift Lock
according to whether the keycodes in its
controlling set include XK_Caps_Lock
or XK_Shift_Lock
.
Clients should determine the meaning of a modifier bit from the keysyms being used to control it.
A client needing to use an extra modifier, for example Meta
, should:
XK_Meta_L
or XK_Meta_R
, it should use that
modifier bit.
XK_Meta_L
or
XK_Meta_R
, it should select an unused modifier bit (one with
an empty controlling set) and:
XL_Meta_L
in its set of keysyms,
add that keycode to the set for the chosen modifier, and then:
XL_Meta_R
in its set of keysyms,
add that keycode to the set for the chosen modifier, and then:
Meta
.
This means that the Mod1
modifier does not necessarily mean
Meta
, although some applications (such as twm and emacs 18)
assume that. Any of the five unassigned modifier bits could mean
Meta
; what matters is that a modifier bit is generated by a
keycode which is bound to the keysym Meta_L
or Meta_R
.
Therefore, if you want to make a META key, the right way
is to make the keycode in question generate both a Meta
keysym
and some previously-unassigned modifier bit.
Next: Character Representation, Previous: Meta Key, Up: Keystrokes [Contents][Index]