Re: [Qemu-devel] Keysymbol interpretation missing in QEMU's VNC server?

[Anthony Liguori]

On 03/07/2012 04:53 AM, Fabian Holler wrote:
> Hello,
>
> I'm not sure if I found a bug in QEMU's VNC keyboard layout mapping or
> if it's a general problem in 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.
> Keysymbol '/' 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'

This does not exist.  There is no such thing as "Scancodes for shift and '7'".

Instead, what's sent to the Client OS is literally, "the key at the fourth 
column, second row".

The sticker that is on that key is unknown to the physical keyboard.  When you 
select a keyboard type in an OS, you're literally telling the OS what labels are 
on the physical keyboard.

Yes, it's almost mind blowing that in 2012, keyboards don't tell you what the 
labels on the keys are... but they don't.

When you tell QEMU to use '-k de', what you're telling it is to figure out what 
the right key is on a de keyboard for the label '/' which may be "the key at the 
second 8th column, second row" on a de keyboard, but on a US keyboard, it's a 7.

There's really nothing that can be done about this.  The way gtk-vnc fixes this 
is by obtaining the actual scancode from the user's keyboard.  But you can't get 
this in Java in an applet AFAIK.

Regards,

Anthony Liguori

 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 also generate the Shift Scancode.
>
> 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 keysymbols to add eg an additional shift keypress
> never happens?
>
> If yes would a QEMU patch that adds keysymbol interpretation have a
> chance to be merged in the upstream version?
> Or are there reasons that it isn't a good idea to interpret the
> keysymbols for the scancode conversion?
>
>
> regards
>
> Fabian