Re: [Qemu-devel] Interpretation of key symbols in QEMU's VNC server

[Fabian Holler]

Hello Gerhard,

On Thu, Mar 08, 2012 at 06:54:46AM +0100, Gerhard Wiesinger wrote:
> I'm having also isssues with german keymappings.
> 
> E.g. Under DOS when pressing shift keys will always be uppercase.
> Also ALT-GR doesn't work.

If I start qemu with -k de and the layout in the Client OS is also set
to de layout I can freely switch  the layout in the VM and it works as
expected (also key presses with shift & alt-gr).
It also works if I'm using gtk-vnc which implements the QEMU extended
keyboard events.
I only tested it with Linux VMs.

> I already discussed such issues here:
> https://lists.gnu.org/archive/html/qemu-devel/2010-03/msg02225.html
> https://lists.gnu.org/archive/html/qemu-devel/2010-04/msg00138.html

Thanks for the links.
I think our problem is a little bit different:

We provide a VNC console for our customers.
The customers use different keyboard mappings and they expect that the same
character in the VNC window appears like on their local editor, if they
press the same key.
Thats not what QEMU does, because it emulates a keyboard controller and the
VNC keysymbols must be converted to scancodes. The character
that shows up in the VNC window further depends on the keyboard layout in the 
VM.

So we are trying to minimize the problems with the vnc console that a
customer could have.

Our currents ideas:

* Let the customer choose the "-k " parameter value for their VMs.
  - Keyboard layout change needs VM restart.
  - Wrong characters shows up if the customer uses a different layout
    on their Client OS.

    Not even all ASCII characters work, because on
    different layouts different meta-keys (shift, alt-gr) presses are
    necessary.
    It could be handled if QEMUs VNC server would interpret
    the received Keysymbol and add/remove additional needed keypresses.
    But QEMU doesn't do this. It also would be an ugly hack if u expect
    that it should behave like a virtualized keyboard controller.
    (Idea from my first post)
  - Sometimes administrators which different Keyboard layouts have to
    use the same console => leads to problems

 * Use a VNC client which supports QEMUs extended keyboard events.
   - Customer didn't expect that he have to choose the keyboard layout
     in the VM. If he has a different layout set in the VM he
     wonders why different characters show up than on their local
     applications..
   - Works with gtk-vnc, but we need an OS independent Java Applet.
     The JVM didn't know the keycodes so we would have to translate the java
     keysymbols to keycodes. For this we have to know the keyboard
     layout on the Client OS, which afaik we also can't detect in the JVM.
     We could guess the keyboard layout on the basis of the locale
     setting but this can also led to new problems.
   o Best idea currently: Let the user choose in the applet their local keyboard
     layout, use this for conversion and try to inform them that the
     layout in the VM has to been choosen.


I'm glad for every hint for a good solution.


BTW: Sorry for the duplicate posts. I was wondering why I didn't
receive my own ML post. It turns out that gmail is moving own ML posts
directly to the archive. :)


regards

Fabian