(xemacs.info)Super and Hyper Keys
2.1.5 Assignment of the <SUPER> and <HYPER> Keys
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
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
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
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',
1. Scan the existing modifier mappings.
1. If it finds a modifier that contains a keycode whose set of
keysyms includes `XK_Meta_L' or `XK_Meta_R', it should use
that modifier bit.
2. If there is no existing modifier controlled by `XK_Meta_L' or
`XK_Meta_R', it should select an unused modifier bit (one with
an empty controlling set) and:
2. If there is a keycode with `XL_Meta_L' in its set of keysyms, add
that keycode to the set for the chosen modifier, and then:
1. If there is a keycode with `XL_Meta_R' in its set of keysyms,
add that keycode to the set for the chosen modifier, and then:
2. If the controlling set is still empty, interact with the user
to select one or more keys to be `Meta'.
3. If there are no unused modifier bits, ask the user to take
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.
automatically generated by info2www version 220.127.116.11