[Qemu-devel] Bug in SDL key event processing

[Qemu-devel] Bug in SDL key event processing

[Tomas Carnecky]

I just spend half day figuring out why my arrow keys and some other keys 
wouldn't work inside of the guest OS. Turns out you have a capital error 
in your SDL keyboard event parsing code.

Once the event hits sdl_process_key(), the function converts the event 
to a keycode. That depends on whether a keyboard layout has been loaded 
(-k en-us) or not. If not, it calls into sdl_keyevent_to_keycode() which 
  uses the SDL keyboard event scancode (presumably the X11 keycode) and 
converts it to keycodes that are then sent to the guest OS. The problem 
is that you assume a fixed layout of the X11 'scancodes', and use a 
table (x_keycode_to_pc_keycode) to convert those. Well, my xserver 
generates keycode=111 for the 'Up' key, which then your code translated 
to 'Print'. I tried changing the keymap files, but it didn't make any 
difference since qemu doesn't use those if no layout has been selected 
using the '-k' switch. If I load the en-use keymap, all keys work as 
expected.

Why is there OS (X11/Windows) specific code in the SDL frontend? And why 
does qemu need keymaps anyway? I would expect qemu to translate my 
keypresses to corresponding bios scancodes and do no further processing. 
  If you do that, you won't need the keymaps code, just a table to 
translate from SDL events to bios scancodes. For that you'd need just 
one table, holding ~322 elements. That's how many keysyms are defined in 
SDL.

tom

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

[Samuel Thibault]

Tomas Carnecky, le Thu 10 Jul 2008 01:27:49 +0200, a écrit :
> Why is there OS (X11/Windows) specific code in the SDL frontend? And why 
> does qemu need keymaps anyway?

The keymaps are for the VNC case, where you get a keyboard symbol, not a
keycode, so you need to know how to translate back into a scancode.

> I would expect qemu to translate my 
> keypresses to corresponding bios scancodes and do no further processing. 

Yep.

>  If you do that, you won't need the keymaps code, just a table to 
> translate from SDL events to bios scancodes.

In the SDL case that should work indeed.

Samuel

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

[Tomas Carnecky]

Samuel Thibault wrote:
> Tomas Carnecky, le Thu 10 Jul 2008 01:27:49 +0200, a écrit :
>> Why is there OS (X11/Windows) specific code in the SDL frontend? And why 
>> does qemu need keymaps anyway?
> 
> The keymaps are for the VNC case, where you get a keyboard symbol, not a
> keycode, so you need to know how to translate back into a scancode.

Well, every 'frontend' needs some kind of keymap table to map the events 
into bios scancodes. But there is no need to have user-editable keymap 
files. This mapping can be done entirely within the qemu code, within 
each of the frontends.


tom

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

[Samuel Thibault]

Tomas Carnecky, le Thu 10 Jul 2008 01:46:58 +0200, a écrit :
> Samuel Thibault wrote:
> >Tomas Carnecky, le Thu 10 Jul 2008 01:27:49 +0200, a écrit :
> >>Why is there OS (X11/Windows) specific code in the SDL frontend? And why 
> >>does qemu need keymaps anyway?
> >
> >The keymaps are for the VNC case, where you get a keyboard symbol, not a
> >keycode, so you need to know how to translate back into a scancode.
> 
> Well, every 'frontend' needs some kind of keymap table to map the events 
> into bios scancodes.

The VNC frontend can not do that without keymap information, and that
information can be shared, and should be shared

There is a fundamental difference between SDL and VNC:

- SDL gets keycode, i.e. the _positional_ number of a key, i.e. for
instance the 1st key of the second row, which happens to be a Q on a
qwerty keyboard. That can be translated into scancodes with a fixed map
table.
- VNC gets symbols, i.e. the _semantic_ of a key, i.e. for instance 'Q',
which has to be translated into a scancode, and there you have the
problem of the expected layout of the keyboard: should that be
translated into scancode for the 1st key of the 2nd row, or for the 1st
key of the 3rd row (because the user has an azerty keyboard).

Samuel

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

[Tomas Carnecky]

Samuel Thibault wrote:
> Tomas Carnecky, le Thu 10 Jul 2008 01:46:58 +0200, a écrit :
>> Samuel Thibault wrote:
>>> Tomas Carnecky, le Thu 10 Jul 2008 01:27:49 +0200, a écrit :
>>>> Why is there OS (X11/Windows) specific code in the SDL frontend? And why 
>>>> does qemu need keymaps anyway?
>>> The keymaps are for the VNC case, where you get a keyboard symbol, not a
>>> keycode, so you need to know how to translate back into a scancode.
>> Well, every 'frontend' needs some kind of keymap table to map the events 
>> into bios scancodes.
> 
> The VNC frontend can not do that without keymap information, and that
> information can be shared, and should be shared
> 
> There is a fundamental difference between SDL and VNC:
> 
> - SDL gets keycode, i.e. the _positional_ number of a key, i.e. for
> instance the 1st key of the second row, which happens to be a Q on a
> qwerty keyboard. That can be translated into scancodes with a fixed map
> table.
> - VNC gets symbols, i.e. the _semantic_ of a key, i.e. for instance 'Q',
> which has to be translated into a scancode, and there you have the
> problem of the expected layout of the keyboard: should that be
> translated into scancode for the 1st key of the 2nd row, or for the 1st
> key of the 3rd row (because the user has an azerty keyboard).
> 

Fair enough. I didn't know that.

But you said it yourself, SDL doesn't need the keymap table, it can 
translate the keycodes on its own. So where is the need to share the 
keymaps? Do other frontends need the keymaps as well?
Anyway, whatever you do, please don't try to be smart, parse the SDL 
'scancode' (which is the X11 keycode) and use that to get the 'real' 
scancode. Maybe that works under win32, but under linux, the SDL 
scancode isn't guaranteed to be usable as an index into your 
x_keycode_to_pc_keycode table.

tom

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

[Samuel Thibault]

Tomas Carnecky, le Thu 10 Jul 2008 02:09:04 +0200, a écrit :
> But you said it yourself, SDL doesn't need the keymap table, it can 
> translate the keycodes on its own. So where is the need to share the 
> keymaps?

I didn't say it needed to, I agree that it's odd it does. That said, see
what Anthony said, windows SDL seems to provide keysyms only.

> Do other frontends need the keymaps as well?

The ncurses one too.

> Anyway, whatever you do, please don't try to be smart, parse the SDL 
> 'scancode' (which is the X11 keycode) and use that to get the 'real' 
> scancode.

In that case we should rather use the SDL keysyms, and thus have to use
a translation table :/

Samuel

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

[Anthony Liguori]

Tomas Carnecky wrote:
> Fair enough. I didn't know that.
>
> But you said it yourself, SDL doesn't need the keymap table, it can 
> translate the keycodes on its own. So where is the need to share the 
> keymaps? Do other frontends need the keymaps as well?
> Anyway, whatever you do, please don't try to be smart, parse the SDL 
> 'scancode' (which is the X11 keycode) and use that to get the 'real' 
> scancode.

What you're saying is inaccurate.  It's a confusing topic, so it's 
useful to get terminology straight.

There are two values available in SDL.  The first is the SDL keyval.  
This is close to, but not guaranteed to be 100% compatible with X11 
keycodes.  You cannot get a PS/2 scancode directly from the keyval.  You 
must use a locale-specific translation table.

SDL also supports a hardware keycode field.  This field is not 
guaranteed to be filled out--it's not filled out on Windows.  As a 
user-friendly optimization, if there is a valid hardware keycode field, 
we use that instead of using the locale-specific translation table.  The 
hardware keycode field can be translated to a PS/2 scancode.

> Maybe that works under win32, but under linux, the SDL scancode isn't 
> guaranteed to be usable as an index into your x_keycode_to_pc_keycode 
> table.

What's lost in your ranting is a concise description of the problem 
you've encountered.  What behavior are you seeing and what behavior do 
you expect to see?  What kind of physical keyboard do you have and what 
is your keyboard configured as in your host and in your guest?  Are you 
using a '-k' option?

I'd be willing to wager that whatever problem you are encountering is a 
configuration error on your part (unless you're using a infrequently 
tested translation table).

Regards,

Anthony Liguori

> tom
>
>

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

[Tomas Carnecky]

Anthony Liguori wrote:
> What's lost in your ranting is a concise description of the problem 
> you've encountered.  What behavior are you seeing and what behavior do 
> you expect to see?  What kind of physical keyboard do you have and what 
> is your keyboard configured as in your host and in your guest?  Are you 
> using a '-k' option?

