[PATCH 0 of 2] Fix keymap handling for vnc console

[John Haxby <john.haxby@oracle.com>]

[I've not posted a patch before so I expect I've got some things 
wrong.   But I'm willing to re-post until I get it right!]


This following patches change the keymap handling code to better deal 
with non-English keyboards.  In particular:

 * The old code implicitly assumed that there was a 1-1 mapping between 
keysyms and scancodes.  Unfortunately, this is often not the case.  For 
example, on an UK keyboard, "@" can be generated from a shift sequence 
(the penultimate "small" key in the middle row) and by typing AltGr-q,

* Some keymaps are quite wrong: for example the Turkish AltGr-b was 
defined to be apostrophe.   This conspired with the previous problem to 
make shift-2 result in a "B" instead of an apostrophe.

* Many symbols used in the keymaps were not defined and several keymaps 
were incomplete resulting in sequences that sent no scancode to the 
guest OS.

These two patches attempt to rectify these problems.

To find the scancode for a given keysym, the code looks in the "right" 
map so that for example, on a UK keyboard "@" will generate a scancode 
of 0x28 or 0x10 depending on whether the shift sequence or the altgr 
sequence is used.   If a keysym can't be found in the right map then the 
code will check the other maps and generate implicit shift and altgr 
presses and releases to match what it thinks the user should have 
pressed.  (So, for example, if you're using a UK keyboard but qemu-dm is 
expecting a Turkish keyboard then the shift sequence to generate "@" 
doesn't exist so the shift key is implicitly released, the AltGR key 
implicitly pressed and the 0x10 scancode sent -- this has the effect 
that keyboards will mostly do the "right" thing even if there is a 
mismatch between qemu-dm and the vnc client.)

Numlock handling is much as before although, so far as I can tell, 
Numlock defaults to "off" instead of "on" at boot time.  However, there 
is a problem that if software in the guest changes the numlock state, 
the qemu-dm vnc server doesn't know this and the numlock state can 
become inverted.

The capslock key is ignored in favour of sending implcit shift-press 
shift-release sequences as recommended in the VNC protocol description.

The second patch corrects many of the existing keymap definitions so 
that they match the XKB definitions.  The maps I have left alone I am 
unsure of as I'm not sure, from the names, what the corresponding xkb 
settings are.   However, the ones I am sure of are now, I think, 
complete so that provided the vnc client and qemu-dm keymaps match it 
doesn't matter what the guest OS uses as its keymap (because it will get 
the correct scancodes).

So far as I can tell, for a given keyboard, if a sequence produces a 
given symbol on Windows then it will do the same under X.  The reverse 
doesn't appear to be true: for example, shift-altgr-Q often gives 
Greek_OMEGA under X but does nothing in Windows.

If anyone is interested I have two (Linux specific) programs that can be 
used to generate and test keymap files.

The patches are against the xen-3.3-testing tree and relative to 
tools/ioemu-remote which is under git control rather than mercurial.


jch