On May 23, 2012 at 10:16 AM Erik Rull <erik.r...@rdsoftware.de> wrote:
> > On March 8, 2012 at 11:01 PM Fabian Holler <fabian.hol...@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
