There are a lot of players between your keyboard and the process that finally handles the keyboard event. Among the major pieces of the landscape are the fact that the X system has its own keyboard-handling layer, and X associates different "keycodes" with keys than your Linux base system does. The showkey
command is showing you the keycodes in Linux-base-system lingo. For xmodmap
you need the X keycodes, which are what xev
is displaying. So long as you're planning to work in X and do your key rebinding with xmodmap
, then, ignore showkeys
and just listen to what xev
says.
What you want to look for in your xev
output are blocks like this:
KeyPress event, serial 27, synthetic NO, window 0x1200001,
root 0x101, subw 0x0, time 6417361, (340,373), root:(342,393),
state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 27, synthetic NO, window 0x1200001,
root 0x101, subw 0x0, time 6417474, (340,373), root:(342,393),
state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
xev
tends to generate a lot of output, especially when you move your mouse. You may have to scroll back a while to find the output you're looking for. In the previous output, we see that the keysym Alt_L
is associated with the X keycode 64
.
From Remap Caps Lock:
man xmodmap shows how to swap the left
control key and the CapsLock key:
!
! Swap Caps_Lock and Control_L
!
remove Lock = Caps_Lock
remove Control = Control_L
remove Lock = Control_L
remove Control = Caps_Lock
keysym Control_L = Caps_Lock
keysym Caps_Lock = Control_L
add Lock = Caps_Lock
add Control = Control_L
Those keysym
lines are important since they're the ones that are mapping the keycodes to the opposing keys, i.e. keycode for Capslock goes to Control L and vice versa.
excerpt from the xmodmap man page*
keysym KEYSYMNAME = KEYSYMNAME ...
The KEYSYMNAME on the left hand side is translated into matching
keycodes used to perform the corresponding set of keycode
expressions. Note that if the same keysym is bound to multiple
keys, the expression is executed for each matching keycode.
Seeing the effect
You can use the tool xev
to see that the keys have been literally remapped. So Capslock now sends the scancode for Control L.
Example
Pressing Capslock sends Control L.
$ xev
KeyPress event, serial 36, synthetic NO, window 0x3e00001,
root 0x86, subw 0x0, time 890946390, (803,237), root:(804,294),
state 0x2, keycode 66 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 36, synthetic NO, window 0x3e00001,
root 0x86, subw 0x0, time 890946462, (803,237), root:(804,294),
state 0x6, keycode 66 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
Pressing Control L sends Capslock.
$ xev
KeyPress event, serial 36, synthetic NO, window 0x3e00001,
root 0x86, subw 0x0, time 891083183, (793,9), root:(794,66),
state 0x0, keycode 37 (keysym 0xffe5, Caps_Lock), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 36, synthetic NO, window 0x3e00001,
root 0x86, subw 0x0, time 891083302, (793,9), root:(794,66),
state 0x2, keycode 37 (keysym 0xffe5, Caps_Lock), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
References
Best Answer
I had this problem with the xmodmap command to freeze the system for ~20 seconds. It appeared that I had the whole keymap in my
.Xmodmap
file, which forced xmodmap to remap every row in the config file.This is how I solved that:
Before initiating custom xmodmap config: