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