Adventures in Linux, VMware, and Broken Keyboard Maps

Fri, Sep 11, 2020 3-minute read

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:

  1. Disable any custom keyboard mapping, i.e. if you’ve mapped CAPS LOCK to CTRL like I did.
  2. (Also, maybe…) As root, add xkeymap.nokeycodeMap = true to /etc/vmware/config.
    • 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):


Restored Keybindings after setxkbmap

# 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)
mod4        Super_L (0x85),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

The Investigation

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