I have a really annoying problem since I upgraded to vmware fusion 10 (10.0.1) (why oh why do I keep upgrading)
When I move to the virtual machine which is hosting windows 10, no matter what caps state the virtual machine is in, my caps always goes on when I return to the host. So no caps in host to virtual machine no caps = CAPS when returning to host, no caps on host to caps on virtual machine = CAPS on host. I continually move from virtual machine to host which means that I constantly have to turn CAPS off. Can anyone tell me how I can fix this?
Hi, I have exactly the same problem.
And in addition to this, inside the Windows VM, sometimes when I press Ctrl+c it results in typing repeatedly "cccccccccc..." or Ctrl+v resulting in "vvvvvvvvvvvvvvvvvvvvv..." and it doesn't stop until I press another key.
This happens randomly and with every "special key" (i.e. Ctrl, Delete, End, Backslash, etc.) and is VERY, VERY annoying.
The CAPS LOCK issue happens every time I switch from the VM to the mac (and it's very annoying, too!).
Mac (27-inch, Late 2013), 3.4 GHz Intel Core i5, 32 GB 1600 MHz DDR3
Osx: 10.13.1 High Sierra
Fusion: 10.0.1 (6754183)
VM: Windows 10, Version 1703 (OS build 15063.674)
I raised a support request and after almost two hours vmware acknowledged that it was a problem with version 10. We found this out by uninstalling version 10 and installing version 8. The problem went away. So I am on version 8 for now cause it was too annoying.
I also downgraded to 8.5.8 and the caps lock issue is gone. The one with the repeated keys still remains... 😞
Are you accessing the VM via remote means by any chance?
I'm asking as that's pretty much the only time I've seen the "repeating key issue"
There's a solution by editing your .vmx file.
VMware Knowledge Base article 196
Note that you have to shut down the VM before editing the vmx file.
No, I'm accessing it "normally", on my Mac (on a separate display). I will try the proposed solution anyway, maybe it'll do something.
It appears that VMWare is trying to keep track of the caps lock state of the host OS so it can put it back when you switch away from the VM, and it's failing. I also can't get the VM to obey the keyboard caps lock, I have to send it from the menu; this may or may not be related. (VMWare reading the same variable it's writing for caps lock functionality?)
If you enable caps lock in the host OS, switch to the VM, and then switch back to the host, caps lock turns off while in the VM and caps lock will come back on when switching to the host OS. If you then turn caps lock off in the host OS and switch back to the VM, everything seems OK until you go back to the host OS... caps lock will come back on.
WORKAROUND (sort of) until VMWare fixes the issue:
Make sure Caps lock is off in the VM (send Caps lock from the 'Virtual Machine' menu in VMWare).
Turn off caps lock in the host OS by hitting the caps lock key.
Go to SYSTEM PREFERENCES > KEYBOARD > [Modifier Keys...], and select 'No action' for the caps lock key.
Click [Modifier Keys...] again & re-enable the caps lock key.
To avoid the problem:
Always turn caps lock off before switching to the VM.
Always use the 'Virtual Machine' menu to send caps lock to the VM.
...or just disable caps lock altogether.
It's not a great workaround, but hopefully this relieves the frustration of not knowing WTF is happening w/ caps lock while you're trying to get some real work done.
If you're wondering, I'm running VMWare Fusion 10.0.1 on OS X 10.13.1.
Hi, unfortunately it doesn't help 😞
Thanks for reporting this issue, the development team is working on it now. In the meanwhile, if possible, please run Fusion on High Sierra 10.13 GA host to workaround this issue.
Hey guys, so sorry to hear you're hitting problems with the caps lock between macOS hosts and VMs. Can I please get some more information from folks who are hitting this?
What exact version of macOS are you hitting this with? I think I saw someone suggest maybe this problem was only happening on macOS High Sierra Beta 2 (10.13.2 Beta (17C67b)). Can folks please reply back with what exact macOS version they're running, from About This Mac > Overview?
Second, can I get some more information about exactly which peripherals are attached to the computers that are exhibiting this problem? Are there multiple keyboards attached, or multiple things that macOS might think are keyboard devices? For example, I use Logitech mice with their Unifying Receiver that lets me use both a keyboard and mouse with the computer. Any chance you guys are using something like a Logitech Unifying Receiver USB dongle?
Third, what Macs are people hitting this on? Please be specific, from About This Mac > Overview. Example: "Mac mini Server (Mid 2011)".
And lastly, there is a config option that should turn this caps lock behavior off. If you want to try, add mks.keyboard.setHostLEDs=FALSE to your ~/.vmware/config or ~/Library/Preferences/VMware\ Fusion/config file. Try shutting down Fusion and all running VMs, add that config option, then restart Fusion and whatever VMs you were using and you shouldn't see the caps lock switching like this on you. That should let you guys use Fusion 10 again without this annoying behavior.
Here are the steps to reproduce the issue on my workstation:
With the Windows 10 (Version 1703, Build 15063.674) VM running, enable caps lock while in the host OS.
Leave caps lock enabled and switch to the VM -- caps is disabled (the VM's caps state)
Switch back to the host OS -- caps is enabled (OK so far...)
Turn caps lock off in the host OS.
Switch to the VM -- caps stays disabled (OK so far...)
Switch to the host OS -- caps is enabled.
All caps status observations were made by looking at the caps indicator light on the keyboard and by typing some text to verify.
Below is the information you requested.
VMWare Fusion Version 10.0.1 (6754183)
Model Name: Mac mini (2014)
Model Identifier: Macmini7,1
Processor Name: Intel Core i5
Processor Speed: 2.6 GHz
Number of Processors: 1
Total Number of Cores: 2
L2 Cache (per Core): 256 KB
L3 Cache: 3 MB
Memory: 16 GB
Boot ROM Version: MM71.0226.B00
SMC Version (system): 2.24f32
System Software Overview:
System Version: macOS 10.13.1 (17B48)
Kernel Version: Darwin 17.2.0
Boot Volume: Macintosh HD
Boot Mode: Normal
Below are the only HID devices connected to the workstation:
Keyboard (from USB section) / Drevo Gramr 84
Product ID: 0x0101
Vendor ID: 0xb404
Speed: Up to 12 Mb/sec
Manufacturer: Megawin Technology Inc.
Location ID: 0x14200000 / 6
Current Available (mA): 500
Current Required (mA): 100
Extra Operating Current (mA): 0
Mouse (from USB section) / Anker Vertical Mouse TM156G
2.4G Wireless Mouse:
Product ID: 0x4102
Vendor ID: 0x062a (ProVision Technology, Inc.)
Speed: Up to 12 Mb/sec
Manufacturer: MOSART Semi.
Location ID: 0x14110000 / 12
Current Available (mA): 500
Current Required (mA): 100
Extra Operating Current (mA): 0
BEAUTIFUL, thank you Matias! ❤️ Does this only happen with that Windows 10 VM or does it happen with all VMs on your system?
Also, your mouse... "Mouse (from USB section) / Anker Vertical Mouse TM156G 2.4G Wireless Mouse"... am I correct in thinking that's a USB dongle wireless mouse?
Thanks so much for the great information, Matias! You rock! =:)
Unfortunately, I don't run any other VM's to test with.
Yes, the Anker mouse is a USB dongle mouse.
I separately plugged both devices into a bare metal Windows PC to see if I see additional keyboard devices in the Device Manager:
Oddly enough, the keyboard gets recognized as 2 HID Keyboard Devices.
The wireless mouse only shows the 1 HID-compliant mouse.
So I grabbed a USB keyboard that is recognized by the bare-metal WX PC as a single HID Keyboard and re-ran my test:
Caps lock behavior is NORMAL. At the last step of the test, the caps lock stays off.
What is still present, and may not be related, is the VM still ignores the caps lock on the keyboard. I have to use the VM > Send Key menu to enable caps lock in the VM.
Awesome information again, thank you Matias! I think I have a starting point now. =:)
On the "VM still ignores the caps lock on the keyboard" bit... in your previous post, I think you disabled it or something in your section "WORKAROUND (sort of) until VMWare fixes the issue"? Did you still have the caps lock disabled or turned off in the VM or something?
Also, I'm not sure if you saw the last comment in my post above, but you can restore the previous (Fusion 😎 behavior with regards to caps lock by setting mks.keyboard.setHostLEDs=FALSE in your ~/.vmware/config file.
Thanks so much for the helpful feedback, Matias!
I'd still love to hear from anyone else who's hitting this as to what their Mac is, macOS version, and attached peripherals are.
I made sure to revert the modifier key settings before I began each test. Incidentally, I discovered that Mac OS stores the Modifier Keys settings on a per-device basis; when I plugged in the new keyboard, the Caps Lock Key drop-down was already set to Caps Lock. When I plugged in my original keyboard, the Caps Lock Key was set to No Action.
As far as the VM ignoring the Caps Lock input from the keyboard, the problem began as soon as I upgraded to 10. The VM doesn't exactly ignore the input.
I have the 'Toggle Keys' accessibility feature enabled in the WX VM so I get an audio cue when caps is toggled.
When I press the Caps Lock key, the LED on the keyboard flickers once and I hear the tone corresponding to the current caps state (not the intended state): it doesn't toggle. If I keep pressing the key, it will eventually enable caps lock, but then it can't be disabled.
I can successfully toggle the caps state of the VM by using the VMWare menu, or the on-screen keyboard within the VM. Interestingly, when the VM's caps state is changed the LED on my physical keyboard will change correspondingly. I reproduced this issue with both of the keyboards mentioned earlier.
...now that I look at that setting change you listed for VMWare 8 behavior, I wonder if there's an unintended loop when VMWare checks caps status and then sets the corresponding LED status. The VM seems to behave like Caps Lock is disabled immediately after it's enabled.
I'll set mks.keyboard.setHostLEDs to FALSE and test.
I could not find the config file. I looked in ~/.vmware/config and ~/Library/Preferences/VMware\ Fusion/config. I also looked in /Library/Preferences/VMware\ Fusion. Is there another possible location?
No, but I don't believe it's created by default. You can just "mkdir ~/.vmware; touch ~/.vmware/config" and then add that line to it.
I've got the same problem with Fusion 10.0.1 and macOS (17B48)--caps lock always on when focus moves from Windows 10 guest to the macOS host.
Putting "mks.keyboard.setHostLEDs=FALSE" in ~/.vmware/config didn't do anything for me. However, putting that line in ~/Library/Preferences/VMware Fusion/config did make the situation somewhat better.
With that configuration line, the caps lock is not synced between host and guest, but at least it doesn't always revert to caps lock when switching to the the host now. Within the guest, there are now some circumstances where a double tap of the caps lock key is needed to actually get caps lock in the guest. Not great, but better.
There will be a fix for this in the next point release?
Thanks for the additional information, jmstacey! We are working on fixing this internally, but I don't think we usually say what future release will contain said fixes, etc.
MacBook Pro Retina 13-inch Late 2013
Using external USB Apple keyboard.
Logitech M510 wireless mouse with receiver connected to external keyboard's USB port.
Windows 8.1 Pro running on a separate display.
Experiencing seemingly random cap lock issues. Without ever touching the CL it will enable itself on a) the VM only, or b) the VM and Mac. Sometimes I can move the mouse cursor back and forth between VM on one display and MacBook display and CL will turn on and off. On over VM, off over Mac. Sometimes I can use keyboard to turn off CL, sometimes I must use the on-screen keyboard on the VM (didn't know until now I can send a CL keystroke via Fusion.)
Have not tried workaround yet.
Also, thank you for the help.