When I press the 'Up' key, the xserver generates an event with keycode 
111 (tested with xev). SDL repacks the XEvent to a SDL_KeyboardEvent 
with keycode=SDLK_UP and scancode=111. If I don't supply a keymap name 
(-k), QEMU uses the SDL scancode as the index into the 
x_keycode_to_pc_keycode table, but that table incorrectly translates it 
to 'Print'. If I use '-k en-us', the QEMU sets up a correct 
SDL-keysym-to-scancode table and then all keys work.
You cannot use the SDL scancode under X11, because there's no guarantee 
that it has any meaningful value. X11 clients have to translate they 
keycode to a keysym using XKeycodeToKeysym() to get the real value, 
which you can then for example compare with 'XK_Up'.

> I'd be willing to wager that whatever problem you are encountering is a 
> configuration error on your part (unless you're using a infrequently 
> tested translation table).

I ran vanilla kvm-userspace.git. Sure, it's not the same as qemu, but I 
doubt the kvm developers wrote that part of the code. I haven't modified 
any existing code or keymap files, just added a few printf()s to see 
what's going on.


tom

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

[Anthony Liguori]

Tomas Carnecky wrote:
> Anthony Liguori wrote:
>> What's lost in your ranting is a concise description of the problem 
>> you've encountered.  What behavior are you seeing and what behavior 
>> do you expect to see?  What kind of physical keyboard do you have and 
>> what is your keyboard configured as in your host and in your guest?  
>> Are you using a '-k' option?
>
> When I press the 'Up' key, the xserver generates an event with keycode 
> 111 (tested with xev). SDL repacks the XEvent to a SDL_KeyboardEvent 
> with keycode=SDLK_UP and scancode=111.

No.  keysym.sym = SDLK_UP.  scancode=111 presumably.

> If I don't supply a keymap name (-k), QEMU uses the SDL scancode as 
> the index into the x_keycode_to_pc_keycode table, but that table 
> incorrectly translates it to 'Print'. If I use '-k en-us', the QEMU 
> sets up a correct SDL-keysym-to-scancode table and then all keys work.

What I assume is happening is that your host keyboard is not setup as 
en-us but your guest is confused with en-us.  That would cause the 
behavior you're seeing.

>
> You cannot use the SDL scancode under X11, because there's no 
> guarantee that it has any meaningful value. X11 clients have to 
> translate they keycode to a keysym using XKeycodeToKeysym() to get the 
> real value, which you can then for example compare with 'XK_Up'.

What keyboard do you have?  What is your host and guest locale?

Regards,

Anthony Liguoiri

>> I'd be willing to wager that whatever problem you are encountering is 
>> a configuration error on your part (unless you're using a 
>> infrequently tested translation table).
>
> I ran vanilla kvm-userspace.git. Sure, it's not the same as qemu, but 
> I doubt the kvm developers wrote that part of the code. I haven't 
> modified any existing code or keymap files, just added a few printf()s 
> to see what's going on.
>
>
> tom
>
>
>

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

[Tomas Carnecky]

Anthony Liguori wrote:
> Tomas Carnecky wrote:
>> When I press the 'Up' key, the xserver generates an event with keycode 
>> 111 (tested with xev). SDL repacks the XEvent to a SDL_KeyboardEvent 
>> with keycode=SDLK_UP and scancode=111.
> 
> No.  keysym.sym = SDLK_UP.  scancode=111 presumably.

Yes, that's what I meant.

> What keyboard do you have?  What is your host and guest locale?

Host: Keyboard hardware is Logitech DiNovo Edge, connected via the 
supplied USB Bluetooth 2.0 dongle. Using evdev driver and hald to 
configure the keyboard, fdi policy file contains: model: evdev, layout: 
us, variant: colemak.

Guest: ubuntu 8.04.1, standard desktop installation with US layout

tom

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

[Anthony Liguori]

Tomas Carnecky wrote:
> Anthony Liguori wrote:
>> Tomas Carnecky wrote:
>>> When I press the 'Up' key, the xserver generates an event with 
>>> keycode 111 (tested with xev). SDL repacks the XEvent to a 
>>> SDL_KeyboardEvent with keycode=SDLK_UP and scancode=111.
>>
>> No.  keysym.sym = SDLK_UP.  scancode=111 presumably.
>
> Yes, that's what I meant.

