Re: Qemu, VNC and non-US keymaps

Re: Qemu, VNC and non-US keymaps

[Philippe Mathieu-Daudé]

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).
> 
> Considering it might be a debian issue as well, I updated the 
> qemu/keymaps/fr file to have bar directly with the 6 key (normally bar 
> is AltGr + 6).
> For an unknown reason, the '6' then no longer works (showkey shows 
> nothing as well).
> 
> There might be something I miss, and the might also be some bug 
> somewhere, or some missings.
> For example, maybe X11 must be installed, even it unused (VNC client 
> connects to Qemu VNC port directly), or whatever.
> 
> Any help appreciated :-)
> 
> Thanks
> 
> Brgrds
> 
> 

Re: Qemu, VNC and non-US keymaps

[LAHAYE Olivier]

I have a similar problem with qemu (all versions including 5.0.0) on MacOS-10.14.6 (mac book pro 2017with touch bar).

Using -k fr-mac the "@"/"#" key is dead.
Showkey doesn't detect the key.
Moreover, the # and @ symbols are mapped on the "<" / ">" key and thus I miss the redirection operator in shell.

Cheers,

Olivier.

Le 11/05/2020 16:25, « Qemu-discuss au nom de Philippe Mathieu-Daudé » <qemu-discuss-bounces+olivier.lahaye=cea.fr@nongnu.org au nom de philmd@redhat.com> a écrit :

    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).
    > 
    > Considering it might be a debian issue as well, I updated the 
    > qemu/keymaps/fr file to have bar directly with the 6 key (normally bar 
    > is AltGr + 6).
    > For an unknown reason, the '6' then no longer works (showkey shows 
    > nothing as well).
    > 
    > There might be something I miss, and the might also be some bug 
    > somewhere, or some missings.
    > For example, maybe X11 must be installed, even it unused (VNC client 
    > connects to Qemu VNC port directly), or whatever.
    > 
    > Any help appreciated :-)
    > 
    > Thanks
    > 
    > Brgrds
    > 
    > 
    
    
    

Re: Qemu, VNC and non-US keymaps

[Daniel P. Berrangé]

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

Re: Qemu, VNC and non-US keymaps

[B3r3n]

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

Brgrds



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

Re: Qemu, VNC and non-US keymaps

[Daniel P. Berrangé]

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

Re: Qemu, VNC and non-US keymaps

[B3r3n]

Hello Daniel, all,

I am a bit confused.

Ok, RFB protocol should be the solution that solves all, sending 
scancodes rather than doing keysyms stuff. No pb for me.
So I removed my '-k fr' to my Qemu VM start as it was before.

However, reading TightVNC & noVNC docs, both are able to perform RFB.

Since these explanations, I replayed a bit:

Under my testing Debian 10, I redefined keyboard to French + No 
compose key + AltGr as CTRL_R

Under noVNC: Ctrl_R works well as alternative but when using AltGr, I 
received 29+100+7 (AltGr + 6) and keep displaying a minus as with 
AltGr was not pressed.

Under TightVNC (2.7.10) : Ctrl_R displays characters, I am still in 
QWERTY for letters, weird mapping for other characters, did not 
checked if compliant with whatever definition.
Under TightVNC (last 2.8.27, supposed to be able to RFB): Ctrl_R 
displays nothing, keys are QWERTY. Seems the same as TightVNC 2.7.10.

With the keyboard defining AltGr as AltGr, no change.

I realize that AltGr is sending 29+100 (seen via showkey), when 
CTRL_R only sends 97.
When using a remote console (iLo and iDRAC), AltGr only sends 100.

I wonder if the issue would not also be the fact AltGr sends 2 codes, 
still another one to select the character key (6 for example).

Is that normal Qemu is transforming AltGr (100) in 29+100 ?

Thanks

Brgrds

Re: Qemu, VNC and non-US keymaps

[Daniel P. Berrangé]

On Tue, May 12, 2020 at 09:45:20AM +0200, B3r3n wrote:
> Hello Daniel, all,
> 
> I am a bit confused.
> 
> Ok, RFB protocol should be the solution that solves all, sending scancodes
> rather than doing keysyms stuff. No pb for me.
> So I removed my '-k fr' to my Qemu VM start as it was before.
> 
> However, reading TightVNC & noVNC docs, both are able to perform RFB.

