| Message ID | 09EE2B64-B7B1-469B-AEE9-8250223DA109@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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? > + [Q_KEY_CODE_POWER] = 0x5e, Same question here. cheers, Gerd
On 03/02/2016 08:52 AM, 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(-) This patch applies, but doesn't build, in isolation: CC ui/input-keymap.o ui/input-keymap.c:101:6: error: ‘Q_KEY_CODE_KP_EQUALS’ undeclared here (not in a function) [Q_KEY_CODE_KP_EQUALS] = 0x55, ^ If it is part of a series, then please make sure to submit the series as a single thread, with a 0/n cover letter, and with pre-requisite patches first. 'git send-email' can do this for you; read http://wiki.qemu.org/Contribute/SubmitAPatch for more patch submission hints.
On Mar 2, 2016, at 11:15 AM, Eric Blake wrote: > On 03/02/2016 08:52 AM, 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(-) > > This patch applies, but doesn't build, in isolation: > > CC ui/input-keymap.o > ui/input-keymap.c:101:6: error: ‘Q_KEY_CODE_KP_EQUALS’ undeclared here > (not in a function) > [Q_KEY_CODE_KP_EQUALS] = 0x55, > ^ > > If it is part of a series, then please make sure to submit the series as > a single thread, with a 0/n cover letter, and with pre-requisite patches > first. 'git send-email' can do this for you; read > > http://wiki.qemu.org/Contribute/SubmitAPatch > > for more patch submission hints. Thank you for catching this. The qapi-schema.json patch is required in order to use this patch. Sorry if this caused you problems. I will learn how to use the git send-email command soon.
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. > >> + [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.
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
On Mar 3, 2016, at 5:01 AM, Gerd Hoffmann wrote: > 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. Really? I thought the only requirement was each scancode had to be unique. > >>>> + [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. They value of these keys doesn't really matter to me. They both just need to be identifiable. > 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. It sounds like you want the power key's value to be the actual ps/2 value of 0xe05e. > 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. Are you saying not to add the power and keypad equal keys to the input-keymap.c file? > Switch cocoa to generate and > submit qkeycodes. This is already done. > Switch the apple keyboard(s) to accept qkeycodes (see > yesterdays mail on adb keyboard). On my to-do list. > Then the key events from the host > keyboard are forwarded to the guest without ever being converted into pc > scancodes. How do I do this? You said to use qemu_input_event_send_key_qcode() to send QKeyCodes to QEMU. Is this what you still want? Eventually wouldn't the qcode_to_number array in input-keymap.c try to translate the keypad equals to a ps/2 value? If the keypad equals key isn't set in this array, the array might return a default value of 0 and the user will see 'a' printed whenever the keypad equals key is pushed.
Hi, > > number is modeled after pc scancodes, so you can't just pick random > > numbers. > > Really? I thought the only requirement was each scancode had to be unique. No, it's not. ps2 emulation assumes those codes are the real ones. > > So, if there are no scancodes for the keys you want handle, you can now > > drop the scancodes from the workflow. > > Are you saying not to add the power and keypad equal keys to the input-keymap.c file? If standard scancodes exist for them we can add them. Needs some care though, ps2 keyboards have different modes and different keymaps in each mode. > > Switch cocoa to generate and > > submit qkeycodes. > > This is already done. Good. > > Switch the apple keyboard(s) to accept qkeycodes (see > > yesterdays mail on adb keyboard). > > On my to-do list. Good. > > Then the key events from the host > > keyboard are forwarded to the guest without ever being converted into pc > > scancodes. > > How do I do this? You said to use qemu_input_event_send_key_qcode() to > send QKeyCodes to QEMU. Is this what you still want? Yes. > Eventually wouldn't the qcode_to_number array in input-keymap.c try to > translate the keypad equals to a ps/2 value? Depends on what the emulated device is doing. Devices which still use the old input interface to register a input handler will get scancodes (example: current adb code). Devices which are switched over to the new input interface will receive InputEvent *evt. Then they can then use either qemu_input_key_value_to_scancode() to translate the event into a sequence of scancodes (Example: ps2 keyboard). Or they can use qemu_input_key_value_to_qcode() to get a qkeycode. So, with cocoa using qemu_input_event_send_key_qcode() and adb using qemu_input_key_value_to_qcode() the keys are never translated into scancodes, and they'll work fine even without a scancode being assigned to them in the qcode <-> number (aka scancode) translation maps. > If the keypad equals key isn't set in this array, the array might > return a default value of 0 and the user will see 'a' printed whenever > the keypad equals key is pushed. Once the adb code is switched over to use qemu_input_key_value_to_qcode this will stop happening. Of course, when emulating a x86 guest with ps/2 keyboard you still run into the problem that there might be no ps/2 scancode for certain keys. But there is nothing we can do about that. Inventing random scancodes wouldn't make guests interpret them as expected ... cheers, Gerd
On Mar 3, 2016, at 10:49 AM, Gerd Hoffmann wrote: > Hi, > >>> number is modeled after pc scancodes, so you can't just pick random >>> numbers. >> >> Really? I thought the only requirement was each scancode had to be unique. > > No, it's not. ps2 emulation assumes those codes are the real ones. > >>> So, if there are no scancodes for the keys you want handle, you can now >>> drop the scancodes from the workflow. >> >> Are you saying not to add the power and keypad equal keys to the input-keymap.c file? > > If standard scancodes exist for them we can add them. Needs some care > though, ps2 keyboards have different modes and different keymaps in each > mode. > >>> Switch cocoa to generate and >>> submit qkeycodes. >> >> This is already done. > > Good. > >>> Switch the apple keyboard(s) to accept qkeycodes (see >>> yesterdays mail on adb keyboard). >> >> On my to-do list. > > Good. > >>> Then the key events from the host >>> keyboard are forwarded to the guest without ever being converted into pc >>> scancodes. >> >> How do I do this? You said to use qemu_input_event_send_key_qcode() to >> send QKeyCodes to QEMU. Is this what you still want? > > Yes. > >> Eventually wouldn't the qcode_to_number array in input-keymap.c try to >> translate the keypad equals to a ps/2 value? > > Depends on what the emulated device is doing. > > Devices which still use the old input interface to register a input > handler will get scancodes (example: current adb code). > > Devices which are switched over to the new input interface will receive > InputEvent *evt. Then they can then use either > qemu_input_key_value_to_scancode() to translate the event into a > sequence of scancodes (Example: ps2 keyboard). Or they can use > qemu_input_key_value_to_qcode() to get a qkeycode. > > So, with cocoa using qemu_input_event_send_key_qcode() and adb using > qemu_input_key_value_to_qcode() the keys are never translated into > scancodes, and they'll work fine even without a scancode being assigned > to them in the qcode <-> number (aka scancode) translation maps. > >> If the keypad equals key isn't set in this array, the array might >> return a default value of 0 and the user will see 'a' printed whenever >> the keypad equals key is pushed. > > Once the adb code is switched over to use qemu_input_key_value_to_qcode > this will stop happening. > > Of course, when emulating a x86 guest with ps/2 keyboard you still run > into the problem that there might be no ps/2 scancode for certain keys. > But there is nothing we can do about that. Inventing random scancodes > wouldn't make guests interpret them as expected ... Well, the evidence would say otherwise. For the Macintosh keyboard's keypad equals key, we could make it so the other equals key is used in its place. The only time the user would have any issues is when he or she holds down the shift key and pushes the keypad equals button. But who would do that? Logically equal equals equal. I always thought the whole point to QKeyCode was to provide a platform neutral keycode implementation. Your description of it makes it sound like it is really just PS/2 keycodes under a different name.
On 3 March 2016 at 17:55, Programmingkid <programmingkidx@gmail.com> wrote: > > On Mar 3, 2016, at 10:49 AM, Gerd Hoffmann wrote: >> Of course, when emulating a x86 guest with ps/2 keyboard you still run >> into the problem that there might be no ps/2 scancode for certain keys. >> But there is nothing we can do about that. Inventing random scancodes >> wouldn't make guests interpret them as expected ... > I always thought the whole point to QKeyCode was to provide a > platform neutral keycode implementation. Your description of it makes > it sound like it is really just PS/2 keycodes under a different name. No, it is a neutral keycode implementation. If the keyboard being emulated is a PS/2 keyboard then obviously you can't actually send the guest keycodes that don't exist in the PS/2 protocol. That's a limitation of the hardware being emulated, not of QEMU. thanks -- PMM
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, [Q_KEY_CODE_KP_0] = 0x52, [Q_KEY_CODE_KP_1] = 0x4f, @@ -132,7 +133,7 @@ static const int qcode_to_number[] = { [Q_KEY_CODE_RO] = 0x73, [Q_KEY_CODE_KP_COMMA] = 0x7e, - + [Q_KEY_CODE_POWER] = 0x5e, [Q_KEY_CODE__MAX] = 0, };
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(-)