From: "Daniel P. Berrangé" <berrange@redhat.com>
To: B3r3n <B3r3n@argosnet.com>
Cc: qemu-discuss@nongnu.org,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
"Gerd Hoffmann" <kraxel@redhat.com>
Subject: Re: Qemu, VNC and non-US keymaps
Date: Mon, 11 May 2020 18:19:30 +0100 [thread overview]
Message-ID: <20200511171930.GS1135885@redhat.com> (raw)
In-Reply-To: <20200511152957.6CFA8D1826@zmta04.collab.prod.int.phx2.redhat.com>
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 :|
next prev parent reply other threads:[~2020-05-11 17:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1jY9FF-0000Po-2c@lists.gnu.org>
2020-05-11 14:24 ` Qemu, VNC and non-US keymaps Philippe Mathieu-Daudé
2020-05-11 14:31 ` LAHAYE Olivier
2020-05-11 15:11 ` Daniel P. Berrangé
2020-05-11 15:29 ` B3r3n
[not found] ` <20200511152957.6CFA8D1826@zmta04.collab.prod.int.phx2.redhat.com>
2020-05-11 17:19 ` Daniel P. Berrangé [this message]
2020-05-12 7:45 ` B3r3n
[not found] ` <20200512074530.8729D1892D3@zmta01.collab.prod.int.phx2.redhat.com>
2020-05-12 9:11 ` Daniel P. Berrangé
2020-05-12 16:30 ` B3r3n
2020-05-13 8:38 ` B3r3n
2020-05-13 8:42 ` Daniel P. Berrangé
2020-05-13 9:13 ` B3r3n
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200511171930.GS1135885@redhat.com \
--to=berrange@redhat.com \
--cc=B3r3n@argosnet.com \
--cc=kraxel@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-discuss@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).