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