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

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

[Programmingkid]

Fixes keyboard mapping so right shift, right command, right option, right control, keypad period, keypad '=', keypad enter, and F13 all work.
 
Signed-off-by: John Arbuckle <programmingkidx@gmail.com>

---
Undid most changes to keyboard map in cocoa.m.
Most changes made to keyboard map in adb.c. 
Since there is no keypad '=' key for the PC/AT or PC/XT layouts, I had to invent my own number for it. It works for the Mac OS X guest. Guest like Windows XP are not effected because they don't use the Macintosh keyboard layout.

Signed-off-by: John Arbuckle <programmingkidx@gmail.com>

---
 hw/input/adb.c |    8 ++++----
 ui/cocoa.m     |    4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/input/adb.c b/hw/input/adb.c
index 34c8058..aa7287f 100644
--- a/hw/input/adb.c
+++ b/hw/input/adb.c
@@ -182,12 +182,12 @@ static const uint8_t pc_to_adb_keycode[256] = {
  84, 85, 82, 65,  0,  0, 10,103,111,  0,  0,110, 81,  0,  0,  0,
   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
-  0,  0,  0, 94,  0, 93,  0,  0,  0,  0,  0,  0,104,102,  0,  0,
-  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 76,125,  0,  0,
+  0,  81, 0, 94,  0, 93,  0,  0,  0,  0,  0,  0,104,102,  0,  0,
+  0,  0,  0,  0,  0,  0,  0,  0, 76,  0,  0,  0, 76, 54,  0,  0,
   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,105,  0,  0,  0,  0,  0,
-  0,  0,  0,  0,  0, 75,  0,  0,124,  0,  0,  0,  0,  0,  0,  0,
+  0,  0,  0,  0,  0, 75,  0,105, 58,  0,  0,  0,  0,  0,  0,  0,
   0,  0,  0,  0,  0,  0,  0,115, 62,116,  0, 59,  0, 60,  0,119,
- 61,121,114,117,  0,  0,  0,  0,  0,  0,  0, 55,126,  0,127,  0,
+ 61,121,114,117,  0,  0,  0,  0,  0,  0,  0, 55, 55,  0,127,  0,
   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
   0,  0,  0,  0,  0, 95,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
 };
diff --git a/ui/cocoa.m b/ui/cocoa.m
index c8535a3..456f942 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -139,7 +139,7 @@ int keymap[] =
     157,//  62      0x3E    0x9d    E0,1D   R CTRL  QZ_RCTRL
     0,  //  63      0x3F    Undefined
     0,  //  64      0x40    Undefined
-    0,  //  65      0x41    Undefined
+    83, //  65      0x41    0x53            KP .    QZ_KP_PERIOD
     0,  //  66      0x42    Undefined
     55, //  67      0x43    0x37            KP *    QZ_KP_MULTIPLY
     0,  //  68      0x44    Undefined
@@ -155,7 +155,7 @@ int keymap[] =
     74, //  78      0x4E    0x4a            KP -    QZ_KP_MINUS
     0,  //  79      0x4F    Undefined
     0,  //  80      0x50    Undefined
-    0,  //  81      0x51                            QZ_KP_EQUALS
+    129,//  81      0x51    0x51            KP =    QZ_KP_EQUALS
     82, //  82      0x52    0x52            KP 0    QZ_KP0
     79, //  83      0x53    0x4f            KP 1    QZ_KP1
     80, //  84      0x54    0x50            KP 2    QZ_KP2
-- 
1.7.5.4

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

[Peter Maydell]

On 15 January 2015 at 21:13, Programmingkid <programmingkidx@gmail.com> wrote:
> Fixes keyboard mapping so right shift, right command, right option, right control, keypad period, keypad '=', keypad enter, and F13 all work.
>
> Signed-off-by: John Arbuckle <programmingkidx@gmail.com>
>
> ---
> Undid most changes to keyboard map in cocoa.m.
> Most changes made to keyboard map in adb.c.
> Since there is no keypad '=' key for the PC/AT or PC/XT layouts, I had to invent my own number for it. It works for the Mac OS X guest. Guest like Windows XP are not effected because they don't use the Macintosh keyboard layout.
>
> Signed-off-by: John Arbuckle <programmingkidx@gmail.com>
>
> ---
>  hw/input/adb.c |    8 ++++----
>  ui/cocoa.m     |    4 ++--

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

My apologies for this review being so delayed; I'm now
trying to process my queue of OSX to-review patches.

-- PMM

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

[Programmingkid]

On May 10, 2015, at 2:45 PM, Peter Maydell wrote:

> On 15 January 2015 at 21:13, Programmingkid <programmingkidx@gmail.com> wrote:
>> Fixes keyboard mapping so right shift, right command, right option, right control, keypad period, keypad '=', keypad enter, and F13 all work.
>> 
>> Signed-off-by: John Arbuckle <programmingkidx@gmail.com>
>> 
>> ---
>> Undid most changes to keyboard map in cocoa.m.
>> Most changes made to keyboard map in adb.c.
>> Since there is no keypad '=' key for the PC/AT or PC/XT layouts, I had to invent my own number for it. It works for the Mac OS X guest. Guest like Windows XP are not effected because they don't use the Macintosh keyboard layout.
>> 
>> Signed-off-by: John Arbuckle <programmingkidx@gmail.com>
>> 
>> ---
>> hw/input/adb.c |    8 ++++----
>> ui/cocoa.m     |    4 ++--
> 
> 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

The above shouldn't be hard to do. Code would need to be added
to the cocoa.m file to detect the currently used emulator. 

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. 

> My apologies for this review being so delayed; I'm now
> trying to process my queue of OSX to-review patches.

Five months is a long time, but it is way better than never.

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

[Peter Maydell]

On 12 May 2015 at 05:11, Programmingkid <programmingkidx@gmail.com> 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