VNC == RFB - they're two different terms of the same thing.

The core RFB/VNC protocol only knows about keysyms.

Hardware scancodes is an extension defined by QEMU, and GTK-VNC, and since
implemented by TigerVNC.

Removing the "-k" arg, merely enables use of the scancode extension.
This requires a compatible client app that knows the scancode extension.
If the client doesn't support scancodes, it will continue using keysyms,
which will then be treated as plain us keymap.

AFAIK,  TightVNC doesn't support the scancode extension, only TigerVNC.

> Since these explanations, I replayed a bit:
> 
> Under my testing Debian 10, I redefined keyboard to French + No compose key
> + AltGr as CTRL_R

This is a key example of the problems of VNC's traditional key handling.

QEMU has a single keymap "fr". It has no way of selecting compose key
on/off, or overriding AltGr to be CtrlR.  So as soon as you do that on
your local desktop, you make it impossible to QEMU VNC serve to work
correctly.

> 
> Under noVNC: Ctrl_R works well as alternative but when using AltGr, I
> received 29+100+7 (AltGr + 6) and keep displaying a minus as with AltGr was
> not pressed.
> 
> Under TightVNC (2.7.10) : Ctrl_R displays characters, I am still in QWERTY
> for letters, weird mapping for other characters, did not checked if
> compliant with whatever definition.
> Under TightVNC (last 2.8.27, supposed to be able to RFB): Ctrl_R displays
> nothing, keys are QWERTY. Seems the same as TightVNC 2.7.10.
> 
> With the keyboard defining AltGr as AltGr, no change.
> 
> I realize that AltGr is sending 29+100 (seen via showkey), when CTRL_R only
> sends 97.
> When using a remote console (iLo and iDRAC), AltGr only sends 100.
> 
> I wonder if the issue would not also be the fact AltGr sends 2 codes, still
> another one to select the character key (6 for example).
> 
> Is that normal Qemu is transforming AltGr (100) in 29+100 ?

It is hard to say without seeing debuging to see what QEMU received.

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

Re: Qemu, VNC and non-US keymaps

[B3r3n]

Dear all,

