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

[Gerd Hoffmann]

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.

cheers,
  Gerd