VMware Communities
pforkes
Contributor
Contributor

CAPS lock (yet again)

Ok, so I followed the directions in this kb article <http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004192>

and add the line that it suggests to my Windows XP Professional VM, but with the line in the .vmx file, the vm will not open. If I take the line out, it opens.

I'm using TextEdit (in text mode NOT RTF).

I have tried adding the line (mks.keyboard.syncLEDS = "TRUE") at the beginning, in the middle and at the end.

Yes, VMware Fusion was NOT running when I made this change.

What else can I possibly doe to FINALLY get this to work?

0 Kudos
11 Replies
admin
Immortal
Immortal

Try this workaround instead: when the Caps Lock light doesn't match the behavior in Fusion (i.e., light lit gives you no caps, light not lit gives you caps), go to the Virtual Machine menu and select Send Key &gt; Caps Lock. That should toggle what Fusion thinks the light is showing, but won't actually change the light.

Try that, and let us know how it goes.

0 Kudos
pforkes
Contributor
Contributor

I know about that workaround.

The challenge is that I am a two-fingered typist, and so by the time I reach the end of the sentence/paragraph that's when I notice the problem and I have to type everything again.

I find it 'irksome' that this was not fixed in 1.0, 1.1, 1.11, 2.0, 2.01, 2.02, 2.03, 2.04, 2.05 and (I'm presuming we are testing 2.06) and it has still been ignored.

0 Kudos
Mikero
Community Manager
Community Manager

The issue has certainly not been ignored... but it's a tricky one...

Basically, the Caps Lock is a special button which triggers state differently than other buttons. Every button has an 'up' and 'down' state, including Caps Lock, however that state is not directly linked to the light on the key itself via any sort of software. There's no way within the Host OS to go back and tell the LED to be lit or not, as the button being pushed down does this strictly in hardware.

We've tried some kernel-level fixes which, in some cases, resulted in a nasty kernel panic on the host if used with certain model keyboards, and we felt this was the greater of the two evils (unexpected loss of data vs. having to toggle the caps lock key in software)

We really hear users pains on this issue, and I've heard from a couple of devs that this is being re-looked at with some new ideas, but I obviously don't have any timeframe nor can I set any expectation as to when we can clear this one up.

So, to reiterate, we're certainly not ignoring this issue, it's just really difficult to get resolved due to the nature of keyboard hardware and lack of an OS API for which to talk to that LED (and hence, set it straight).

Thanks

Message was edited by: Mikero: deleted my other 5 spam messages... forum kept saying a serious error occurred and it didn't look like it posted...

-
Michael Roy - Product Marketing Engineer: VCF
0 Kudos
asatoran
Immortal
Immortal

...I find it 'irksome' that this was not fixed in 1.0, 1.1, 1.11, 2.0, 2.01, 2.02, 2.03, 2.04, 2.05 and (I'm presuming we are testing 2.06) and it has still been ignored.

...So, to reiterate, we're certainly not ignoring this issue, it's just really difficult to get resolved due to the nature of keyboard hardware and lack of an OS API for which to talk to that LED (and hence, set it straight).

To add additional info, It's not just Fusion, anything that "shares" the keyboard will tend to have a similar problem. As Mike said, there's no way for software to access the light. So I see the same thing happen in VNC, RDP and even some physical KVMs. Thus it's no surprise that VMWare has not fixed this issue yet. If VMWare does, that could make them smarter than the rest of the computing industry. Smiley Wink

0 Kudos
Mikero
Community Manager
Community Manager

one small note too, pforkes, your post notes the vmx option to be: mks.keyboard.syncLEDS = "TRUE"

The kBase says it should be: mks.keyboard.syncLEDs = "TRUE"

The lower case 's' might be why you're not able to start the VM with this option. Does the issue persist with the lower case 's' ?

-
Michael Roy - Product Marketing Engineer: VCF
0 Kudos
pforkes
Contributor
Contributor

Sorry, that's my two-fingered typing again...what I have in my .vmx file is copied and pasted from the knowledge base article.

0 Kudos
ewing47
Enthusiast
Enthusiast

Ok, so I followed the directions in this kb article &lt;[http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004192]&gt;

and add the line that it suggests to my Windows XP Professional VM, but with the line in the .vmx file, the vm will not open. If I take the line out, it opens.

I'm using TextEdit (in text mode NOT RTF).

I have tried adding the line (mks.keyboard.syncLEDS = "TRUE") at the beginning, in the middle and at the end.

Yes, VMware Fusion was NOT running when I made this change.

What else can I possibly doe to FINALLY get this to work?

Just a thought, I noticed in the kbase article that 'TRUE' in in smart quotes, rather than straight quotes. Even in plaintext mode, TextEdit seems to respect smart quotes. So if you copied and pasted from the kbase article, you may be using smart quotes around 'TRUE'. All other the other options with say 'TRUE' are surrounded by straight rather smart quotes.

You might try changing the quotes in the .vmx to straight quotes to see if the VM at least opens. That's what I did, and it seems to have solved the Caps lock light problem for me.

0 Kudos
pforkes
Contributor
Contributor

I have the capitalization in my file EXACTLY as it should be type (I coped and pasted it).

What exactly is this edit supposed to do? if, as was explained earlier, there is no API call to determine (or set) the caps lock light state, then what exactly is this supposed to do and how can it possibly work?

0 Kudos
ewing47
Enthusiast
Enthusiast

I have the capitalization in my file EXACTLY as it should be type (I coped and pasted it).

Capitalization isn't the problem. It's the quotes. If you copied from the kbase article, you copied it with smart quotes which I suspect isn't appropriate in the file.

Compare:

Copied from article: mks.keyboard.syncLEDs = “TRUE”

Setting with appropriate straight-quotes: mks.keyboard.syncLEDs = "TRUE"

I bet the first is causing your problems. Whether it completely solves the problem, that I cannot answer.

0 Kudos
pforkes
Contributor
Contributor

As far as I can tell, the double quotes are the "straight quotes" and not the "smart quotes".

0 Kudos
ewing47
Enthusiast
Enthusiast

As far as I can tell, the double quotes are the "straight quotes" and not the "smart quotes".

Maybe getting hung up in terminology. Copy and paste the first from the kbase article with the smart or curly quotes into Text Edit; I'm using the default Monico font. (In the kbase article, you can even see how they're angled inwards, which is how double smart/curly quotes appear in Courier.)

Then copy the second version, in my post, where I corrected for the quotes (using what I call straight double-quotes).

You should see a difference -- TextEdit respects the two types of quotes even in plain text mode.

The kbase article has the wrong kind of quotes. They should be straight double-quotes.

0 Kudos