From: Erik Rull <erik.rull@rdsoftware.de>
To: Anthony Liguori <anthony@codemonkey.ws>,
Fabian Holler <fabian.holler@profitbricks.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Keysymbol interpretation missing in QEMU's VNC server?
Date: Wed, 23 May 2012 10:45:03 +0200 (CEST) [thread overview]
Message-ID: <403913480.100757.1337762703428.JavaMail.open-xchange@email.1und1.de> (raw)
In-Reply-To: <683578512.98476.1337760973834.JavaMail.open-xchange@email.1und1.de>
On May 23, 2012 at 10:16 AM Erik Rull <erik.rull@rdsoftware.de> wrote:
>
> On March 8, 2012 at 11:01 PM Fabian Holler
<fabian.holler@profitbricks.com>
> wrote:
>
> > Hello Anthony,
> >
> >
> > On Thu, Mar 08, 2012 at 03:30:18PM -0600, Anthony Liguori wrote:
> > > On 03/07/2012 04:53 AM, Fabian Holler wrote:
> > > >Hello,
> > > >
> > > >I'm not sure if I found a bug in QEMU's VNC keyboard layout mapping
or
> > > >if it's a general problem in the implemented VNC server:
> > > >
> > > >Scenario:
> > > >QEMU started with: "-k de"
> > > >Keyboard layout in VM: de
> > > >Keyboard layout from Client OS: us
> > > >
> > > >What i expect:
> > > >I type the '/' character on the Client OS (key left from the
> right-shift-key) on US layout.
> > > >Keysymbol '/' is send over VNC to the QEMU.
> > > >QEMU lookup in the de keyboard mapping table for the character '/'
and
> > > >should find the scancodes for the keys shift+'7'.
> > > >The Scancodes for shift and '7'
> > >
> > > This does not exist. There is no such thing as "Scancodes for shift
> and '7'".
> > >
> > > Instead, what's sent to the Client OS is literally, "the key at the
> > > fourth column, second row".
> >
> > Yes, I know.
> > What i actually meant was: with the knowledge of the used
> > keyboard layout and the key symbol QEMU could figure out that it has to
> > send scan codes for the keys that are labeled SHIFT & 7 on a keyboard
> > with DE layout.
> > Afaik QEMU does this already for the 7 labeled key. But it doesn't
> > remove/adds additional needed metakey presses like eg Shift.
> > Or I'm wrong?
> >
> > The idea was to add these interpretation to also add/remove additional
> > metakey scancodes for the VM if needed.
> >
> > > There's really nothing that can be done about this. The way gtk-vnc
> > > fixes this is by obtaining the actual scancode from the user's
> > > keyboard. But you can't get this in Java in an applet AFAIK.
> >
> > The same should work in a Java Applet but you also have to figure out
> > the used keyboard layout and handle metakeys.
> >
> >
> > regards
> >
> > Fabian
> >
>
>
> Hi all,
>
> I'm experiencing the same issues.
>
> When using the QEMU VNC server (which I would prefer to Remote Desktop or
a
> VNC server installed on the guest) I get problems when pressing special
> character keys on the remote keyboard. QEMU reports on the console:
> Warning: no scancode found for keysym 180
> or
> Warning: no scancode found for keysym 223
>
> I just want to route all keypresses to the guest without interfering with
> the native QEMU key layout. Is that possible? When running QEMU via SDL
and
> a real monitor and keyboard attached, I have no problems with the
different
> keyboard language layouts (I tested US, DE, ES, FR). Well - there I
switch
> the keyboard language layout in Windows for having all keypresses handled
> correctly (in most cases, Windows detects the correct keyboard layout
> automatically), but there is no change needed in the QEMU command line
when
> having different hardware attached!
>
> Any ideas how to resolve that? How does the QEMU VNC server receive the
key
> presses? In the same manner as the direct way does by getting scancodes
or
> via "real" characters?
> My requirement for the VNC usage is, that all clients that connect via
VNC
> can work independently of their client keyboard layout. The manual switch
> in Windows for getting the proper key translation is fine for the clients
> that use VNC.
>
> Best regards,
>
> Erik
>
Just a small addition: The AltGr Keys are not routed correctly through VNC!
I had a look at the "de" keymap, it looks as if they are described (e.g.
backslash \) which is placed on the german keyboard on the key right to the
0 key (german key ssharp) and accessed via AltGr + this key. Same with }
which is at the 0 key position accessed via AltGr + 0. The shifted keys and
the Windows standard functions Ctrl + C / Ctrl + V works as well.
They are not lost completely but the AltGr press gets lost! So when
pressing AltGr + 0, I get only a 0 on the guest instead of a "}".
Any ideas?
Best regards,
Erik
next prev parent reply other threads:[~2012-05-23 8:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-07 10:53 [Qemu-devel] Keysymbol interpretation missing in QEMU's VNC server? Fabian Holler
2012-03-08 20:24 ` Philipp Hahn
2012-03-08 21:23 ` Fabian Holler
2012-03-08 21:30 ` Anthony Liguori
2012-03-08 22:01 ` Fabian Holler
2012-05-23 8:16 ` Erik Rull
2012-05-23 8:45 ` Erik Rull [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-03-07 12:22 Fabian Holler
2014-01-14 8:45 Gonglei (Arei)
2014-01-25 5:13 Gonglei (Arei)
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=403913480.100757.1337762703428.JavaMail.open-xchange@email.1und1.de \
--to=erik.rull@rdsoftware.de \
--cc=anthony@codemonkey.ws \
--cc=fabian.holler@profitbricks.com \
--cc=qemu-devel@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).