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

[Programmingkid]

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 <address@hidden>
>>>> 
>>>> ---
>>>> 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.