From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5EVn-0004tv-7d for qemu-devel@nongnu.org; Wed, 07 Mar 2012 05:54:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S5EVO-00038z-Cj for qemu-devel@nongnu.org; Wed, 07 Mar 2012 05:54:26 -0500 Received: from mail-ee0-f45.google.com ([74.125.83.45]:64582) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5EVO-00035Z-6J for qemu-devel@nongnu.org; Wed, 07 Mar 2012 05:54:02 -0500 Received: by eeit10 with SMTP id t10so2584970eei.4 for ; Wed, 07 Mar 2012 02:53:59 -0800 (PST) Date: Wed, 7 Mar 2012 11:53:57 +0100 From: Fabian Holler Message-ID: <20120307105357.GA30632@fholler.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] Keysymbol interpretation missing in QEMU's VNC server? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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 in the upstream version? Or are there reasons that it isn't a good idea to interpret the keysymbols for the scancode conversion? regards Fabian