From: Tomas Carnecky <tom@dbservice.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Bug in SDL key event processing
Date: Thu, 10 Jul 2008 17:35:53 +0200 [thread overview]
Message-ID: <48762C59.9010204@dbservice.com> (raw)
In-Reply-To: <48761F31.4090909@codemonkey.ws>
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
next prev parent reply other threads:[~2008-07-10 15:36 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-09 23:27 [Qemu-devel] Bug in SDL key event processing Tomas Carnecky
2008-07-09 23:37 ` 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 [this message]
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=48762C59.9010204@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).