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