making caps lock a control retains 'lock' modifier
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
xkeyboard-config (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: gnome-control-
I have used the gnome keyboard properties to make the CapsLock key an additional Control key, long ago.
Then, recently, I was having the problem described in this mail thread: http://
Running xev to verify this, pressing the CapsLock key and P together causes a KeyPress event with state set to 0x6, and pressing the left Control key and P together causes an event with state set to 0x4. After some digging with xkbcomp and xmodmap, the following lines looked suspicious to me:
lock Control_L (0x42)
control Control_L (0x25), Control_L (0x42), Control_R (0x69)
And sure enough, after an xmodmap -e 'clear lock', the state of the X event caused by CapsLock now also reads 0x4. Emacs stopped being annoying and I am happy.
So, in conclusion, the effect of the "make caps lock an additional control" option makes the X server send the wrong information in the events it generates.
ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 8.10
ExecutablePath: /usr/bin/
NonfreeKernelMo
Package: gnome-control-
ProcEnviron:
SHELL=/bin/zsh
PATH=/
LANG=nl_NL.UTF-8
SourcePackage: gnome-control-
Uname: Linux 2.6.27-11-generic x86_64
the GNOME capplet only use xkeyboard options