making caps lock a control retains 'lock' modifier

[Ivo Timmermans]

Binary package hint: gnome-control-center

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://www.archivum.info/gnu.emacs.bug/2008-08/msg00978.html , which is that pressing control+p or control+n in a recent emacs cvs build causes the mark to be set. Reading on in the thread, this message http://www.archivum.info/gnu.emacs.bug/2008-08/msg00967.html seems to suggest that shift+control+p is actually passed to the application.

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/gnome-keyboard-properties
NonfreeKernelModules: fglrx
Package: gnome-control-center 1:2.24.0.1-0ubuntu7.1
ProcEnviron:
 SHELL=/bin/zsh
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
 LANG=nl_NL.UTF-8
SourcePackage: gnome-control-center
Uname: Linux 2.6.27-11-generic x86_64

[Sebastien Bacher (seb128)]

the GNOME capplet only use xkeyboard options

[Ivo Timmermans (ivo)]

In jaunty, this is no longer a problem.