Re: [Qemu-devel] Bug in SDL key event processing

[Anthony Liguori]

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