1 person found this helpful
I too have been experiencing this problem recently. In fact, I am typing on my new BT keyboard as I thought my old one was going flaky. I bought a new one and found the issue remained.
I am running High Sierra 10.13.2 with VMware Fusion 10.1.0 with a Logitech K380 BT keyboard and a Logitech M705 mouse with a USB dongle. It also happened while using my first generation Apple Wireless Keyboard.
This has been driving me absolutely bonkers. I have implemented the mks.keyboard.setHostLEDs=FALSE to the config file, and in the short time since then, I've not seen it happen. Fingers crossed.
I am brand new to VMware Fusion after getting a new MacBook Pro I made the switch from Parallels to Fusion. Regretting it already, as I too am having this CAP LOCKS issue and see it has been going on for a couple months and not yet fixed. I can NOT turn off Cap Locks when I return to host after working in the VM. I am just a very average user so can't get very technical.
After using Word in the VM and then going to the host, whether cap locks was on or off (or even USED) in the VM, I am stuck in CAP LOCK on the Host and Cap Lock will not work in the VM (though I can get a Cap with shift key in VM). Only fix is to restart. (I do not know that working in WORD has anything to so with it, as i usually am in it at one point or another, as well as a few other programs.)
MacBook Pro 15" w/ Retina and touch bar
High Sierra 10.13.2
VMware Fusion 10.1.1 (7520154)
And NOW suddenly in the VM I am in STUCK IN CAP LOCK (whether indicator light is on or off) but can type lower case if I hold in the shift key. THIS IS NUTS. I do not know what made this suddenly change while I was typing this reply!!! I HAD TO ACCESS YOUR WEBSITE thru the VM so I could type in my password since it had lower case letter.:" btw shift key works properly for special character keys :"<>? but backward on all letter keys.
Quick check to see if this has been resolved. I am running 10.1.1 guest CentOS 7. I am currently seeing the issue were caps lock state is improperly restored to ON. I have also experienced the 'permanently' (until reboot) locked caps lock.
I hope there will be a fix soon. If more information is required to identify the reason for the issue, i would be happy to help
Still having this issue.
Running VMware Fusion 10.1.1
MacOS High Sierra 10.13.3
Multiple VM's - Windows, Ubuntu, Kali Linux, Security Onion etc.
Caps Lock Off when clicking inside of a VM, when returning to the host OS caps lock is enabled, re-enter VM caps lock enabled, return to host caps lock remains enabled.
I HAVE THIS PROBLEM TOO. SOME RANDOM EVENT IN THE VM IS LEAKING OUT TO THE HOST OS IN SUCH A WAY THAT THE CAPS LOCK KEY IS COMPLETELY STUCK. WHETHER THE LIGHT ON THE KEY IS ON OR OFF THE TEXT COMES OUT AS OF THE SHIFT KEY IS HELD DOWN.
ONLY ANSWER IS TO REBOOT THE MACHINE - VERY VERY ANNOYING.
IF IT WEREN'T FOR THE FACT THAT MY CAPS LOCK KEY WERE STUCK I MIGHT BE TEMPTED TO COMPLAIN IN ALL CAPS TO EXPRESS MY FRUSTRATION.
FIX THIS BUG PLEASE.
1 person found this helpful
I just gotta say, @CAPS_LOCK, you made my day.
Anyway, just wanted to get an update out to you guys. I've found the problem and a solution. This has been fixed internally. I can't speak to when Fusion will put a new release out which contains the fix, but one should be coming at some point.
So sorry this bug was missed and is affecting all of you. Hang in there, a fix is coming.
vanRijn: glad to hear that this has been fixed internally.
Based on your experience, can you give us any guidance on when a release with this fix may come out? Days? Weeks? Months?
Thank you for your help.
The exact same problem here. Need to restart to fix it. really annoying
This is not working for me either. After paying €103 to upgrade, and having this issue every single day, trying to develop software, I am very annoyed. This happens to me when connecting to a remote VSphere machine too.
Sorry for this annoying issue! We already fixed this internally and the fix will be contained for the upcoming update release of Fusion 10.
Before the official fix, pls try following workaround documented in KB:VMware Knowledge Base.
I have the SAME issue.
I raised this issue and started this over thread three months ago and this annoying issue has not yet been resolved.
Obviously this is not a priority for vmware and so the best option is to ask for a full refund (as I did, and received) and move to another option. Under Australian consumer law companies must give a full refund for faulty products and similar laws are present in other countries. Continually having to click caps lock every few seconds makes this product unusable for me. I have also spent about 6 hours of my time trying to resolve this issue with vmware support. For the most part they approached this issue as if something was wrong on my end and so we spent hours trying to find that (swap multiple keyboards, reset pram, support request to Apple, re-install, remove other software and on and on).
As consumers it is in our best interest to support companies that listen to us and take our needs and problems as priority. Whilst I commend their support team for trying to resolve the issue there is no doubt that it is an issue wth Fusion and not a configuration issue on the users end and there is no doubt that the issue arose from version 8 to version 10.
I am always amused when companies want our feedback when they've done something right but ignore our feedback when they've done something wrong. This is not acceptable vmware you obviously don't care about your customers.
1 person found this helpful
So, I was having this issue with Fusion Pro 10.1.1 with host os 10.13.3 and guest os 10.13.3 (yeah, I run a Mac VM on a Mac. :-)). I found I just had to log out, not reboot, to resolve the issue.
But I followed the steps in the KB article and it resolved my issue (and is actually the behavior I prefer, anyway).
I get the frustration with people who have this problem (I suffered from it for several months). But I think it's a little unfair to paint VMware with the paintbrush of "they don't care". Clearly, they care. Folks from VMware have been asking for information and looking into the problem for some time, and now there is at least a mitigation for this issue. I think it's fair to said that "they" (who do you really think you're talking about here? The people who work for the company and are looking for a solution? Really? They don't care when they say they've found the issue and it will be released? Do you mean the release folks who are certainly running whatever release tests they run so that they don't release crappy code? Do you mean the marketing people who abhor the negativity that can snowball if they don't address issues? I'm just unclear who "they" are here) care.
As for trying to identify the problem, when I read the thread, your second post three days later said VMware acknowledged this was a bug. Yeah, companies often try to figure out if it's some configuration error or hardware thing. Unless they have a ton of people report the same problem, the first assumption is that it's localized to an individual user.
Finally, I'm unclear why this isn't marked as resolved, since the Fusion 8 behavior is trivially restored with a single file creation and restarting the app. OK, yeah, you shouldn't have to do anything, but, gees. . . I've spend WAY more time typing up this response than I did simply applying the workaround.
Zongmin, I tried the workaround in the Knowledge Base article but it didn't help. What does fix the problem, however, is unplugging my Logitech M510 dongle and using my Magic Trackpad instead. Will the fix you describe cover this case? Thanks.
A good call - always jump to the end of the thread.
The KB article, did the trick....
Thank you - shkamath
Everyone else, I have been running FP 10.1.1 and 10.3.4, and the problem only showed up very recently. I mean a week or so.
I don't know what triggers CAPS LOCK to switch on every time FP gains focus, but it was driving me nuts.
Is this a feature feature, or a feature gone wrong? I don't mind if FP can track CAPS LOCK and make sure each session guest and host maintain their status. However, maybe a setting, the opposite way, ALWAYS OFF this would be better.