Re: [Qemu-devel] [PATCH] ps2: Fix lost scancodes by recent changes

[OGAWA Hirofumi]

Hervé Poussineau <address@hidden> writes:

> [from hw/input/ps2.c]
>>> Can you also add the keycodes for scancode set 1:
>>> +    [Q_KEY_CODE_HIRAGANA] = 0x70,
>>> +    [Q_KEY_CODE_HENKAN] = 0x79,
>>> +    [Q_KEY_CODE_YEN] = 0x7d,
>>
>> Current linux can't use set1, so untested.
>
> Note that those are the same as those added in input-keymap.c

I see.

>> [... on qemu monitor "sendkey yen" ...]
>> 06:49:58.893893: EV_MSC MSC_SCAN 81
> -> 81 = 0x51
>> 06:49:58.893893: EV_KEY KEY_VOLUMEDOWN (0x72) pressed
>> 06:49:58.893893: EV_SYN code=0 value=0
>> 06:49:58.973841: EV_MSC MSC_SCAN 81
>> 06:49:58.973841: EV_KEY KEY_VOLUMEDOWN (0x72) released
>> 06:49:58.973841: EV_SYN code=0 value=0
>> timeout, quitting
>
> So, Linux is describing 0x51 make scancode as VOLUMEDOWN.
>
> Indeed, according to http://www.quadibloc.com/comp/scan.htm
>                  Set 1  Set 2  Set 3
> HENKAN           79     64     86    (kanji)
> HIRAGANA         70     13     87    (katakana)
> YEN              7d     6a     5d    (INT 4)
>
> So correct values for hw/input/ps2.c seem to be:

[...]

> Set 3:
> +    [Q_KEY_CODE_HIRAGANA] = 0x87, // already verified
> +    [Q_KEY_CODE_HENKAN] = 0x86, // already verified
> +    [Q_KEY_CODE_YEN] = 0x5d,  // not 0x51,  as I said in a previous email
>
> Can you check those values?

04:32:33.111316: EV_MSC MSC_SCAN 93
04:32:33.111316: EV_KEY KEY_BACKSLASH (0x2b) pressed
04:32:33.111316: EV_SYN code=0 value=0

Sent 93==0x5d as expected, but keycode is BACKSLASH. Of course, linux
driver is using BACKSLASH(43) keycode for 0x5d. But linux driver has
several BACKSLASH entries for multiple scancodes in set3.

And qemu doesn't have 0x5d entry in set3.  Also

        http://hp.vector.co.jp/authors/VA003720/lpproj/others/kbdjpn.htm

yet another site says 0x5d.

Some sites says about buggy keyboards using wrong scancode in set3, and
microsoft seems to removed set3 from specification. So linux translation
table for 43=>0x5d, maybe result of workarounds.

So looks like 0x5d is right value for set3.

Thanks.
-- 
OGAWA Hirofumi <address@hidden>