[Top][All Lists]

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

Re: [Qemu-devel] Definition of the UI layer's "key number" ?

From: Gerd Hoffmann
Subject: Re: [Qemu-devel] Definition of the UI layer's "key number" ?
Date: Mon, 09 Feb 2015 10:16:04 +0100

On Mo, 2015-02-09 at 08:31 +0000, Peter Maydell wrote:
> On 9 February 2015 at 08:27, Gerd Hoffmann <address@hidden> 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.


reply via email to

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