I use Option "XKbOptions" "ctrl:nocaps" to turn my Caps lock key into another Control key. Twice in the recent past this mapping has failed and my Caps Lock key resumed being a Caps Lock key, and there was much gnashing of teeth. The first time it happened, I'm not sure what caused it, but restarting the X server "solved" the problem. The second time was right after I did a /etc/init.d/udev --nodeps restart while following some post-install instructions for sys-fs/udev-208 . How do I restore the ctrl:nocaps behavior without restarting X? Unplugging and replugging the keyboard does NOT solve the problem. Using Ctrl-Alt-F1 to switch to a text terminal and then Ctrl-F7 to go back to X does not solve the problem. Reproducible: Always Steps to Reproduce: I have the following clause in my /etc/X11/xorg.conf: Section "InputDevice" Identifier "Keyboard0" Driver "evdev" Option "XKbOptions" "ctrl:nocaps" Option "XKbOptions" "terminate:ctrl_alt_bksp" EndSection Start X. Verify that your caps lock is behaving as a Control key. # /etc/init.d/udev --nodeps restart Test the caps lock key. It now behaves as a caps lock key. Actual Results: The caps lock key is a caps lock key instead of a control key Expected Results: My caps lock key should have stayed a control key
After a little more digging I was able to find a workaround: setxkbmap -option "ctrl:nocaps" restores my configuration, although I also have to re-apply my xmodmap. thoth@farafra ~ $ setxkbmap -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us+inet(evdev)+ctrl(nocaps)" }; xkb_geometry { include "pc(pc104)" }; }; farafra thoth # /etc/init.d/udev --nodeps restart * Stopping udev ... [ ok ] * Starting udev ... [ ok ] * Generating a rule to create a /dev/root symlink ... [ ok ] * Populating /dev with existing devices through uevents ... [ ok ] * Waiting for uevents to be processed ... [ ok ] thoth@farafra ~ $ setxkbmap -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us+inet(evdev)" }; xkb_geometry { include "pc(pc104)" }; }; shows the mapping being lost.
Perhaps you shouldn't hard-code such things in xorg.conf any longer. I am not even sure this is a bug.
InputDevice sections are obsolete for setups that use udev for input configuration. Please use InputClass sections. You can find examples in /usr/share/X11/xorg.conf.d/10-evdev.conf If that does not help, please try to reproduce this in a failsafe X11 session (only xterm) to make sure that no desktop environment is interfering here. Also attach Xorg.0.log from after restarting udev and unplugging/replugging the keyboard.
Yeah, this machine is pretty old, and the conf was probably copied and modified from an even older machine. Getting nvidia to do multiple monitors properly has a lot of badly-handled corner cases. I switched over to using /etc/X11/xorg.conf.d/ and am using a 10-evdev.conf that looks like this: Section "InputClass" Identifier "catch-all keyboard config" MatchIsKeyboard "on" MatchDevicepath "/dev/input/event*" Driver "evdev" Option "XKbOptions" "terminate:ctrl_alt_bksp,ctrl:nocaps" EndSection Unfortunately, the xmodmap settings are still getting lost. I use remove Mod4 = Super_L add Mod1 = Super_L to turn my left super key into an extra alt key.
The NVidia driver can also cause problems here, please try without it (also prevent the nvidia kernel module from loading during boot).
hmm, is this related? http://cgit.freedesktop.org/systemd/systemd/commit/?id=49804365ea1242456c9763058a59cf68479e07ea the fix is not yet in udev-212, but will be in udev-213
