Re: [Qemu-devel] [PATCH v2] Fixes key mapping so all keys work

[Peter Maydell]

On 12 May 2015 at 05:11, Programmingkid <address@hidden> wrote:
>
> On May 10, 2015, at 2:45 PM, Peter Maydell wrote:
>> This is two conceptually separate fixes:
>> (1) better handle key input to the ADB keyboard
>> (2) output the right keycodes on the OSX cocoa UI
>> which should be in separate patches.
>>
>> We should also be doing the support for keypad-= by converting both
>> the cocoa UI and the ADB keyboard device to the QKeyCode APIs,
>> which can cleanly handle these key without inventing fake PC
>> keycode numbers, as suggested by Gerd:
>> https://lists.gnu.org/archive/html/qemu-devel/2015-02/msg01322.html
>
> So what you want is to eliminate the ps/xt key mappings found in
> the cocoa.m and use the QKeyCode API?
>
> I really didn't like how in the cocoa.m file, a key press is first
> translated to a ps/xt key value, then translated to a Macintosh ADB
> keycode.
>
> Basically this:
> Macintosh host key code => PS/XT  key code => ADB key code
>
> I do admit I'm not fully sure how the new API is suppose to work.

> For a Macintosh host and guest it probably should work like this:
> Macintosh host key code => sent directly to guest OS
>
> For a Macintosh host and a PC guest, it probably should work like this:
> Macintosh host key code => PS/2 key code (not PS/XT)
>
> For a PC host and a PC guest, it probably should work like this:
> PC host key code => sent directly to guest OS
>
> For a PC host and a Macintosh guest, it might work like this:
> PC host key code (PS/2) => ADB key code

No. In the new scheme it would go:
  Mac host keycode => QKeyCode => [whatever keycode guest h/w uses]

It's similar to the PS/XT scheme, except that the QKeyCodes
genuinely cover all possible keys, not just the ones that
happen to be present for the PC. (Instead of converting to a
scancode in ui/cocoa.m, we would convert to a QKeyCode, then call
qemu_input_event_send_key_qcode rather than ...send_key_number.)

Doing direct conversion between host and guest is a bad idea,
because then every UI frontend needs to know about every
possible scancode scheme used by every keyboard device, and
to know which device is currently being used. (And adding a
new keyboard device would be massively painful.)
Going via QKeyCode means that UI frontends only need to know
about the keycode the host GUI uses and QEMU's common scheme;
similarly keyboard device models only need to know about
QEMU's common scheme and the codes they need to send to the guest.
(The bug you're trying to fix here is actually a result of
the remains of a 'direct conversion' API from when the only
guests we cared about were PC/x86 -- that's why the input
API is using a PC scancode, and that's why it doesn't work
with keys that aren't on a PC. Going via a universal
intermediate encoding fixes this problem.)

> Host key code => QKeyCode => guest key code
> I would like to avoid this translation because it would be relatively slow.
> It would be as inefficient as what we have now.

At the rate at which keys are pressed (which is governed by
how fast a human can type, which is massively slow compared
to how fast computers can process) the speed of doing a pair
of array lookups to do keycode conversion is absolutely lost
in the noise. Maintainability and flexibility of the code
is a more important consideration in my opinion.

thanks
-- PMM