Re: Qemu, VNC and non-US keymaps

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, May 11, 2020 at 04:24:32PM +0200, Philippe Mathieu-Daudé wrote:
> Cc'ing more developers.
> 
> On 5/11/20 4:17 PM, B3r3n wrote:
> > Dear all,
> > 
> > I am struggling for days/weeks with Qemu and its VNC accesses...with
> > non-US keymaps.
> > 
> > Let me summ the facts:
> > - I am using a french keyboard over a Ubuntu 18.04.
> > - I installed a simple Debian in a Qemu VM, configured with FR keyboard
> > (AZERTY).
> > - I am launching the Qemu VM with the '-k fr' keymaping (original)
> > - I tested with Qemu 3.1.1, 4.2.0 & 5.0.0.
> > 
> > I fail to have the AltGr keys, critical to frenches (pipe, backslash,
> > dash etc).
> > checking with showkey, I see the keys arriving properly (29+56, 29+100,
> > etc).

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.

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.

Due to this mess, years ago (over a decade) QEMU introduced a VNC
protocol extension that allows for passing hardware scancodes over
the wire.

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.

To summarize, my recommendation is to remove the "-k" arg entirely,
and pick a VNC client that supports the scancode extension.

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.

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