qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Bug in SDL key event processing


From: Tomas Carnecky
Subject: [Qemu-devel] Bug in SDL key event processing
Date: Thu, 10 Jul 2008 01:27:49 +0200
User-agent: Thunderbird 2.0.0.14 (X11/20080621)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]