* [Qemu-devel] Definition of the UI layer's "key number" ?
@ 2015-02-05 17:36 Peter Maydell
2015-02-09 8:27 ` Gerd Hoffmann
0 siblings, 1 reply; 4+ messages in thread
From: Peter Maydell @ 2015-02-05 17:36 UTC (permalink / raw)
To: QEMU Developers, Gerd Hoffmann
Hi; I'm trying to find out what the UI layer's definition of
a "key number" is (ie what qemu_input_event_send_key_number()'s
"num" parameter is). We don't seem to document this anywhere,
which makes writing UI frontends tricky...
thanks
-- PMM
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] Definition of the UI layer's "key number" ?
2015-02-05 17:36 [Qemu-devel] Definition of the UI layer's "key number" ? Peter Maydell
@ 2015-02-09 8:27 ` Gerd Hoffmann
2015-02-09 8:31 ` Peter Maydell
0 siblings, 1 reply; 4+ messages in thread
From: Gerd Hoffmann @ 2015-02-09 8:27 UTC (permalink / raw)
To: Peter Maydell; +Cc: QEMU Developers
On Do, 2015-02-05 at 17:36 +0000, Peter Maydell wrote:
> Hi; I'm trying to find out what the UI layer's definition of
> a "key number" is (ie what qemu_input_event_send_key_number()'s
> "num" parameter is). We don't seem to document this anywhere,
> which makes writing UI frontends tricky...
Well, we have two ways to represent a key code in qemu, unfortunately in
the QMP api (see KeyValue in qapi-schema.json).
One is QKeyCode (defined in qapi-schema.json too), the other "key
number" is the key coding used pretty much everywhere in qemu before the
input layer rewrite (the new code in ui/input*.c) got merged. It is
based on ps/2 keycodes.
For new code I strongly suggest to simply ignore the old "key number"
coding and use QKeyCodes exclusively, it allows you to have nicely
readable mappings like the one in ui/sdl2-keymap.h. Then use
qemu_input_event_send_key_qcode() to feed the guest with the keyboard
input.
ui/input-keymap.c has a table to map QKeyCodes to "key numbers" and
helper functions to translate codes both ways.
cheers,
Gerd
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] Definition of the UI layer's "key number" ?
2015-02-09 8:27 ` Gerd Hoffmann
@ 2015-02-09 8:31 ` Peter Maydell
2015-02-09 9:16 ` Gerd Hoffmann
0 siblings, 1 reply; 4+ messages in thread
From: Peter Maydell @ 2015-02-09 8:31 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: QEMU Developers
On 9 February 2015 at 08:27, Gerd Hoffmann <kraxel@redhat.com> wrote:
> Well, we have two ways to represent a key code in qemu, unfortunately in
> the QMP api (see KeyValue in qapi-schema.json).
>
> One is QKeyCode (defined in qapi-schema.json too), the other "key
> number" is the key coding used pretty much everywhere in qemu before the
> input layer rewrite (the new code in ui/input*.c) got merged. It is
> based on ps/2 keycodes.
>
> For new code I strongly suggest to simply ignore the old "key number"
> coding and use QKeyCodes exclusively, it allows you to have nicely
> readable mappings like the one in ui/sdl2-keymap.h. Then use
> qemu_input_event_send_key_qcode() to feed the guest with the keyboard
> input.
>
> ui/input-keymap.c has a table to map QKeyCodes to "key numbers" and
> helper functions to translate codes both ways.
Thanks. How do we handle key codes which don't exist in the translation
tables in input-keymap.c? Specifically, we need to support the
"keypad =" key which exists on some Mac keyboards (both for sending
it if you're using this keyboard on the host and for receiving it
if you're using the ADB keyboard in the guest). There is a
Q_KEY_CODE_KP_EQUALS but it doesn't have a table entry, and since
both the guest code and the frontend UI code in question use old
style keycodes I'd rather the answer wasn't "convert both of them
to use QKeyCode"...
-- PMM
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] Definition of the UI layer's "key number" ?
2015-02-09 8:31 ` Peter Maydell
@ 2015-02-09 9:16 ` Gerd Hoffmann
0 siblings, 0 replies; 4+ messages in thread
From: Gerd Hoffmann @ 2015-02-09 9:16 UTC (permalink / raw)
To: Peter Maydell; +Cc: QEMU Developers
On Mo, 2015-02-09 at 08:31 +0000, Peter Maydell wrote:
> On 9 February 2015 at 08:27, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > Well, we have two ways to represent a key code in qemu, unfortunately in
> > the QMP api (see KeyValue in qapi-schema.json).
> >
> > One is QKeyCode (defined in qapi-schema.json too), the other "key
> > number" is the key coding used pretty much everywhere in qemu before the
> > input layer rewrite (the new code in ui/input*.c) got merged. It is
> > based on ps/2 keycodes.
> >
> > For new code I strongly suggest to simply ignore the old "key number"
> > coding and use QKeyCodes exclusively, it allows you to have nicely
> > readable mappings like the one in ui/sdl2-keymap.h. Then use
> > qemu_input_event_send_key_qcode() to feed the guest with the keyboard
> > input.
> >
> > ui/input-keymap.c has a table to map QKeyCodes to "key numbers" and
> > helper functions to translate codes both ways.
>
> Thanks. How do we handle key codes which don't exist in the translation
> tables in input-keymap.c? Specifically, we need to support the
> "keypad =" key which exists on some Mac keyboards (both for sending
> it if you're using this keyboard on the host and for receiving it
> if you're using the ADB keyboard in the guest). There is a
> Q_KEY_CODE_KP_EQUALS but it doesn't have a table entry, and since
> both the guest code and the frontend UI code in question use old
> style keycodes I'd rather the answer wasn't "convert both of them
> to use QKeyCode"...
Hmm, this certainly is the cleanest approach and it is exactly what I
did for sparc. They had some special key numbers in the 0xf0 .. 0xff
range for keys present on the sparc keyboard but not ps/2. sparc kbd
emulation (in hw/char/escc.c) got converted to use QKeyCodes so I could
drop those numbers. The keymap in the sparc kbd emulation also became
much nicer in the process.
qcode_to_number[] in ui/input-keymap.c basically defines what our "key
numbers" are, so we could extend this with non-ps/2 keys, simliar to how
it was done for the sparc keys in the past. It's hackish, but should
work as long as the number of additional keys is small.
cheers,
Gerd
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-02-09 9:16 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-02-05 17:36 [Qemu-devel] Definition of the UI layer's "key number" ? Peter Maydell
2015-02-09 8:27 ` Gerd Hoffmann
2015-02-09 8:31 ` Peter Maydell
2015-02-09 9:16 ` Gerd Hoffmann
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).