Re: Qemu, VNC and non-US keymaps

[B3r3n]

Hello Daniel,

> There is no mention here of what VNC client program is being used, which
> is quite important, as key handling is a big mess in VNC.
I tested with TightVNC & noVNC through Apache. Both behaves the same. 
I did not tested Ultr@VNC.


> The default VNC protocol passes X11 keysyms over the wire.
>
> The remote desktop gets hardware scancodes and turns them into keysyms,
> which the VNC client sees. The VNC client passes them to the VNC server
> in QEMU, which then has to turn them back into hardware scancodes. This
> reverse mapping relies on knowledge of the keyboard mapping, and is what
> the "-k fr" argument tells QEMU.
>
> For this to work at all, the keymap used by the remote desktop must
> match the keymap used by QEMU, which must match the keymap used by
> the guest OS.  Even this is not sufficient though, because the act
> of translating hardware scancodes into keysyms is *lossy*. There is
> no way to reliably go back to hardware scancodes, which is precisely
> what QEMU tries to do - some reverse mappings will be ambiguous.
Yes, I saw that topic passing by. Looks messy with all these interferences...

> Due to this mess, years ago (over a decade) QEMU introduced a VNC
> protocol extension that allows for passing hardware scancodes over
> the wire.
I guess I also crossed something about this on Internet.
Are you talking of the RFB protocol ?

> With this extension, the VNC client gets the hardware scancode
> from the remote desktop, and passes it straight to the VNC server,
> which passes it straight to the guest OS, which then applies the
> localized keyboard mapping.   This is good because the localized
> keyboard mapping conversion is now only done once, in the guest
> OS.
>
> To make use of this protocol extension to VNC, you must *NOT*
> pass any "-k" arg to QEMU, and must use a VNC client that has
> support for this protocol extension.  The GTK-VNC widget supports
> this and is used by virt-viewer, remote-viewer, virt-manager,
> GNOME Boxes, Vinagre client applications.  The TigerVNC client
> also supports this extension.
So if I read you, if the client "enforce" this protocol (supposed 
RFB), Qemu will automatically uses it as well ?
Removing -k option is great to me if it works, since user will have 
its own mapping and these are international :-)

> To summarize, my recommendation is to remove the "-k" arg entirely,
> and pick a VNC client that supports the scancode extension.
For now I am using TightVNC & noVNC. noVNC is precious since it 
widens the user world, removing any client software constraint.

> It is possible there might be a genuine bug in QEMU's 'fr' keymap
> that can be fixed to deal with AltGr problems. Personally though I
> don't spend time investigating these problems, as the broad reverse
> keymapping problem is unfixable. The only sensible option is to take
> the route of using the VNC hardware scancode extension. It is notable
> that SPICE learnt from VNC's mistake and used hardware scancodes from
> the very start.

This was another path I intend to follow : using SPICE and a 
"noSPICE" client if VNC was too painful.
If I understand you, using SPICE could also solve the issue ?

Many thanks for your inputs...

Brgrds



> Regards,
> Daniel
> --
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|