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 <programmingk...@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