Re: [Qemu-devel] [PATCH] input-keymap.c: Add keypad equal and power keys

[Gerd Hoffmann <kraxel@redhat.com>]

On Mi, 2016-03-02 at 11:29 -0500, Programmingkid wrote:
> On Mar 2, 2016, at 11:12 AM, Gerd Hoffmann wrote:
> 
> > On Mi, 2016-03-02 at 10:52 -0500, Programmingkid wrote:
> >> Add the keypad equals and power keys to the qcode_to_number array. These keys
> >> are used on a Macintosh keyboard.
> >> 
> >> Signed-off-by: John Arbuckle <programmingkidx@gmail.com>
> >> 
> >> ---
> >> ui/input-keymap.c |    3 ++-
> >> 1 files changed, 2 insertions(+), 1 deletions(-)
> >> 
> >> diff --git a/ui/input-keymap.c b/ui/input-keymap.c
> >> index fd2c09d..8cffe62 100644
> >> --- a/ui/input-keymap.c
> >> +++ b/ui/input-keymap.c
> >> @@ -98,6 +98,7 @@ static const int qcode_to_number[] = {
> >>     [Q_KEY_CODE_KP_ENTER] = 0x9c,
> >>     [Q_KEY_CODE_KP_DECIMAL] = 0x53,
> >>     [Q_KEY_CODE_SYSRQ] = 0x54,
> >> +    [Q_KEY_CODE_KP_EQUALS] = 0x55,
> > 
> > Where does the 0x55 come from?
> 
> It is a value I picked by adding one to Q_KEY_CODE_SYSRQ's value.

Naa, that is not going to fly.

number is modeled after pc scancodes, so you can't just pick random
numbers.

> >> +    [Q_KEY_CODE_POWER] = 0x5e,
> > 
> > Same question here.
> 
> I went to this page: http://www.computer-engineering.org/ps2keyboard/scancodes1.html.
> Then I looked at the power button's value of 0xe05e, and just removed the e0 part.

That is wrong too, you can't just drop the 0xe0.

Traditionally qemu used pc scancodes exclusively to pass around key
presses internally.  That had a number of problems:  First, alot of
places in qemu had code to deal with the extended scancode (0xe0 prefix)
logic.  Second, if you need keys which don't have a pc scancode you have
a problem.

So, a while back I've switched the qemu input system over to use
qkeycodes instead.  pc scancodes can still be handled and there are
helper functions to translate qkeycodes to scancodes and back.  That is
needed (a) for backward compatibility with code which isn't converted
yet to the new input api and (b) for devices such as the ps/2 keyboard
which actually need scancodes.

So, if there are no scancodes for the keys you want handle, you can now
drop the scancodes from the workflow.  Switch cocoa to generate and
submit qkeycodes.  Switch the apple keyboard(s) to accept qkeycodes (see
yesterdays mail on adb keyboard).  Then the key events from the host
keyboard are forwarded to the guest without ever being converted into pc
scancodes.

cheers,
  Gerd