And you're sure that your host layout is set to en-us?  The Up key 
should be scancode 98.

Regards,

Anthony Liguori

>> What keyboard do you have?  What is your host and guest locale?
>
> Host: Keyboard hardware is Logitech DiNovo Edge, connected via the 
> supplied USB Bluetooth 2.0 dongle. Using evdev driver and hald to 
> configure the keyboard, fdi policy file contains: model: evdev, 
> layout: us, variant: colemak.
>
> Guest: ubuntu 8.04.1, standard desktop installation with US layout
>
> tom
>
>

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

[Tomas Carnecky]

QEMU assumes that the xserver uses the xfree86 model. See files in 
/usr/share/X11/xkb/keycodes/, especially 'xfree86' and 'evdev'. The 
files translate from scancodes that the drivers generate into xserver 
keycodes. The xfree86 file has '<UP> = 98', meaning that if the xkb 
driver generates 98 it means the user pressed the UP key. When QEMU uses 
`98 - 97` as the index into the x_keycode_to_pc_keycode table, which 
yields the correct Up scancode. But the 'evdev' keycode file in the xkb 
directory has '<UP> = 111', meaning that the evdev driver generates 
keycode 111 for the UP key.

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.

Am I the only one who uses the evdev driver and runs QEMU? I can't 
believe that.

tom

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

[Samuel Thibault]

Tomas Carnecky, le Thu 10 Jul 2008 16:03:39 +0200, a écrit :
> Am I the only one who uses the evdev driver and runs QEMU? I can't 
> believe that.

evdev has been experimental for quite a long time. I don't know e.g. a
distribution that uses it by default. I hence wouldn't be surprised.

Samuel

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

[Tomas Carnecky]

Samuel Thibault wrote:
> Tomas Carnecky, le Thu 10 Jul 2008 16:03:39 +0200, a écrit :
>> Am I the only one who uses the evdev driver and runs QEMU? I can't 
>> believe that.
> 
> evdev has been experimental for quite a long time. I don't know e.g. a
> distribution that uses it by default. I hence wouldn't be surprised.

It's used by default if the xserver runs on Linux and uses 
auto-configuration (hald). That feature has been added in xorg 7.2 or 
so. Evdev is actually the preferred way to talk to keyboards and such 
under Linux. It has been stable for a couple years now (since 2.6?), and 
I've been using it ever since I remember it was available in the kernel.

tom

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

[Samuel Thibault]

Tomas Carnecky, le Thu 10 Jul 2008 16:20:12 +0200, a écrit :
> Samuel Thibault wrote:
> >Tomas Carnecky, le Thu 10 Jul 2008 16:03:39 +0200, a écrit :
> >>Am I the only one who uses the evdev driver and runs QEMU? I can't 
> >>believe that.
> >
> >evdev has been experimental for quite a long time. I don't know e.g. a
> >distribution that uses it by default. I hence wouldn't be surprised.
> 
> It's used by default if the xserver runs on Linux and uses 
> auto-configuration (hald). That feature has been added in xorg 7.2 or 
> so.

Oh? Not on the debian machines I've recently installed at least.

> Evdev is actually the preferred way to talk to keyboards and such 
> under Linux. It has been stable for a couple years now (since 2.6?),

Err, that's not what my X.org contacts say about evdev :)

I'm not talking about the implementation in the linux kernel, but the
mess arout keyboard configuration.

Samuel

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

[Anthony Liguori]

Tomas Carnecky wrote:
> QEMU assumes that the xserver uses the xfree86 model. See files in 
> /usr/share/X11/xkb/keycodes/, especially 'xfree86' and 'evdev'. The 
> files translate from scancodes that the drivers generate into xserver 
> keycodes. The xfree86 file has '<UP> = 98', meaning that if the xkb 
> driver generates 98 it means the user pressed the UP key. When QEMU 
> uses `98 - 97` as the index into the x_keycode_to_pc_keycode table, 
> which yields the correct Up scancode. But the 'evdev' keycode file in 
> the xkb directory has '<UP> = 111', meaning that the evdev driver 
> generates keycode 111 for the UP key.
>
> 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.

Regards,

Anthony Liguori

> Am I the only one who uses the evdev driver and runs QEMU? I can't 
> believe that.
>
> tom
>
>

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

