On Mon, May 11, 2020 at 05:29:48PM +0200, B3r3n wrote: > 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.
AFAIK, neithe TightVNC nor Ultra@VNC support the scancode extension. noVNC does, for most modern browsers, so it might work if you remove the -k arg from QEMU. > > 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 ? Yes, RFB protocol is the technical name for the VNC wire 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 ? The client should automatically activate the extension if QEMU advertizes it, and QEMU advertizes it if you remove the -k arg. > 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. As above, noVNC ought to support the 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. > > 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... 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 :|