qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: B3r3n <B3r3n@argosnet.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Philippe Mathieu-Daudé" <philmd@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	qemu-discuss@nongnu.org
Subject: Re: Qemu, VNC and non-US keymaps
Date: Tue, 12 May 2020 09:45:20 +0200	[thread overview]
Message-ID: <E1jYPbT-0005ig-H5@lists.gnu.org> (raw)
In-Reply-To: <20200511171930.GS1135885@redhat.com>

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



  reply	other threads:[~2020-05-12  7:46 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é
2020-05-12  7:45         ` B3r3n [this message]
     [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=E1jYPbT-0005ig-H5@lists.gnu.org \
    --to=b3r3n@argosnet.com \
    --cc=berrange@redhat.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).