qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

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