From: Tomas Carnecky <tom@dbservice.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Bug in SDL key event processing
Date: Thu, 10 Jul 2008 01:27:49 +0200 [thread overview]
Message-ID: <48754975.1050303@dbservice.com> (raw)
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
next reply other threads:[~2008-07-09 23:28 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-09 23:27 Tomas Carnecky [this message]
2008-07-09 23:37 ` [Qemu-devel] Bug in SDL key event processing Samuel Thibault
2008-07-09 23:46 ` Tomas Carnecky
2008-07-09 23:55 ` Samuel Thibault
2008-07-10 0:09 ` Tomas Carnecky
2008-07-10 0:20 ` Samuel Thibault
2008-07-10 3:19 ` Anthony Liguori
2008-07-10 7:56 ` Tomas Carnecky
2008-07-10 13:35 ` Anthony Liguori
2008-07-10 13:43 ` Tomas Carnecky
2008-07-10 13:56 ` Anthony Liguori
2008-07-10 14:03 ` Tomas Carnecky
2008-07-10 14:10 ` Samuel Thibault
2008-07-10 14:20 ` Tomas Carnecky
2008-07-10 14:49 ` Samuel Thibault
2008-07-10 14:39 ` Anthony Liguori
2008-07-10 15:35 ` Tomas Carnecky
2008-07-10 15:51 ` Samuel Thibault
2008-07-10 19:25 ` Anthony Liguori
2008-07-10 19:51 ` Tomas Carnecky
2008-07-10 21:55 ` Samuel Thibault
2008-07-10 22:03 ` Anthony Liguori
2008-07-10 22:14 ` Samuel Thibault
2008-07-14 16:02 ` Ian Jackson
2008-07-14 16:27 ` Samuel Thibault
2008-07-14 16:01 ` Ian Jackson
2008-07-09 23:52 ` Anthony Liguori
2008-07-10 12:03 ` Jamie Lokier
2008-07-10 12:24 ` Samuel Thibault
-- strict thread matches above, loose matches on Subject: below --
2008-07-10 14:22 Juergen Keil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48754975.1050303@dbservice.com \
--to=tom@dbservice.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).