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' are send to the VM's emulated keyboard controller and the '/' appears in the VM. But what actually happens is that the '7' character shows up in the VM. It seems that QEMU misses to also generate the Shift Scancode. Is this a general problem in the VNC server implementation? So that an interpretation (http://tools.ietf.org/html/rfc6143#section-7.5.4) of the received keysymbols to add eg an additional shift keypress never happens? If yes, would a QEMU patch that adds keysymbol interpretation have a chance to be merged into upstream? Or are there reasons that it isn't a good idea to interpret the keysymbols for the scancode conversion? regards Fabian