[Tomas Carnecky]

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?

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.
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'.
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.

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.


tom

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

[Samuel Thibault]

Tomas Carnecky, le Thu 10 Jul 2008 17:35:53 +0200, a écrit :
> -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.

It's not so simple. Think about shifted keysyms.

Samuel

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
>
>

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

[Tomas Carnecky]

Anthony Liguori wrote:
> 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.

I expect distributions and users to use xorg autoconfiguration in the 
future. It's especially useful for laptop users, because you can plug in 
devices and they 'just work'. I may be one of the first, but certainly 
not the only one to ever use evdev.

tom

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

[Samuel Thibault]

Anthony Liguori, le Thu 10 Jul 2008 14:25:05 -0500, a écrit :
> >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.

That won't for the shifted characters. Let's take for instance azerty,
which has the numbers in the shifted position instead of the direct
position. Typing shift+1 will produce a 1 keysym, which will indeed be
converted to the correct scancode, but shift will be simulated too, and
thus produce in the guest '!'... There is no other correct than properly
reverse-engineering the keysyms we get into a positional keycode, and
then convert to PS2 scancode, and let the guest use its keymaps..

Samuel

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

[Anthony Liguori]

Samuel Thibault wrote:
> Anthony Liguori, le Thu 10 Jul 2008 14:25:05 -0500, a écrit :
>   
>>> 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.
>>     
>
> That won't for the shifted characters. Let's take for instance azerty,
> which has the numbers in the shifted position instead of the direct
> position. Typing shift+1 will produce a 1 keysym, which will indeed be
> converted to the correct scancode, but shift will be simulated too, and
> thus produce in the guest '!'...

Yes, unfortunately, I don't see a great way to fix that :-/  You 
basically have to have the guest also set up to use azerty.

>  There is no other correct than properly
> reverse-engineering the keysyms we get into a positional keycode, and
> then convert to PS2 scancode, and let the guest use its keymaps..
>   

Which is what we're trying to do.  The issue is that the 
keysyms=>positional keycode mapping is 1->many.  That's what the -k 
mappings are selecting.

Regards,

Anthony Liguroi

> Samuel
>
>
>   

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

[Samuel Thibault]

Anthony Liguori, le Thu 10 Jul 2008 17:03:23 -0500, a écrit :
> Which is what we're trying to do.  The issue is that the 
> keysyms=>positional keycode mapping is 1->many.  That's what the -k 
> mappings are selecting.

Yep.

In the X11 case, however, we could use XKB extensions to get it from the
server, just like xkbprint does.  Maybe windows has a way to know which
keyboard layout is currently in use, and use the qemu keymap according
to that.

Samuel

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

[Ian Jackson]

Samuel Thibault writes ("Re: [Qemu-devel] Bug in SDL key event processing"):
> That won't for the shifted characters. Let's take for instance azerty,
> which has the numbers in the shifted position instead of the direct
> position. Typing shift+1 will produce a 1 keysym, which will indeed be
> converted to the correct scancode, but shift will be simulated too, and
> thus produce in the guest '!'... There is no other correct than properly
> reverse-engineering the keysyms we get into a positional keycode, and
> then convert to PS2 scancode, and let the guest use its keymaps..

Well, one alternative approach would be to simulate a shift down
event, followed by the key in question, followed by a shift up event.

Ian.

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

[Samuel Thibault]

Ian Jackson, le Mon 14 Jul 2008 17:02:50 +0100, a écrit :
> Samuel Thibault writes ("Re: [Qemu-devel] Bug in SDL key event processing"):
> > That won't for the shifted characters. Let's take for instance azerty,
> > which has the numbers in the shifted position instead of the direct
> > position. Typing shift+1 will produce a 1 keysym, which will indeed be
> > converted to the correct scancode, but shift will be simulated too, and
> > thus produce in the guest '!'... There is no other correct than properly
> > reverse-engineering the keysyms we get into a positional keycode, and
> > then convert to PS2 scancode, and let the guest use its keymaps..
> 
> Well, one alternative approach would be to simulate a shift down
> event, followed by the key in question, followed by a shift up event.

Uuuggghh (to say the least).

