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

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

[Fabian Holler]

Hello,

I'm not sure if I found a bug in QEMU's VNC keysymbol to scancode
mapping or if it is
a general Problem with the implemented VNC server:

Scenario:
QEMU started with: "-k de"
Keyboard layout in VM: de
Keyboard layout from Client OS: us

What i expect:
I type the '/' character on the Client OS (key left from the
right-shift-key) on US layout.
key symbol '/' is send over VNC to the QEMU.
QEMU lookup in the de keyboard mapping table for the character '/' and
should find the scancodes for the keys shift+'7'.
The Scancodes for shift and '7' are send to the VM's emulated keyboard
controller and the '/' appears in the VM.

But what actually happens is that the '7' character shows up in the VM.
It seems that QEMU misses to generates an additional  Shift Scancode/Keypress.

Is this a general problem in the VNC server implementation?
So that an interpretation (http://tools.ietf.org/html/rfc6143#section-7.5.4)
of the received key symbols to eg add an additional shift keypress
isn't implemented?

If yes, would a QEMU patch that adds keysymbol interpretation have a
chance to be merged into upstream?
Or are there reasons that it isn't a good idea to interpret the
VNC keysymbols and add/remove additional needed scancodes to get the expected
character on the VM?


regards

Fabian

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

[Gerhard Wiesinger]

Hello Fabian,

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.

Testcase in this order:
a => a
a => a
Shift-a => a (should be A)
a => A (should be a)
a => A (should be a)
a => A (should be a)
Shift-a => a (should be A)
a => A (should be a)
AltGr-? => ? (should be \)

So Shift states are not correctly implemented.

Also issues with CAPS-LOCK.

I'm always trying with:
QEMU started with: "-k de"
Keyboard layout in VM: de
Keyboard layout from Client OS: de

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

Ciao,
Gerhard

--
http://www.wiesinger.com/


On Wed, 7 Mar 2012, Fabian Holler wrote:

> Hello,
>
> I'm not sure if I found a bug in QEMU's VNC keysymbol to scancode
> mapping or if it is
> a general Problem with the implemented VNC server:
>
> Scenario:
> QEMU started with: "-k de"
> Keyboard layout in VM: de
> Keyboard layout from Client OS: us
>
> What i expect:
> I type the '/' character on the Client OS (key left from the
> right-shift-key) on US layout.
> key symbol '/' is send over VNC to the QEMU.
> QEMU lookup in the de keyboard mapping table for the character '/' and
> should find the scancodes for the keys shift+'7'.
> The Scancodes for shift and '7' are send to the VM's emulated keyboard
> controller and the '/' appears in the VM.
>
> But what actually happens is that the '7' character shows up in the VM.
> It seems that QEMU misses to generates an additional  Shift Scancode/Keypress.
>
> Is this a general problem in the VNC server implementation?
> So that an interpretation (http://tools.ietf.org/html/rfc6143#section-7.5.4)
> of the received key symbols to eg add an additional shift keypress
> isn't implemented?
>
> If yes, would a QEMU patch that adds keysymbol interpretation have a
> chance to be merged into upstream?
> Or are there reasons that it isn't a good idea to interpret the
> VNC keysymbols and add/remove additional needed scancodes to get the expected
> character on the VM?
>
>
> regards
>
> Fabian
>
>

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