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

[Programmingkid]

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.