HyperV + AltGr + Linux + MS SDEs + MSKB == ䷅

by Michael S. Kaplan, published on 2010/06/15 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/06/15/10023953.aspx

For those who don't know that symbol or lack the font to see it: it is (U+4DC5, aka HEXAGRAM FOR CONFLICT).

Whenever you talk about virtual machines, there is one piece that will never fail to be incredibly complicated.


You know, keyboards.

Just the other day someone was asking:


In the following KB, it mentioned that the issue occurred in Windows Server 2008 based Hyper-V computer and there is a hotfix, however, one of my customer encountered this issue on a Windows Server 2008 R2 based Hyper-V computer.


Best Regards,

This is one of those cases where you have to read the whole article, though. It won't give you the answer but it will help you through the problem, and suggest a solution.

The article, The AltGr key does not work on a Linux virtual machine on a Windows Server 2008-based server that has the Hyper-V role enabled, has a few facets. It:

Now obviously a future service pack is expected include the hotfix, and just as obviously the next version is expected to contain the fix, too.

But that changes the landscape only a little bit. The Server 2008 R2-directed article needs to do a little less. It would:

Now the information, buried in the bottom of the KB article due to all the text related to the hotfix is:

Under the following registry key, add a registry entry named "KeyboardWorkaroundEnabled," set the type to REG_DWORD, and then set the value to 1:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Worker

This was not a new problem even when the article first came out (ref: The ALTGR and ALT+CTRL key combinations do not work in Virtual PC 2004 with Service Pack 1).

Now regular readers will know I have a history of disliking the way international keyboards are handled by various technologies.

I mean look at the symptoms described in the article:

Consider the following scenario:

In this scenario, the AltGr key does not work on the Linux virtual machine. As a result, you cannot type the following characters:

NoteThe AltGr key is the right ALT key on the German keyboard.

Either the person does not know what AltGr is (in which case they are not looking at the article in the first place), or they do know and they will feel like this is the most ridiculous description one could possibly imagine for a key used on so many keyboards.

But we'll set that aside for now, and think about this for a minute.

The problem, as the KB article explains quite accurately, is:

Windows systems use the left CTRL scan code together with the right ALT scan code to indicate the AltGr key on a German keyboard. However, the Linux virtual machine expects to receive the right ALT scan code only. When Windows sends the left CTRL scan code together with the right ALT scan code, the Linux virtual machine does not interpret these scan codes as the AltGr key.

And then, also buried in the text lower down related to after the fix, is:

Note:After you install the hotfix and then create the new registry entry, the Windows Server 2008-based system removes the left CTRL scan code when it is followed by a right ALT scan code. However, this may affect intentional left CTRL + right ALT key combinations. To work around this issue, hold down the left CTRL key for a few seconds before you hold down the right ALT key.

This seems fairly ugly as shortcuts go -- kind of removes the usefulness of a shortcut if you have to type the keys slower to make it work.

Of course, the fact that the registry value added is begging to be thought of as a hack, what with a name like KeyboardWorkaroundEnabled, seems like a problem too. Like they think there will never be another keyboard handling bug in a virtual machine? The odds of that are almost on the same order of magnitude as the odds for Eric Cartman of South Park being asked to step in to fill Robbie Bach's E&D President role.

From a technical side, maybe this is the only way to fix the problem. But there probably still would have been better ways to handle the execution!

So a part of me is happy that the KB article is so unwieldy and hard to get information out of because it hides the hack. It is not a committment or anything but I really like to encourage people to not design things that make the company look dumb technically. It is just the other part (the part that likes to help people!) would prefer that things are documented in a way that would make them more useful for users....

Yuhong Bao on 15 Jun 2010 11:47 AM:

Maybe patch Linux?

Random832 on 15 Jun 2010 4:28 PM:

So - what's the history here? Why is windows generating an extra scan code, when it clearly can tell the left and right alt scan codes apart at all stages (since it's relying on this distinct scan code to tell the difference between altgr and an actual ctrl-alt [with, i suppose, a right ctrl or left alt])? What benefited from this? I don't know much about the keyboard handling 'stack' on either Linux or Windows to figure anything out here.

I mean, I know this is something that would require Raymond Chen's time machine to change at this point, but I would like to understand the thought process as to why that ctrl is in there in the first place.

Michael S. Kaplan on 15 Jun 2010 5:02 PM:

We have always treated ALTGR as right alt + ctrl, so that people who lack an altgr key can still get to those letters on the keyboard (and also so that times that the "right alt" is harder to hit in touch typing has a "left alt" solution). This is something I have written about often in the past....

NLE on 27 Aug 2010 7:39 AM:

Indeed, I didn't understand what to do before reading your post. Unfortunately, adding the registry key didn't solve anything (Windows Server 2008 R2 French / French keyboard and Linux / CentOS 5.5)

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

go to newer or older post, or back to index or month or day