Re: Qemu, VNC and non-US keymaps

[B3r3n <B3r3n@argosnet.com>]

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 :|