Keyboard mapping STILL broken in 2.1RC !!!

Keyboard mapping for UK keyboards on a MacBook Pro 15" is STILL broken. I strongly suspect that it is also still broken for other International keyboard layouts.

This is despite Parallels ONCE AGAIN claiming to have fixed it. I quote their "What's New" below

Whats New in Workstation for Mac RC?

New look and feel
Improved performance and stability
Better and broader USB support
Improved Shared Folder tool
Better networking in virtual machines
Better sound support
Improved fullscreen mode
Resolved Suspend/Resume issues
Uninstaller introduced
National keyboards mapping issues have been fixed <-------------- Oh no it hasn't!
Red Power Off button now always acts like Power Off
Blue Pause button now always acts like Suspend
The Pause button was moved to the VM menu


For your information I am using a UK MacBook Pro 15" (2GHz), with Mac OS X 10.4.6 and all the firmware updates (including the latest SMC) have been installed, I also installed Apple's Keyboard update. I am now running Parallels Desktop 2.1RC and the VM contains Windows XP SP2. Windows XP has been configured to use a UK keyboard layout to 'supposedly' match the physical Mac UK keyboard. I have also remembered to update the Parallels extensions AND rebooted.

I find that typing Shift-' (the " symbol) in Windows actually generates a @ symbol
I find that typing Shift-2 (the @ symbol) in Windows actually generates a " symbol
I find that typing \ in Windows actually generates a # symbol
I find that typing Shift-\ (the | symbol [called the pipes symbol in Unix speak) in Windows actually generates a ~ (tilde) symbol
I find that typing Shift-` (the ~ symbol) in Windows actually generates a | (the pipe symbol)

As a result it is IMPOSSIBLE to type a backslash in Windows, this of course is a character used all the time to type in file paths. As you can see this is a huge inconvenience.

As I have gone to the effort of TESTING EACH NEW VERSION, and furthermore REPORTING THIS ERROR each time, I am intensly annoyed that Parallels keep claiming to have fixed this problem when if anything IT IS GETTING WORSE.

This is extremely frustrating as in all other areas the product is excellent and HAS improved steadily.

 

This problem is not related to keyboard mappings in Parallels Desktop.
It's just the difference between uk keyboard (please, see attachment)
You should correct your guest mappings to match this, i guess.

To verify your host mappings you can use Apple Keyboard Viewer.
To verify your guest mappings you can use Microsoft Visual Keyboard from http://www.microsoft.com/downloads/...ba-e9f6-41db-86eb-2adfe407e620&DisplayLang=en

These mapping should be set correctly inside your guest system. You should experience the same thing if you connect this kind of keyboard to windows system.

 

The problem is that this user did not understand that under Windows the keyboard will act like under Windows. That is : keys are located like they are on a PC-Windows UK Keyboard and NOT like they are on Mac UK Keyboard.

This is a limitation that most US-keyboard users don't even think it exists, but that users of keyboard significantly different like french keyboards know very well.

On a Mac French/belgian keyboard, under Mac OS, to type a backslash I have to press shift alt :.

On a PC French/belgian keyboard, under Windows, to type a backslash I have to press AltGr <.

This is simply because the layout of a Mac keyboard is different from the layout of a PC keyboard, even for a same locale, except maybe for some minor keys when the keyboard is a US-ASCII one (typical US QWERTY keyboard).

So when I run Windows in PW, and Windows is set to French/Belgian keyboard, the backslash is not at the same location as when in a Mac OS X native window. Not very easy to switch between both worlds, requires some training, but at least it is coherent in the VM with what I would get on a Windows PC with a PC keyboard.

What would be needed is a Windows keyboard mapping for a Mac French/Belgian keyboard. Such as what I would need if I were to connect such a Mac keyboard on a PC. But as far as I know such mapping drivers are not available from anywhere.

There are only two solutions to this.

1) Keep it as it is : learn to live with the different mappings of a PC keyboard and a Mac keyboard.

2) Have an option in PW configuration to have it "translate the keyboard". Pressing shift alt : (the Mac way) would type a "\" in the guest no matter what keyboard mapping is active there. That may require the Guest tools to install a special Parallels Keyboard Map to achieve this.

This is just a floating idea (the people of RealVNC have chosen that way for the mapping of keyboard from a Mac OS X VNC viewer to a Windows VNC Server) : wether Parallels wants to investigate that alternate way of handling keyboard mappings or not, wether this is technicaly completely possible or not, I don't know.

 

Actually, if you have an Apple UK keyboard your best bet is to set it as a US keyboard in Windows. The Windows US keyboard is a far better match and it will make " @ ` \ / all appear in the right places. The only thing you'll be missing is £ symbol.

 

Most keys fixed in RC1 for my swedish KB layout

Whooray! Now I can type < and > (it was a pain to edit HTML in visual studio in beta 6...). One thing missing though is my alt-key. Previously the alt-key worked correctly, but now it does not seem to do anything. As a consequence, alt-tab has stopped working and closing apps with alt-F4 fails. Problem logged with parallels support.

 

This is a bug. You can change OS type to "Other/Other" as workaround for now,

 

Exactly, this is why I chose UK layout.

In response to other replies, I am aware the location of certain keys (the @ and ") differs between Mac and PC keyboards. Obviously if I press the key in the wrong place because I am used to doing so then I would expect the wrong result. This is not what is happening, I remember to press the correct location for THAT PHYSICAL keyboard and it gives the wrong result for the guest operating system (Windows XP).

It is quite obvious Parallels is merely reading the position of the key and not asking the host operating system to give it the character typed. This maybe necessary to allow Parallels to capture 'special' keys sequences that would normally be filtered out by the host.

I can understand how this might go wrong if for example I was using BootCamp to natively boot in to Windows. However with Parallels I am IN Mac OS X which fully knows the Mac keyboard layout, Parallels should therefore be able to get the CORRECT result from the host [Mac] operating system.

As mentioned VNC does get this right, Timbuktu by Netopia on the other hand DOES NOT.

Whoever is to blame (Parallels, keyboard manufacturers, other) the result is that while US users are unaffected, all INTERNATIONAL customers get hacked off as evidenced by the MANY different threads in these forums all on this same topic. It should be noted that the 'rest of the world' out numbers the US by about 30 to 1.

If Parallels cannot resolve this problem by talking to the host [Mac] and getting the correct key press then I would advise Parallels to add a custom keyboard driver or custom keyboard layouts to their set of drivers they install in to Windows.

Note: in the case of Timbuktu YOU CANNOT simply choose a different keyboard layout (e.g. US or a custom one) because you are controlling a remote computer which will have its own PHYSICAL keyboard attached to it (e.g. UK) and the PC user will obviously want to type properly THEMSELVES. Therefore Netopia's sin is far greater.

PS. It maybe of interest to note that VNC was originally written in Cambridge, England where they are obviously aware of none US keyboards.

 

Bad mapping for my french (Imac) keyboard

Should be fine if Install tools came also with a Parallel keyboard driver, in charge of the host keyboard mapping, whatever it is.

Correct keyboard mapping is a critical problem for a the good adoption of PW/Windows XP in non US countries, and I hope this will be fixed in GA (I pre-ordered, so I can just hope by now ).

 

problems in japanese keyboard mapping

I just want to note there remains a few problems in the keyboard mapping for japanese layout.

For the japanese keyboard, both of PC and Mac, you have the backslash (or the currency symbol for yen) key on the left of the delete key. Shift-backslash gives the | symbol. You also have the _ symbol on the left of the right shift key. I found these three symbols cannot be generated in WinXP guest on RC1 (or in any previous versions). I tried if any combinations of keys, alt-shift-something..., can generate these symbols but have not yet succeeded...

 

It appears to me that the problem does not lie in the mapping but is due to the fact that the guest OS (WInXP in my case) recognizes the keyboard (of MBP, in my case) as a 101/102 keyboard, which indeed does not have the keys for backslash and _. It has to be 106 keyboard. Changing the keyboard driver to the PS/2 106 one in the device manager does not work. I suppose Parallels Team can manage something to make the guest recognise the keyboard properly.

 

[ I know the following has already been said multiple times through different threads and in different ways, but I see no negative to attempt to synthesize it once again here. I'm not complaining stupidly. I'm not complaining at all indeed. I'm pin-pointing an issue, which overlooked might turn in bad sales or bad press after release. Parallels Desktop, as of RC1, is such a nice product, that it is very understandable to wish it becomes even nicer, especially for users outside of the US-qwerty keyboard realm. ]

It more and more looks like an interesting way for Parallels to fix all keyboard mapping issues at once for each specific Mac keyboard and locale available could be, at least for Windows guests OS, to install a guest OS keyboard driver which would get the keys pressed / composed from the Mac OS X host directly. Or anything else bringing the same net results of course.

That scheme is very different of the current one, where Parallels Desktop emulates as best as it can a PC keyboard which the guest OS has then to map properly through its own drivers and maps.

The current solution is smart for guest OS where no other solution can currently be programmed. But for such a highly popular guest OS like Windows XP and possibly some other Windows or Linux versions, this is far from optimal, except maybe for the most simplest keyboard configurations (US english).

Why? Because there are simply NO keyboard drivers and mapping for the Apple keyboards in the Windows world. So there is no way to have the guest Windows OS correctly map an Apple keyboard through a virtual PC keyboard emulation. Yes this is the very same issue as if people where to connect a Mac Keyboard to a real hardware PC using WIndows.

Though we're not using a hardware PC. We don't want nor need that. We are Mac users with a need to run some Windows programs correctly and comfortably. So here comes Parallels Desktop at the rescue. Unfortunately, the fun and the comfort stop where the keyboard gets in. Unless we would be using a basic US qwerty keyboard, which according to world demography, is the least used keyboard in the world.

What is needed for the best possible data-entry experience? Have the keyboard works in the guest OS as in the Mac OS X host. Let Mac OS X handle the keyboard and somehow transmit the net result to the guest OS, probably through some kind of guest virtual keyboard driver. (Again, I'm focused on the net result: the technical way to achieve it is of no importance to end-users of the product. The above only reflects how it looks like it could be done, in a humble opinion.)

Any way a user with a Mac keyboard X, Y or Z has to press the keys to compose a \ or a é (e-cute) or whatever else on Mac OS X itself, he/she would use exactly the same way to compose that same character in a VM window.

Indeed if it has to be treated like that (through some guest-side keyboard driver helper), it would be limited to guest OSes for which Parallels could provide such a keyboard driver. This means the current solution should be kept as an alternative for unsupported guest OSes and even for supported ones, just in case some very specific useage cases might require the "real" PC Keyboard virtualization that Parallels Desktop currently offers.

But a better way has undoubtly to be found and offered for non US-qwerty users to support the product past its beta / RC stage. When time to really use it and work with it will come, bad keyboard support might be a real-world show-stopper. And, personally, I whish Parallels the best success, not the worst support nightmares.

 

Just do it !

I do totally agree with Olivier.

MacOS-Unix/MacIntel/Parallel WS/Windows XP is the winner quad for the PC -> MAC switching
candidates, whose number is increasing everyday.

Many of us still need to have a continuous XP access to ease the transition period, which could
be long, and a bad keyboard mapping for XP just make this move impossible.

In this case, the winner quad will stay the same: Windows XP/X86/VMWARE/Linux.

If you can allocate some extra development time on keyboard issues, I would suggest
to give it to the most important target given the MacOS context; which is the XP guest
keyboard driver (Unix is available "for free" with MacOS, thus doing such things for Linuxes is not a priority, and by the way, Linux is old enough to defend himself ).

You did an excellent job, that is why we cannot believe that you will leave things as they
are for the final release !

 

Remapkey.exe

I know that this isn't a permanent solution for all the keyboard mapping problems BUT it does cure some of them! i've used it under boot camp and I assume it works under parallels.
You can find the remapkey program in the Windows Resource Kit Tools which you can download at:
http://www.microsoft.com/downloads/...69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en

Remapkey.exe: Remap Windows Keyboard Layout

fyi - i'm a UK keyboard user.

mike

 

Thanks Mike. Unfortunately I very well know this tool and others allowing to build customized keyboard mapping drivers. Though they are somewhat limited and cannot solve complex remappings like trying to assign \ to shift-alt-:

That may be a successful path for a UK keyboard, which I presume is quite close to the US keyboard (I may be wrong, but they at least share the advantage that they don't need to offer some commonly used accented characters, so have more locations available for characters like \ [ ] { } and the like without having to use alt-ctrl-altgr key modifiers).

But for a french keyboard and many other national versions, using a Mac keyboard through the PC keyboard of Parallels Desktop through a XP national keyboard mapping through some mapping hacks like remapkey.exe is __NOT__ a good solution.

 

Provide WinXP keyboard layouts for Mac keyboards in the Tools instead!

I completely agree with the goal, but I think there is a much simpler and much safer way to do that: Installing custom keyboard maps into windows.

I'm not talking about remapkey.exe, which only re-maps scan codes at the lowest driver level.

There is a tool set called MSKLC "MicroSoft Keyboard Layout Creator", which can be downloaded for free (though you have to go through some "genuine Microsoft" checking hurdles and the requirement to get .net 1.1 installed). It is a graphical editor where you can create keyboard layouts including all the complex compond key stuff needed. The output of this tool is a "Layout Installer" which installs the new layout to the set of existing keyboard layouts into WinXP. You can then choose it via System Prefs or with the Task bar layout switcher.

Who dares can use this tool already and make his/her own layout (I already did, works great).

But I think what Parallels should deliver (as part of the parallels Tools for XP) is a set of such layouts that exactly match the Mac keyboards. I think the community would help to make and test these layouts for the different national layouts with some support from Parallels.

I think this is a much cleaner way to do it, rather than adding another special driver. What is needed at the Parallels side is that they should pass the USB scan codes exactly as is to the VM. They do it very well already, but there are some problems with differentiating left and right modifier keys in Mac OS right now (I'm confident they'll find a way to fix this )

 

It works great for some task, but is not enough. Take a Mac USB keyboard (get a french one, a japanese one or a german one for instance), plug it in a PC, and try to use this tool to build up a perfect (or even quite close) map such that the Mac OS X way of entering extended characters is valid in native Windows. Good luck, really.

That is a possible solution. Not sure how easy / maintainable it is, because there are not 3 or 4 keyboards mapping needed, but much more than that. As I said earlier, I don't really care what the solution is. But there is a need for a solution. And better be it an easy to maintain solution.

The current scan-code mapping that they do is another thing which should absolutely not be abandonned. It is useful to have it available, as a VM configuration option, because that may be required for some specific needs.

 

I'm using the swiss german keyboard, and see no fundamental problems, except for the modifier mapping, which currently needs remapkey.exe type tweaks and still IS a problem as long as Parallels cannot distinguish right and left variants.

Maybe you are correct saying that you can't build a perfect keymap. But I think that what can't be done with MSKLC (plus modifier remapping) is bound to cause problems with some windows apps anyway because this is the architecture for keyboard mapping in Windows. Bypassing it will break things, and I'd not be surprised if Office was a prominent example of that (not tested however, but I have the feeling originating from using it since Word 1.0).

 

Should work out of the box !

Remapkey and ali is not, and cannot be, a good long term solution to solve keyboard issues.

"Virtualization for the masses !" this is the future !

"For the masses" means a good price. That is OK, thank you Parallels !

"For the masses" means "easy, no trouble, no keyboard problems to deal with. No additional
utilities to install and set up to help the OS offer a *very* basic and transparent
service (from a end user point of view)".

Do not forget that, normally, if you run XP within a virtual host, you have paid *a lot* for it.
And, generally you (will) use it under MacOS for no other reason than doing stuff you
cannot do with MacOS.

In these conditions, when hosting Windows XP, PW4Mac must make things working out the
box, no more, no less than they would work on a physical PC running XP.

To my opinion, there is great difference between VMWARE on XP and PWS on MacOS.

The first one is targeted for an IT population, whereas the second one should be an attractive
solution for advanced end users.

I would not be surprised if the great majority of people running PW on a Mac would run it for
XP.

In this case, it should rock, and not only in the states !!!!

 

I posted a solution to this a while go.

See:
http://forum.parallels.com/thread1680.html

 

A solution for the masses komrad ?

Out of the box ?

I do not think so !