Setting capslock to control in gnome keyboard preferences leaves capslock stuck on

Thank you for your bug. No reason that the tool should force a mode you didn't choose, closing the request that's not a bug

Granted, this shouldn't be a high priority bug, and it's a point of minor polish. But I doubt that the current behavior is ever what the user wants. People are going to be editing their layout options if they want to remap their keys, not to try and force capslock to always be on (and even if this were the case, they'd simply be stuck with it off after the next reboot). If you can come up with some possible use scenarios, I'm all ears. Whether or not the user deliberately chooses a mode doesn't change that Ubuntu simply isn't doing what they want.

I've opened the request upstream on http://bugzilla.gnome.org/show_bug.cgi?id=432595

Upstream says:

 Comment #1 from Sergey V. Udaltsov (developer, points: 14)
2007-04-23 22:46 UTC [reply]

This is NOTGNOME. It is an issue with your x server (if it is xorg, file a bug
against xkeyboard-config component).

This is similar to Bug #173350
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/173350
a work around given there is:
xmodmap -e "clear lock" -e "add lock = Caps_Lock"

I found a better workaround. I'm using Hardy beta.

Do not use gnome's keyboard control (Ubuntu System > Preferences > Keyboard > Layout Options).
Instead follow the example in man xmodmap as explained below.

NOTE: before doing this, undo any changes in Keyboard layout options. Put the options back to defaults in gnome's keyboard control.

And, if you have done anything advanced to try to work around this issue, remove those modifications too. For example, the following is NOT needed so if you are using it, remove it (may require a restart):
 xmodmap -e "clear lock" -e "add lock = Caps_Lock"

Put the following in a text file.

            !
            ! Swap Caps_Lock and Control_L
            !
            remove Lock = Caps_Lock
            remove Control = Control_L
            keysym Control_L = Caps_Lock
            keysym Caps_Lock = Control_L
            add Lock = Caps_Lock
            add Control = Control_L

save the above as /etc/SwapCapsCtrl.kmap

then, from a terminal, run:
xmodmap /etc/SwapCapsCtrl.kmap

To make the change permanent, do this:
edit /etc/rc.local
add the following before the last line that says 'exit 0'
sudo loadkeys /etc/SwapCapsCtrl.kmap

MountainX, you don't need sudo in /etc/rc.local. It runs as root on bootup, like all init scripts.

Are you sure your loadkeys method even works? loadkeys is a totally different way to change your keymap: It changes the Linux kernel keymap. I though X put the kbd in raw mode, and got keycodes which weren't affected by Linux's keymap, but maybe I'm remembering wrong or it's changed in the few years since I've used loadkeys instead of just xkb options. I don't think loadkeys even accepts the same syntax as xmodmap; loadkeys(1) and keymaps(5) don't say anything about "add" lines.

 The easiest way to swap ctrl and caps (for X11, doesn't affect the text consoles like loadkeys) is to set the xkb option ctrl:swapcaps. The defaults can be set in xorg.conf, or you could arrange for your X session startup scripts to include setxkbmap -option ctrl:swapcaps.

 I like having my capslock as an extra control (ctrl:nocaps), since some of muscle memories send my finger to the key labeled Ctrl, but capslock is right there on the home row so it's easier to reach, and where Control is on e.g. Sun and original VT100 keyboards. :) Plus, I find the Caps Lock feature useless and annoying.

Section "InputDevice"
        Identifier "Generic Keyboard"
        Driver "kbd"
# Option "CoreKeyboard"
        Option "XkbRules" "xorg"
        Option "XkbModel" "pc105"
        Option "XkbLayout" "us"
        Option "XkbOptions" "ctrl:nocaps"
        Option "Autorepeat" "200 40"
#Ubuntu default: lv3:ralt_switch ISO level 3 shift
EndSection

 Anyway, none of this has anything to do with the bug report, which was that if caps-lock is on _when_ you enable ctrl:nocaps (either with setxkbmap or with gnome), you won't be able to turn caps-lock off again, because you don't have a caps-lock key. This has happened to me, and I had to re-enable capslock, turn off capslock, then re-do the setting. (setxkbmap -option '' clears all options, BTW. Get that into your command history before you try to test this, unless you really like clicking your mouse. setxkbmap -print is interesting...)

 Strangely, X turns off the capslock LED when you hit capslock while ctrl:nocaps is set. If you hit numlock a couple times, it will sort itself out and eventually display the correct set of LEDs.

 I was going to say this isn't a gnome-keyboard-preferences bug, since it's the same problem when you use setxkbmap. But then I realized that I couldn't imagine anybody wanting caps-lock to be stuck on, so it would be a nice feature for g-k-p to turn off caps-lock if it's on before applying any setting that leaves the keyboard without a caps-lock key. That would make it more than a straight GUI equivalent of setxkbmap (with persistence, now that that works properly...)

 The X people probably wouldn't see it as a bug, either. They probably wouldn't be willing to make setting xkb options have side effects, like turning off caps-lock, since you never know what weird things people might want. GNOME should be putting the user-friendly do what almost-everyone-wants wrapping on top of thing, vs. the direct...

We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

Just marking the control-center as invalid because it is the wrong package.

By the way: Does anyone still have the problem?

 We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

I can confirm that this problem still exists under Intrepid.