qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Keysymbol interpretation missing in QEMU's VNC server?


From: Erik Rull
Subject: Re: [Qemu-devel] Keysymbol interpretation missing in QEMU's VNC server?
Date: Wed, 23 May 2012 10:45:03 +0200 (CEST)

 On May 23, 2012 at 10:16 AM Erik Rull <address@hidden> wrote:

>
> On March 8, 2012 at 11:01 PM Fabian Holler
<address@hidden>
> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]