Hello, I'm not sure if I found a bug in QEMU's VNC keysymbol to scancode mapping or if it is a general Problem with 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. key symbol '/' 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 generates an additional Shift Scancode/Keypress. 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 key symbols to eg add an additional shift keypress isn't implemented? 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 VNC keysymbols and add/remove additional needed scancodes to get the expected character on the VM? regards Fabian
