Hervé Poussineau <hpous...@reactos.org> 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 <hirof...@mail.parknet.co.jp>
