From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KH1lp-0002Cj-Dm for qemu-devel@nongnu.org; Thu, 10 Jul 2008 15:25:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KH1lo-0002Ba-Ou for qemu-devel@nongnu.org; Thu, 10 Jul 2008 15:25:37 -0400 Received: from [199.232.76.173] (port=38908 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KH1lo-0002BL-Jm for qemu-devel@nongnu.org; Thu, 10 Jul 2008 15:25:36 -0400 Received: from py-out-1112.google.com ([64.233.166.183]:58765) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KH1lo-0003jy-7W for qemu-devel@nongnu.org; Thu, 10 Jul 2008 15:25:36 -0400 Received: by py-out-1112.google.com with SMTP id p76so1938272pyb.10 for ; Thu, 10 Jul 2008 12:25:35 -0700 (PDT) Message-ID: <48766211.2090304@codemonkey.ws> Date: Thu, 10 Jul 2008 14:25:05 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Bug in SDL key event processing References: <48754975.1050303@dbservice.com> <20080709233752.GL4889@implementation> <48754DF2.2010704@dbservice.com> <20080709235516.GM4889@implementation> <48755320.5090707@dbservice.com> <48757FB8.8010400@codemonkey.ws> <4875C0B6.2060302@dbservice.com> <4876101A.1080800@codemonkey.ws> <487611FC.5070500@dbservice.com> <487616BB.8020402@dbservice.com> <48761F31.4090909@codemonkey.ws> <48762C59.9010204@dbservice.com> In-Reply-To: <48762C59.9010204@dbservice.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Tomas Carnecky wrote: > Anthony Liguori wrote: >> Tomas Carnecky wrote: >>> Again, you _can not_ assume that the X keycode (XKeyEvent.keycode or >>> SDL_KeyboardEvent.scancode) has any particular meaning. If you run >>> on pure X11, you have to translate it into a keysym >>> (XKeycodeToKeysym()) and use that instead. If you run on SDL, you >>> have to use keysym.sym. >> >> Having to use keysym.sym means that -k is *always* required. So it >> looks like we need to detect when the keycodes translation is not >> xfree86 and insist that a -k option is passed. > > What does '-k' actually mean? It's not the current layout I use in > X11. Is it the layout that the VM uses? It's the type of hardware keyboard being exposed to the guest. It has the side effect of always processing keysyms instead of scancodes. > Keep in mind that using '-k' completely changes the semantics of the > keyboard. I'm using the colemak layout, so my top row is: qwfpg. For > the sake of simplicity, assume that the guest uses the standard en-us > layout. Then you would need to add a colemak translation table if you wanted that to be reflected in the guest. However, if you use -k en-us and use en-us in the guest, it should just work for you. > Now let's go through what happens when I press the third key of the > top row (labeled 'e' on standard US keyboard). Without the '-k' > switch, qemu uses the X11 keycode (26) and translates that into the > corresponding scancode. The VM then receives '0x12'. The guest will > then translate it to an 'e'. This is because of your weird evdev scancodes. QEMU expects the scancodes to be xfree86, not evdev. > Now let's see what happens when I use '-k en-us': When I press the > third key of the top row, qemu receives a SDLK_F keyboard event. > Because I loaded the en-us layout, the qemu sdl frontend translates > the event into '0x21' and sends that to the VM. The guest will then > translate it to a 'f'. > > Without '-k', the mapping is purely 'positional', qemu tries to guess > which physical key was pressed on the keyboard, and send the > corresponding scancode to the guest. With '-k' qemu translates the > events according to their meaning (the user meant to send me a 'f') > and generates the corresponding scancode. The issue is that we always assume scancodes from the xfree86 keycodes. We have one translation table that converts from xfree86=>ps/2. The real fix for this problem would be to detect what the current xkb keycode is, and then use an appropriate translation to generate ps/2 scancodes. Honestly though, this is the first time I've seen this problem come up. Patches are certainly welcome but this appears to be a very odd case. I think you're asking for trouble using evdev. > Please consider making the -k switch easier to understand. I'd suggest > having two modes: > > -k raw[=model]: when the user presses the top left key, generate a > scancode corresponding to the top left key. Use 'model' to translate > the SDL scancode (possible useful for other frontends as well). > > -k map[=keymap]: Guest OS uses this keymap: 'keymap'. When the user > presses 'f', send whatever scancode is needed to have the guest > generate 'f'. > > > I'd expect -k map=en-us to be the default. That way the user doesn't > have to change the layout in each of the VMs (just tell them to use > en-us when installing the guest). When he/she changes the layout in > the host, it will be 'changed' in all guests as well. The problem with that is that it forces non en-us users to specify a -k option. Right now, as long as you use the xfree86 keycodes for xkb, SDL will Just Work regardless of what your keyboard layout is. There are far more non en-us users than en-us users who have an odd xkb keycodes. Regards, Anthony Liguori > > tom > >