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