Adventures in Linux, VMware, and Broken Keyboard Maps
I use the Control Key A LOT. When VMware broke it, I had a problem.
I just started the SANS “SEC401: Security Essentials” course, which requires VMware Workstation hypervisor to run the pre-configured VMs. Sounds like that’s true for all of SANS, and since I’ve got two more courses after this one, VMware is clearly my reality.
Problem was…. every time I would drop into a VM, the keymaps on my Linux host (Pop_OS!) would get wiped. Definitely an issue when clicking in and out of a VM while navigating online training and taking notes in Emacs Org Mode.
My go-to hypervisor on my Pop_OS daily driver is KVM/QEMU. I hear people complain about it when pushing to scale, but for my tinkering it works great. I’ve tried VirtualBox on the Linux box as well – it’s what I’ve been using on my Windows machine – but the Linux experience wasn’t great.
Look and feel of VMware Workstation has been pretty good so far… except the Control Key issue on the host is an absolute non-starter.
Bottom Line Up Front - Here’s What Worked:
- Disable any custom keyboard mapping, i.e. if you’ve mapped CAPS LOCK to CTRL like I did.
- (Also, maybe…) As root, add
xkeymap.nokeycodeMap = trueto
- This may not actually be necessary, but I did this in an earlier troubleshooting step, never un-did it, and now that things work I’m not about to re-stir the pot.
Also helpful: If you haven’t implemented the permanent fix above, but your CTRL and other modifier keys are hosed, run
setxkbmap in your terminal to reset the key bindings.
Example: Wiped Out Keybindings from using VMware
# xmodmap -pm xmodmap: up to 0 keys per modifier, (keycodes in parentheses): shift lock control mod1 mod2 mod3 mod4 mod5
Restored Keybindings after
# xmodmap -pm xmodmap: up to 3 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x69) mod1 Alt_L (0x40), Alt_R (0x6c), Meta_L (0xcd) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x85), Super_L (0xce), Hyper_L (0xcf) mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)
First resource to surface was post from 2008 which still seems to have traction. Kudos to Iain at Technoblahti for this great starting point: “VMWare and the fubar keyboard effect”.
That post showed me the
setxkbmap fix above. But none of the “permanent” solutions were permanent.
Then there was the verbose explanation from VMware which made sense but didn’t solve anything.
Finally, after a few rabbit-holes courtesy of Duck Duck Go, Stack Exchange, and Reddit, I found this little nugget in r/vmware. The redditor noted that remapping CTRL and CAPS LOCK appeared to be at the root of their problems.
A dedicated Emacser, I remapped CAPS LOCK to CTRL a while ago on my Linux machine. But I’ve bounced through a few Windows machines and never swapped CAPS LOCK there… so I don’t actually use CAPS-AS-CTRL.
Disabled CAPS-AS-CTRL mapping (via Gnome Tweaks in my case), and voilà. No more issues from VMware.
That’s what worked for me. Got other suggestions or similar experiences?
Give me a shout on Twitter: @quietmike8192