Keyboard SHIFT keys not working after upgrade to Parallels 6

Hi Dennis,
I have version 6.0.11992. Unless I'm doing something wrong, it is definitely not working without the game modifier. I have entered a support ticket.

Thanks!
- David Scheidt
 
ok. I will receive requested report and all other logs in a couple of months in this case.
 
Me, too...

Hi... I'm having the same issue using build 11992. I just submitted a report, #7695853. Making the change in preferences (Virtual Machine -> Configure -> Options -> Advanced -> Optimize modifier keys for games) did the trick... but it's probably not favorable 'out of the box' issue.

Thanks!
 
thank you very much for the report. We are sorry for this inconvenience. The problem is that there is nothing suspicious in it :( and the problem is still not reproducible in our environment.

Could you please tell us two things:
- which Windows7 you are using? may be it is not English one? We have already faced some strange keyboard issue with German in Parallels Workstation project
- could you also play a bit without "optimize mouse for games" with the following boot flag set: devices.kbd.delay=2000

This delay is in microseconds. Default value is 1000. This is a delay in between scancodes reading by guest PS/2 controller. May be we should increase it to 2000 or 5000. Could you please check.

Thank you for the report and best regards.
 
I have the same verison 11992 running Windows 7 (English) and the problem still exists. Turning on the optimize modifier keys works.
 
SHIFT problem continues

Using latest version, I have the shift key problem when connecting by Remote Desktop Connection to my work Win 7 desktop.

Build 6.0.11992
(Revision 625164; December 17, 2010)
 
Thank you for the report.

could you please spend a bit of time playing with "devices.kbd.delay" as I have described above?

Unfortunately we do not see the problem locally and unable to handle it :(

May be the problem is the target system? What OS you are connecting using rdesktop? Win7 to Win7 or something different?
 
I am not sure what/how to play with devices.kbd.delay.

I am trying to connect, using Parallels 6 for Mac, from a virtual Win XP Pro desktop to a Win 7 Pro desktop using a SSL-VPN protocol that uses an ActiveX-RDP implementation to connect.

And I get the SHIFT problem even on logging into the Win 7 machine.
 
Virtual Machine -> Configure -> Hardware -> Boot Order

Field "Boot flags". Stop VM. Place "devices.kbd.delay=2000" into above field without quotas and try. Right now default value for this is 1000 and it is enough for our environment. If 2000 will work -> notify me. If not -> could you please try different values.

This is a delay in between scancodes to be reported into guest OS. It is in microseconds.
 
Thank you! The "Optimize for video games" setting WORKED!

It was driving me crazy that build 6.0.11994 was behaving flaky with CTRL, ALT and WIN keys that I could not properly "Copy Shortcut" in Windows Explorer:

In Windows Explorer:
1. Drag and drop a file.
2. While dragging a file, but BEFORE releasing the mouse button -- Press the ALT(option) key.

In Parallels, nothing happens. (WRONG)
In real native Windows, a shortcut icon shows up. (CORRECT)

Please, Parallels, there are dozens of people complaining about this, fix this in the next build (after the buggy 11994) or make "Optimize for video games" default!!

NOTE: This also fixes the ALT "rectangle block" copy-and-paste in Visual Studio, and so many operations that require pressing a modifier key in the middle of holding a mouse button.
 
Last edited:
we are very sorry but this is lesser evil :( In the other case buttons which are a part of key actions defined in Mac/Parallels will be sent to guest with unpredictable effects, f.e. under certain situations we will have accidentally shown start menu or something like that.

sorry again
 
You might be interested to know I am a programmer of a former open source virtualization project called DOSEMU for Linux, in the mid 90's. So I am familiar with synchronization problems in virtualization of many aspects of virtualized devices, such as keyboard or mouse. As a compromise, what about this logic:

IF (a mouse button is currently being continuously pressed down)
.....Transmit Shift / Ctrl / Alt keydown events immediately to Parallels
ELSE
.....Keep doing the "workaround" behaviour that current build is doing
ENDIF

This will solve maybe, 90% of the complaints:
- Copying shortcuts
- Block copy & pastes in Visual Studio and other text editors
- Modifier operations for graphics editors, such as Adobe PhotoShop for Windows (marking operations, etc)
- The conflict situations you describe don't normally happen while a mouse button is being pressed; so it would be safe to pass the modifier states immediately in these cases.
Etc.
At least as an easy fix for now.

Now, then, to solve the problem completely, can't a creative solution be done?
[Warning, highly technical programmer speak] Another idea, what about buffering up ALL keyboard/mouse events (not just the shift states) and running them in proper sync in a slightly delayed manner, including proper-timing of low level events such as WM_INPUT, so that first/second letters are not accidentally mis-capitalized. Creative use of GetKeyboardState() / SetKeyboardState() can make sure that modifier states are in sync even if transmitted asynchronously to the virtualization (i.e. even 100 milliseconds later without screwing the virtualization up with unexpected behaviours like a key that doesn't have a modifier), even with delayed virtualization of keypresses, if a few-milliseconds delay of injection is necessary on the shift/ctrl/alt keys. I used to program for virtualization software (DOSEMU) back in the 1990's and am familiar with some of the issues of key states going out of sync (for different reasons, but I've got an understandng of many possible tricky situations relating to the keyboard) -- if your previous workaround attempts that caused bugs such as improper capitalization (like the second letter becoming capitalized instead of the first) caused you to give up on trying to invent a better workaround. Maybe one of your developers can contact me to explain the issue in more specific, exact detail and I can suggest a creative solution. Suggestion only. Spy++ logs illustrating the problem are also useful. I am pretty certain that a better solution can be done.

One useful virtualization keyboard debugging method is to write:
(1) write logging on the Mac side using MacOS/Cocoa API's that monitors keyup/keydown events, including timecodes
(2) write logging on the PC side using Windows API that monitor keyup/key events, including timecodes
(3) then write debug code that monitors these two logs simultaneously and raises an alarm if a keypress event goes out-of-sequence, for any reason.
THEN, it becomes MUCH easier/safer to test workarounds and experimental changes; without all the headaches of frequent buggy releases and then giving up "it's the lesser of evil".

Another suggestion is to make the "video game" option much more visible and prominent, as it is the computer geeks (with the biggest word of mouth about Parallels) that might complain the most about not being able to figure out a keyboard problem. The optimize for games option, isn't necessarily games - but useful for geeks like me who are new to Mac and want to continue using existing paint-software and development-software licenses, many of which require proper keyboard states.

Excellent achievement on Parallels, and the technical achievement of Coherence mode. It's pretty impressive, coming from a programmer of a past, different virtualization project.
 
Last edited:
I understand your idea about pressed mouse buttons. We are thinking in a same way about key action engine changes but unfortunately this can't be implemented easily in current codebase. We will try to implement that.

Though the problem with modifier delaying comes NOT from a delivery pipeline. Pipeline itself is synchronous. The problem come from the following pattern. User presses 'Cmd' and then 'Alt'. If we deliver these buttons inside VM and the user will press 'Enter' (switching out from fullscreen mode) we will find ourselves in a bad position. Cmd and Alt are in a pressed state inside. We have to pass release events for them to keep keyboard state consistent but guest OS my decide to react to these buttons and this reaction can frustrate even more users :(

I will talk with our designers about this button but I am a bit skeptical with it. They are too artistic :)

Anyway, thank you for this talk :)
 
Thanks for the insight...

For the quick workaround of shift states updating faster when a mouse button is pressed -- keep it in mind for an upcoming release. Try a test 'refactoring' of the code to centrallize the shift state syncing into one function that's called on both keypress and mousepress events (both the down and up modes). Where your code handles updating shift keys, make it call this centralized function instead. It would then have its own internal states to memorize the virtual state of each modifier key. If the refactor was quick and successful and behaves exactly the same as before (certain kinds of refactorings end up easier than expected, but sometimes not known until attempted) then it becomes easy to follow my suggestion. Do it as a two step project -- a trial refactor (see if it is something that can be done in under an hour, etc) -- then if trial refactor ends up successful, implement my suggestion! :-)
 
I have some experience with this as I have written a keyboard remapping utility called Input Remapper where I encountered the same problem with Remote Desktop. Previously a 3 ms delay between each key state change (delay both presses and releases) seems to be enough. While running remote desktop in Parallels though I have found that I need a 5 ms delay to reliably make key combinations work correctly.

I have also had problems with modifier keys being pressed that I need to dismiss. In particular the Win key that I use for some shortcuts. In this cases I have found that you can prevent the start menu from appearing by generating left shift before releasing the Windows key. This might be a possible solution for all such key combinations.

As a quick fix though I would guess that 5 ms delay would be enough to make Remote Desktop work reliably.

The root of the problem is of course that the Remote Desktop client is buggy and Microsoft should fix it. I don't have the same problem when running remote desktop through rdesktop so I'm pretty sure that the client is at fault. I haven't gotten around to reporting this to Microsoft yet though, but I hope you do as you would probably have more impact :)
 
Last edited:
I am, however, not 100% certain if it applies in Parallels' own case, not knowing their exact architecture but it is my opinion that a fixed delay value is often not a "one size fits all" approach. Who knows, 5ms might not be enough for me, mind you -- I'm running Macbook Air, one of Apple's slowest CPU of currently-selling Macs. (I wanted a fast netbook size machine -- the Air is the world's fastest sub-3-pound 'netbook' size machines; even the Alienware M11X disqualifies due to >3lbs). If it is at all possible, there should be a way to somehow 'peeks' at the safety of the timing of delivering a keyboard state, rather than using an arbitrary delay. Though the Apple API calls might not allow that low level access...

Oh, and throwing out some more ideas into the open (Parallels 7 stuff?):

--> Parallels could also modify their software to scan their preconfigured shortcuts whether a specific modifier key is used in any assigned shortcut. If it is used in none of them, it could automatically deliver the specific modifier key immediately (like video game compatible mode) because it would know there is no interference. This is probably too complicated a change for too little user benefit.

--> If a modifier key tapped, then it switches to immediate sync until another key is pressed. That way, tapping Option followed by pressing it down in less than 1 second later, would behave normally for copying shortcuts and copy & paste behaviour. People will still be complaining it's semi-buggy behaviour, but it would become a lesser evil of "Weird, why do I have to tap ALT key first to copy shortcuts in Windows Explorer?" versus "Damn, why can't I copy shortcuts by drag and drop??!?!?" ... People will naturally instinctively simply keep repeat-tapping a non-working key until the key works, so you simply take advantage of that behaviour because the behaviour is quite obvious (tap, tap, tap). You could even pop up a message (even in that status bar, in the empty space to the right of the onscreen power button at bottom-right -- a useful unused blank area in Parallels that could be used for optional non-obtrusive real-time status or tip messages) when you detect a user tapping a modifier key 5 times, explaining the behaviour and suggesting the video game mode -- that might reduce tech support inquiries too. For many things that are not critical issues, 1 tech support inquiry means 10 or 50 people are privately complaining about it, but not enough to try to get technical support from Parallels. Preventing 5% of these users from switching to Fusion, might make this kind of change worth it.

--> Also, if some keys are delivered synchronously (entire keyboard) and some keys are delivered asynchronously (shift, ctrl, alt, etc), that can be a bad situation when you're mixing synchronous and asynchronous events. Sometimes a synchronous keypress delivery that happens after an asynchronous delivery, means events now gets delivered 'out-of-order' (i.e. capitalizing the 2nd letter instead of 1st letter when delivering a shift key). Therefore, in certain situations, it then sometimes becomes necessary to make keyboard delivery 100% asynchronous -- i.e. key events should get put into a queue. Default behavour would be to empty the asynchronous queue immediately (to emulate synchronous behaviour) upon every event that adds an event to the asynchronous queue. Then whenever needed, delay the assynchronous queue whenever we hit a situation warranting a slight delay. This would cover some, but not all, situations that cause user frustration. I think Parallels might have done something similiar, or a clever workaround to multiplex asynchronous and synchronous keyup/keydown events, and that they were hitting limits.

--> Parallels could even distinguish between left modifier keys and right modifier keys, by allowing one set to behave immediately like game mode and the other set to behave like today. This might be difficult to make user friendly, so probably not feasible. (You can simply leave that to KeyRemap4Macbook users; that utility is a great tool!)

I realize due to architectural issues, if anything is done, it is probably "Parallels 7" stuff, but it's certainly stuff I would pay an upgrade fee for; so it's a matter of if it's worth the "1 or 2 or 3 days of extra work" with "enough sales to warrant the work?" or "Do I have a developer with enough free time, or do I want to give the summer student something to do?" type of work -- but anyway, I disgress. :-)

[Note: I accidentally registered a separate account for forums. This mdrejhon3 account contains my paid Parallels support. I couldn't fix my username to mdrejhon even after renaming the original mdrejhon to mdrejhon2]
 
Last edited:
The delay is only needed because of remote desktop. The cleanest implementation would be to detect if Remote Desktop is the active application on the guest and only then apply the delay.

And you are right that 5 ms might not be enough. It isn't even enough with 25 ms to be 100% reliable according to my testing.

I still think that the best fix for the issue is to not defer modifiers and just generate extra modifiers in the guest when pressing a Parallels shortcut:
Win = Brings up start menu
Win + Shift = Does not bring up the start menu

This should work in all normal application use cases.
 
You must log in or register to reply here.
Back
Top