This is a slightly updated version of the patch I posted a little while 
ago.  It is a patch against the ioemu-remote tree in xen-3.3-testing.   
I'll be sending a corresponding patch to qemu-devel when I've got my 
qemu build environment sorted out.

There are presently a few problems dogging keymap handling for the vnc 
console:

   * Some keystrokes that generate a symbol locally are ignored.

   * Some keystrokes in some keymaps generate the wrong scancode and 
thence the wrong character

   * The capslock key is handled inconsistently

The first problem is typically caused by missing entries in the keymap.  
For example, the "Q" key in many European keyboards generates "@" and 
"Ω" in addition to the normal "q" and "Q" when used with the AltGr key.  
However, the keysym defintions in vnc_keysym.h are incomplete and so, 
for example, "Ω" will never be recognised even if it is in the keymap 
definition (which it often isn't).

The second problem is a little more subtle.   The code presently assumes 
that there is a many-to-one mapping from keysyms to scancodes.  So, for 
example, "q", "Q", "@" and "Ω" all generate the scancode 0x10.   
However, on a UK keyboard the "@" keysym can arise from typing either 
AltGr-Q (scancode 0x10) or Shift-apostrophe (scancode 0x28).   For some 
keymaps this is particularly damaging -- for example in 
http://article.gmane.org/gmane.comp.emulators.qemu/32241 the "1", "4" 
and "6" keys should give "&", "'" (apostrophe) and "§" respectively but 
actually give "k", "b" and "s".

The final problem is related to the numlock handling problem that was 
fixed fairly recently.  For that particular problem, the various keysyms 
that are generated when the only when the numlock key is pressed or 
released result in an implicit press or release of the numlock key in 
order to change the state of the key.  In the case of the capslock key, 
however, it isn't, in general, possible to distinguish between a "A" 
generated from a capslock and one generated with a shift sequence.

The following patches are designed to fix these problems.

The first uses five keysym to scancode keymaps for plain, shifted, 
AltGr'd, shift-AltGr'd and numlocked keys to handle the many-to-many 
mapping from keysyms to scancodes.   The current state of the shift and 
altgr keys that the guest is aware of is tracked and a keysym looked up 
in the corresponding map to find the right scancode.  If the scancode is 
not defined in that keymap then the other keymaps are checked and 
implicit keypress or keyrelease events for shift and AltGr sent to 
produce the right scancode and modifier set to generate the correct 
keysym in the guest's application.   The first lookup means that the 
right scancode will be generated for a keysym in all but the most 
pathological of cases; the second lookup means that, for example, a 
client UK keyboard will work correctly against a guest Belgian keyboard 
because the implicit shift and AltGr keypresses and releases will do the 
necessary shuffling behind the scenes.

The second patch adds the missing keysym names to vnc_keysym.h.   Not 
all the X keysym names are in here, but there are enough to satisfy all 
the keysyms used by the keymaps presently defined.

The third and final patch corrects most of the keymap definitions.  The 
ones I haven't changed are the ones I am unsure of -- the names do not 
always correspond that well to the xkb keymap names and for the 
non-european keyboards I have very little confidence that what I am 
typing is what is intended!

There is a remaining problem with the numlock key handling which is 
beyond the scope of these patches: if software running in the guest 
toggles the numlock key (for example, the X server) then the behaviour 
of the numlock key may become inverted.   Also note that the initial 
state of the numlock key was wrong in the existing code, but that was 
easy to fix.

Finally, the two attached programs -- evkey.c and evconv.c -- can be 
used to help generate and test keymap definitions.   The former, evkey, 
is Linux specific and matches up keysyms received through a small X 
window with the scancodes retrieved from a PS/2 keyboard (and it must be 
a PS/2 keyboard, USB keyboards generate different scancodes).  The 
latter, evconv, uses the xen keymap to generate find the scancode and 
can be used to check that a keymap definition is going to give the 
expected scancodes for a given (X) keyboard mapping.  Hopefully the 
comments at the head of each file will describe the intention 
sufficiently well.

jch