[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Qemu, VNC and non-US keymaps

From: B3r3n
Subject: Re: Qemu, VNC and non-US keymaps
Date: Mon, 11 May 2020 17:29:48 +0200

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

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


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]