>VNC == RFB - they're two different terms of the same thing.
>
>The core RFB/VNC protocol only knows about keysyms.
Ok, so RFB is not the keyword to track :-(

>AFAIK,  TightVNC doesn't support the scancode extension, only TigerVNC.
Confirmed, I replaced TightVNC viewer by TigerVNC, solves the issue. 
I got AltGr working + Ctrl_R acting as AltGr (my Debian kbd definition).
With this client, it is fine.

About this issue:
> > I realize that AltGr is sending 29+100 (seen via showkey), when CTRL_R only
> > sends 97.
> > When using a remote console (iLo and iDRAC), AltGr only sends 100.
> >
> > I wonder if the issue would not also be the fact AltGr sends 2 codes, still
> > another one to select the character key (6 for example).
> >
> > Is that normal Qemu is transforming AltGr (100) in 29+100 ?
>
>It is hard to say without seeing debuging to see what QEMU received.

I saw Qemu must be compile with debug support, ok.
 From this, if you have a recommendation, specific config to setup to 
debug the particular keyboard, I can do that.

To me the issue is here since a single keyboard key should produce a 
single keycode. Since my PC does not send 2 keys (else TigerVNC or 
noVNC would behave the same), it is elsewhere...

Thanks

Brgrds

Re: Qemu, VNC and non-US keymaps

[B3r3n]

Hello Daniel,

Ok, TigerVNC, added -shared=1 to behave the same 
as TightVNC, works greatly, Thanks !

But funny thing, I saw you were part of exchanges 
on that topic, noVNC totally fails now.
Despite my keyboard isnt changed, debian VM is 
just in QWERTY as if noVNC only send keysyms.

If you know how to force noVNC keycodes instead, digging to find the trick :-(

Thanks

Brgrds

At 11:11 12/05/2020, Daniel P. Berrangé wrote:
>On Tue, May 12, 2020 at 09:45:20AM +0200, B3r3n wrote:
> > Hello Daniel, all,
> >
> > I am a bit confused.
> >
> > Ok, RFB protocol should be the solution that solves all, sending scancodes
> > rather than doing keysyms stuff. No pb for me.
> > So I removed my '-k fr' to my Qemu VM start as it was before.
> >
> > However, reading TightVNC & noVNC docs, both are able to perform RFB.
>
>VNC == RFB - they're two different terms of the same thing.
>
>The core RFB/VNC protocol only knows about keysyms.
>
>Hardware scancodes is an extension defined by QEMU, and GTK-VNC, and since
>implemented by TigerVNC.
>
>Removing the "-k" arg, merely enables use of the scancode extension.
>This requires a compatible client app that knows the scancode extension.
>If the client doesn't support scancodes, it will continue using keysyms,
>which will then be treated as plain us keymap.
>
>AFAIK,  TightVNC doesn't support the scancode extension, only TigerVNC.
>
> > Since these explanations, I replayed a bit:
> >
> > Under my testing Debian 10, I redefined keyboard to French + No compose key
> > + AltGr as CTRL_R
>
>This is a key example of the problems of VNC's traditional key handling.
>
>QEMU has a single keymap "fr". It has no way of selecting compose key
>on/off, or overriding AltGr to be CtrlR.  So as soon as you do that on
>your local desktop, you make it impossible to QEMU VNC serve to work
>correctly.
>
> >
> > Under noVNC: Ctrl_R works well as alternative but when using AltGr, I
> > received 29+100+7 (AltGr + 6) and keep displaying a minus as with AltGr was
> > not pressed.
> >
> > Under TightVNC (2.7.10) : Ctrl_R displays characters, I am still in QWERTY
> > for letters, weird mapping for other characters, did not checked if
> > compliant with whatever definition.
> > Under TightVNC (last 2.8.27, supposed to be able to RFB): Ctrl_R displays
> > nothing, keys are QWERTY. Seems the same as TightVNC 2.7.10.
> >
> > With the keyboard defining AltGr as AltGr, no change.
> >
> > I realize that AltGr is sending 29+100 (seen via showkey), when CTRL_R only
> > sends 97.
> > When using a remote console (iLo and iDRAC), AltGr only sends 100.
> >
> > I wonder if the issue would not also be the fact AltGr sends 2 codes, still
> > another one to select the character key (6 for example).
> >
> > Is that normal Qemu is transforming AltGr (100) in 29+100 ?
>
>It is hard to say without seeing debuging to see what QEMU received.
>
>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 :|

Re: Qemu, VNC and non-US keymaps

[Daniel P. Berrangé]

On Wed, May 13, 2020 at 10:38:52AM +0200, B3r3n wrote:
> Hello Daniel,
> 
> Ok, TigerVNC, added -shared=1 to behave the same as TightVNC, works greatly,
> Thanks !
> 
> But funny thing, I saw you were part of exchanges on that topic, noVNC
> totally fails now.
> Despite my keyboard isnt changed, debian VM is just in QWERTY as if noVNC
> only send keysyms.
> 
> If you know how to force noVNC keycodes instead, digging to find the trick :-(

Looking at the current git master code AFAICT it should "just work"
unless you have an older version of it perhaps


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

Re: Qemu, VNC and non-US keymaps

[B3r3n]

Hello Daniel,

I guess it is time for me to commit 
suicide...when you dont think about the basics : software version :-(

Was 1.0.4, moved to 1.1.0, no issue

DONT BECOME OLD ! :-)

thanks!

At 10:42 13/05/2020, Daniel P. Berrangé wrote:
>On Wed, May 13, 2020 at 10:38:52AM +0200, B3r3n wrote:
> > Hello Daniel,
> >
> > Ok, TigerVNC, added -shared=1 to behave the 
> same as TightVNC, works greatly,
> > Thanks !
> >
> > But funny thing, I saw you were part of exchanges on that topic, noVNC
> > totally fails now.
> > Despite my keyboard isnt changed, debian VM is just in QWERTY as if noVNC
> > only send keysyms.
> >
> > If you know how to force noVNC keycodes 
> instead, digging to find the trick :-(
>
>Looking at the current git master code AFAICT it should "just work"
>unless you have an older version of it perhaps
>
>
>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 :|