See also the GUI xkeycaps(1) with very good documentation about the keyboard model of X11.
If you are new to the keyboard model, read there first, and then come back for even more comments about subtle things.
This file contains raw iso-8859-1 (latin1) characters for documentation.
Wether you can really use special (non-ASCII, 8bit) characters, likely will depend on your locale settings.
If you have the XKEYBOARD/XKB Xserver extension (e.g. X11R6/XFree86),
then see also setxkbmap(1)
and several xkb*(1)
tools. The according file format is sort of similar to the "loadkeys"
format on some unix flavours (however, when collecting these notes,
i only used X11R5 regularly, which is not providing any XKB extension).
The best documentation i found about the XKB/XKEYBOARD extension, is
${X11SRC}/doc/hardcopy/XKB/XKBlib.ps.gz
Don't forget to search for existing and possibly appropriate keymaps
on your system before you write your own. Some Linux distributors
provide numerous mappings on their ftp server, e.g. Mandrake.
For XFree86, you should firsty properly configure
X11 uses these logical names for keys - instead of the printables
themselves or the literal names on the caps. There are KeySym-names
for really all common keys in X11, thus it stays independent from the
myriades of different physical keyboards and slightly different
namings.
See <X11/keysymdef.h> or a list of
KeySym-names and KeySyms with printables
(one should distinguish between "KeySym-names" like
"backslash", and "KeySyms" themselves, i.e. hexadecimal
values like "0x5c").
To confirm that your remapping, in particular about using modifiers,
was successful, use Apart from the regular KeySym-names / KeySyms, you can also map
arbitrary values,
using the hexadecimal KeySym-notation (up to four digits):
Related: You can add new KeySym-names to the file Only the first four elements are platform-independent and of real interest
(see below about the last four) :
Look at positions 1-4: There are two groups, each with two keys.
You get the 2nd group with 'Mode_shift'/AltGr and the second key in
each group with 'Shift'.
The fastest way, concerning typing, to
get special (e.g. latin1) characters on US/EN Keyboards
is to use "Mode_switch": For this purpose you have to map the
KeySym (XFree86 usually doesn't require the explicit mapping as modifier.
This shall apparently ease the configuring. But it's not possible to
refrain from modifiers in general.)
In contrast, the "Multi_key/Compose" mechanism doesn't need to be
also mapped as modifier and is easier to configure, but you'll have to type
more then - and not all applications support it. However older X11R5
Xservers do it completely Xserver internally, then it works always.
( Only for the sake of completeness:
If only a single key is defined in a group [certainly only possible
with the last in a complete row], then it's a shorthand for a complete
pair of a KeySym-name in small and CAPS. )
The X11R5 "X Protocol documentation" says: Take the above Solaris example as rare, platform dependent exception.
And don't be confused by Num_Lock appearing there, the very
Num_Lock mechanism is configured in a different way, with
KeySym-names being prefixed with " /usr/X11R6/include/X11/keysymdef.h:
With "ISO_Next_Group" you can switch into the next group of characters.
Example: If you map a key with the following KeySym-names,
(I only use X11R5 and thus most of my keycodes
are only mapped with four KeySyms.)
'General' order for mapping keys and modifiers: BTW, it's exactly 5 logical (extra-) modifers, because X11 uses 8 bits
for all these modifiers (control, shift, lock, The very number in Keyodes themselves are skipped here, because they are keyboard specific.
Have a look at the output of "xmodmap -pke".
(Or see an
example.
Here, mainly keysyms for special characters were added:
german umlauts, "ä ö ü ß", and many other latin1 chars,
"° µ ² ³ ©".
There is also 'ecaron' (mapped on the cap 'e'). It's an iso-latin-2-only
character, so you'll need also a font to display it. A general
example is Thomas
Dickey's (XFree86-)xterm in connection with
Markus Kuhn's
Unicode fonts.)
See <X11/keysymdef.h> or a list of
KeySym-names with printables for the names of available KeySyms.
Using the following, e.g.,
KeySyms, which are usually used as *modifier* KeySyms:
However, the XKB extension provides at least mechanisms to trigger
Pointer- and Buttonevents with the keyboard.
Things you can't do via xmodmap
Things you shouldn't do:
Certainly you may have "Meta_L" and "Meta_R" (and perhaps even
"Alt_L/R" on the same key, as long as they serve the same purpose.
Modifier KeySyms like "Mode_switch" or "Meta_L/R" have to be mapped to
an arbitrary, still free logical modifier ( When deciding how to do the mapping, you should consider:
Later on then: This however is not true in general. In Sun-X11R5 this is done
by the Xserver itself.
xkbseldb(1)
is a quite valuable tool to correct
a messed up XKB keyboard mapping (that is, xkbseldb -r; xkbseldb -lb;
xkbsel -s <mapname>).
How to use an xmodmap file:
Add a call to xmodmap(1) to your X11 startup
script. It's usually ~/.xinitrc for startx(1) and ~/.xsession for display
managers.
XF86Config
.
In the following you will read a lot
about "KeySyms"
xev(1)
and xmodmap(1)
(without options).
xmodmap -e "keycode <Keycode> = 0x<Hex-Value>"
(pointed out by Florian Weimer, de.comp.os.unix.x11 22-2-01)
XKeysymDB
(see xmodmap(1)
),
but later on those new KeySym-names will not be recognized from
XKeysymToString(3)
. Only the KeySym-value is visible
and tools like xev(1)
and xmodmap(1)
behave
accordingly then.
What's the format of a "keycode-line"?
(i.e. the result of "xmodmap -pke
" or
Suns "xmakemap
")
keycode <x> = <1> <2> <3> <4> <5> <6> <7> <8>
Solaris Openwin 3.5 (X11R5), Type-5 US keyboard
<1> <key>
<2> <shift-key>
<3> <"Mode_switch"-key>
<4> <shift-"Mode_switch"-key>
<5> <"Num_Lock"-key>
<6> -
<7> <"Num_Lock"-"Mode_switch"-key>
<8> -
Mode_switch
onto a keycode of your choice and
map it to an arbitrary, still available logical modifier, called
mod1-5
, see below
You certainly also have to provide the
KeySyms for the wanted special characters, you will usually put them in
the second group, i.e. the 3rd and 4th position.
What about position 5-8:
"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.)"
KP_
".
ISO 9995 Function and Modifier Keys
[...]
#ifdef XK_XKB_KEYS
#define XK_ISO_Group_Shift 0xFF7E /* Alias for mode_switch */
#define XK_ISO_Next_Group 0xFE08
#define XK_ISO_Prev_Group 0xFE0A
#define XK_ISO_First_Group 0xFE0C
#define XK_ISO_Last_Group 0xFE0E
keycode ... = a A ae AE dollar pound yen currency
then you get the first four with "Shift" and "Mode_switch"/AltGr as usual.
But after pressing "ISO_Next_Group" twice, you get the last four in the
same way.
The action of mapping itself
- Clear the logical modifiers,
- Then map KeySyms to keycodes,
- Finally map the logical modifiers
(xkeycaps does it 2-1-3, which works as well)
clear Shift
clear Lock
clear Control
clear Mod1
clear Mod2
clear Mod3
clear Mod4
clear Mod5
mod1-mod5
).
For more information, see <X11/X.h>,
e.g. /usr/include/X11/X.h
.
mod1-mod5
has no meaning itself
and thus shouldn't matter. However, there are a few exceptions
about wrongly hardcoded programs and also sort of broken Xserver
implementations, see below.
add shift = Shift_L Shift_R
add lock = Caps_Lock
add control = Control_L
add mod1 = Meta_L Meta_R
add mod2 = Mode_switch
add mod3 = Num_Lock
add mod4 = Alt_R
add mod5 =
results in
shift Shift_L (0x6a), Shift_R (0x75)
lock Caps_Lock
control Control_L (0x53)
mod1 Meta_L (0x7f)
mod2 Mode_switch (0x14), Mode_switch (0x1a)
mod3 Num_Lock (0x69)
mod4 Alt_R (0x81)
mod5
Shift_L/R, Control_L/R, Meta_L/R, Alt_L/R,
Num_Lock, Multi_key, Mode_switch/script_switch,
Caps_Lock, Shift_Lock, Hyper_L/R, ...
mod1-5
), for to
really get activated.
xv(1)
for example actually uses (hardcoded and wrongly)
mod1
as "Meta", e.g. for pixmap cut&paste.
Thus, Meta_L/R is 'mod1' for me always.
mod1
must be associated with "Alt" or "Meta",
see VirtualBindings(3)
.
Num_Lock
only
on Mod5.
But it's still broken then. I haven't succeded yet in properly
activating its funcionality at all.
(BTW, AIX doesn't recognize Multi_key in several terminal emulators.)
System specific:
xev(1)
is
(execpt for 2.6, 8 and 9, in /usr/openwin/demo/
)
not available The same for some versions of HP-UX. See
link for a glance at
the source then (and binaries, if you like).
There are also application specific ways for mapping
For example XTerm(1):
if you often use Meta for command line editing (bash/readline
etc, or even emacs) - and if you want to get both latin1 chars
and command line editing with the same modifier key (example:
<meta-a>: "ä", <meta-b>: "backward word"), then
you can use the 'translation tables' of libXt, e.g. in xterm(1):
XTerm.VT100.translations: #override Meta<Key>a: string("ä") \n\ [...]
post scriptum
The xkeycaps documentation mentions:
"Not all vendors support the use of the Multi_key keysym; in
particular, Digital, Sun, and HP support it, but the X Con-
sortium does not. (The reason for this, I am told, is that
``Compose'' sequences are considered obsolete; the party
line is that you should be using Input Methods to do this.)"
"Whether Multi_key works is a property of the Xt library
(not the X server) [...]"
2002-07, 2005-05, Sven Mascheck