It's Version 3.what? and vmware Has Yet to Fix Caps Lock Issue

[bittondb]

Why should we be so far past beta and I still have to use osk.exe to fix the caps lock synch issue in my Win7 VM? Rediculous!

[admin]

This is a chronic issue, and I feel your pain! Unfortunately, it's not as easy to resolve as it would seem -- as I understand it, Mac OS X doesn't say whether Caps Lock is on or off, it just says whether it's been pressed. So, Fusion can sometimes miss one of the press notifications and get the state backwards.

Rather than using osk, you might try just using the Virtual Machine > Send Key > menu? (Or, just press Caps Lock yourself, to fix it while you're working in Windows, then press it again when you're back in Mac OS...)

[bittondb]

The send key trick doesn't work. Why not some sort of helper process on the OSX side that monitors the cap locks? This is just not OK.

[admin]

The send key trick doesn't work.

You're using Virtual Machine > Send Key > Caps Lock, right? This should toggle the guest capslock state back into sync. What happens when you try? Do any of the other Send Key options work?

Why not some sort of helper process on the OSX side that monitors the cap locks?

Because there is nothing we can monitor. My understanding is that the only place OS X keeps track of whether the capslock state is "on" is in the kernel, with no consistent way to access the state. We cannot safely access it - we tried various ways in earlier versions of Fusion, but in some rare cases this would provoke a host kernel panic. Rather than risk that, we decided to not try to sync state. To the best of our knowledge, the capslock issue only comes up if the host and guest capslock state initially differ, e.g. if you have capslock on in OS X when you boot Win7, or if you resume from suspend and changed state - for most people, this is rare, if ever.

Another issue we have to deal with is when the host or guest has remapped the capslock key. In other words, even if we did reliably know what the host and guest think the state is, we have no reliable way to tell them to change state.

[bittondb]

I did try the send keys caps lock. no go. I launched osk.exe, and set the caps lock. closed the app, did a send keys, and then brought osk.exe back up. no state change.

[benpoole]

FWIW, occasionally I see this behaviour in my VMs, but the send key feature works every time. You shouldn't need to use osk.exe. This is a very mild annoyance though; not sure it warrants a whole new keyboard scanning process from VMWare (not to mention the fact that that would probably cause issues with OS X's security sandbox, assuming it could be done at all).

[OxkAMam]

I've noticed this issue myself, when resuming from Sleep on my MacBook Pro, and was trying to think of a possible solution. Does this only occur when resuming from Sleep, or are there other instances where Fusion can miss when Caps Lock has been pressed ?

If it only happens when resuming from sleep, does Fusion get a notification when resuming from sleep ?

If so, would the following work when a notification is received:

- On the OSX side, check the state of the Shift keys, simulate a normal keypress and capture the character output (eg. preferably in memory, but piping it to a file would do)

- Check whether the character is uppercase or lowercase, and depending on the state of the Shift key, Fusion will/should know whether Caps is on or off.

- Use this information to sync the Caps state in VM's

or has this already been tried ?