Re: [gtk-vnc-devel] [PATCH][RFC] Support for ExtendedKeyEvent client message

[Gerd Hoffmann <kraxel redhat com>]

Anthony Liguori wrote:
>>> One problem with passing Linux input codes is that we have no way to
>>> make the information we get from GDK to Linux keycodes.  We're basically
>>> passing all the information we have (the symbolic value, and what GDK
>>> provides as the hardware keycode with some canonicalization).
>>>     
>>
>> For the standard 105-key-kbd keys it should be easy at least on pc
>> hardware (just a table lookup).  Just that should be good enougth for
>> starters.
>>
>> The other keys probably become a bit more tricky due to non-standardized
>> ps/2 keycodes for them.  Shouldn't be impossible though.  On the client
>> side we probably can map those XF86XK_AudioLowerVolume (+friends)
>> keysyms.  On the qemu side we probably have to pick one specific
>> multimedia keyboard (with lots of different keys) and emulate that one.
> 
> Using the -k option in QEMU basically picks a particular keyboard and
> emulates that.

No.  It picks a keymap, not a keyboard.

> If we're willing to do that, then always launching qemu
> with -k en-us and using the existing VNC keysyms is a fine solution to
> the problem.  This is actually exactly what the current QEMU server
> does.  As long as you configure your guest with an en-us keyboard,
> everything Just Works regardless of your client's keyboard got most
> keysyms.

No, it doesn't "just work".

For example the '<' and '>' chars are on two keys on a us keyboard.  On
a german keyboard they are on the very same key, one of them with and
the other without shift pressed (and on top of that it is the 105th key
which is present on int'l keyboards only).  Those keys are completely
messed up with "qemu -k en-us" and a client using a german keyboard.

cheers,
  Gerd