Guess what happens when you use software that can fuck up your keyboard mappings (VMware Remote Console), in combination with software that uses these mappings to be able to switch back to a text console (X.org) and a screen saver that locks your screen (gnome-screensaver, but that would worl equally well with xlock or anything else similar) ? A recipe for FAIL.
It so happens that VMware Remote Console, and apparently other VMware products such as Player or Workstation not only are unable to do anything useful with special keys (try installing Debian without the arrows keys, for example), but they are also able to remap keys (such as ctrl, shift and caps lock) to nothing.
It also happens that X.org uses its keyboard mappings when dealing with the ctrl+alt+Fn key combinations that allow to get back to a text console. Yes, that means you can’t switch to a text console after VMware fucked up your keyboard mappings.
On top of all that, add a X session locking program, that won’t allow you back until you type your password, and a password that, well, you just can’t type without shift of caps-lock, because it is somehow strong. The X session locking program won’t allow you to fix your keyboard mappings, you can’t switch to a text console either, and you can’t unlock for obvious reasons.
The only solution that didn’t involve a reboot or losing everything under the X session was to ssh in, change the password to one that can be typed without shift and unlock.
It is said on the interwebs that adding “
xkeymap.nokeycodeMap = true” in the
~/.vmware/config file solves the issue. At least, it works for the arrows. I’ll see if it also prevents the special keys to be remapped.