Even more tricky.  I have an azerty keyboard.  To type '\' I press
alt-gr + '8'.  Qemu receives a '\' keysym, with altgr being pressed.
How do you know that that alt-gr is to be dropped (because it's an
artifact of the azerty keyboard) or kept as is (in the qwerty case one
may want to have an alt-gr + '\' shortcut)?

Samuel

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

[Ian Jackson]

Anthony Liguori writes ("Re: [Qemu-devel] Bug in SDL key event processing"):
> This is because of your weird evdev scancodes.  QEMU expects the 
> scancodes to be xfree86, not evdev.

Well, yes, but as Tomas Carnecky points out that is not a legitimate
assumption.  Specific keycode values are not a published part of the X
protocol; applications are supposed to use keysyms.

Indeed there exist physical X terminals (I have one at home) which use
different keycode values.  I can only assume that no-one with one of
these has used qemu and known how to report the resulting
misbehaviour.

Ian.

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

[Anthony Liguori]

Samuel Thibault wrote:
> Tomas Carnecky, le Thu 10 Jul 2008 01:27:49 +0200, a écrit :
>   
>> Why is there OS (X11/Windows) specific code in the SDL frontend? And why 
>> does qemu need keymaps anyway?
>>     
>
> The keymaps are for the VNC case, where you get a keyboard symbol, not a
> keycode, so you need to know how to translate back into a scancode.
>   

Actually the keymap is for the case where hardware keycodes are not 
available.  The guest needs hardware keycodes and you typically only get 
symbolic keycodes.  The conversion from symbolic keycodes to hardware 
keycodes is a 1->many translation so a user needs to explicitly set what 
the translation is.  You could possibly autoguess it by trying to get 
locale information I guess.

SDL in Linux happens to provide hardware keycode information so we don't 
need to use a keymap.  This is not true on Windows SDL though IIRC.  
Likewise, under normal circumstances, hardware keycodes are not 
available through VNC.

>> I would expect qemu to translate my 
>> keypresses to corresponding bios scancodes and do no further processing. 
>>     
>
> Yep.
>
>   
>>  If you do that, you won't need the keymaps code, just a table to 
>> translate from SDL events to bios scancodes.
>>     
>   

The problem is this is a 1->many translation.  It all depends on what 
hardware keyboard you are emulation.  That is really what you are 
choosing when you provide a -k option.

Regards,

Anthony Liguori

> In the SDL case that should work indeed.
>
> Samuel
>
>
>   

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

[Jamie Lokier]

Anthony Liguori wrote:
> The guest needs hardware keycodes

By the way, is this necessarily true if it emulated a USB keyboard?

I'm wondering if USB keyboards can report what symbols are on each
keycap, and if some guests can use that information automatically, so
even when hardware keycodes are wrong, they might still map host key
symbols to guest key symbols correctly.

I don't know much about USB keyboards, just that they can report a
large block of information about themselves, and wondered if this
might be possible.

-- Jamie

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

[Samuel Thibault]

Jamie Lokier, le Thu 10 Jul 2008 13:03:30 +0100, a écrit :
> Anthony Liguori wrote:
> > The guest needs hardware keycodes
> 
> By the way, is this necessarily true if it emulated a USB keyboard?

IIRC yes, and that's sad, because it makes hard to build a keyboard that
has, say, just letters A-F.

Samuel

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

[Juergen Keil]

> QEMU assumes that the xserver uses the xfree86 model. See files in 
> /usr/share/X11/xkb/keycodes/, especially 'xfree86' and 'evdev'. The 
> files translate from scancodes that the drivers generate into xserver 
> keycodes. The xfree86 file has '<UP> = 98', meaning that if the xkb 
> driver generates 98 it means the user pressed the UP key. When QEMU uses 
> `98 - 97` as the index into the x_keycode_to_pc_keycode table, which 
> yields the correct Up scancode. But the 'evdev' keycode file in the xkb 
> directory has '<UP> = 111', meaning that the evdev driver generates 
> keycode 111 for the UP key.
> 
> 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.
> 
> Am I the only one who uses the evdev driver and runs QEMU? I can't 
> believe that.

Yes, the same issue exists when displaying to a non-Xorg server,
e.g. the Xsun server on a Solaris/SPARC.

With an US English layout keyboard on the Solaris/SPARC machine,
I get keycode 27 in xev (which translates to keysym 0xff52, "Up").

Qemu's sdl keyboard layout is broken when displaying to Xsun, unless I 
use "-k en-us".