[Bug 60476] New: Japanese 106/109 keyboard is not recognized: the Japanese-only keys get made-up scan codes, so GetKeyboardType(1) returns 0 and DirectInput reports a PC enhanced keyboard

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=60476

            Bug ID: 60476
           Summary: Japanese 106/109 keyboard is not recognized: the
                    Japanese-only keys get made-up scan codes, so
                    GetKeyboardType(1) returns 0 and DirectInput reports a
                    PC enhanced keyboard
           Product: Wine
           Version: 11.19
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: winex11.drv
          Assignee: [e-mail]
          Reporter: [e-mail]
  Target Milestone: ---
      Distribution: ---

Created attachment 82306
  --> http://bugs.winehq.org/attachment.cgi?id=82306
dinputtest.c, kbd_drive.py, container scripts, logs (Windows 11, Wine   11.19,
Wine 11.19 + patch)

DESCRIPTION

With a Japanese keyboard (XKB layout jp, evdev keycodes), the keys that only
exist on Japanese
keyboards get no proper scan code in winex11: Ro (the key left of right Shift),
Yen, Henkan,
Muhenkan and Katakana/Hiragana. keyc2scan() has no entry for KEY_RO, KEY_YEN,
KEY_HENKAN,
KEY_MUHENKAN and KEY_KATAKANAHIRAGANA, so they fall through to the made-up
extended scan code
0x200 | key (there is even a FIXME: map a KEY to T73 / VK_ABNT_C1).

Consequences:

- MapVirtualKey(VK_OEM_102, MAPVK_VK_TO_VSC) returns 0x59 instead of 0x73, so
GetKeyboardType(1)
  returns 0 instead of 2 (its check for a Japanese 106 keyboard fails),
although
  GetKeyboardType(0) returns 7.
- DirectInput then creates the keyboard as DIDEVTYPEKEYBOARD_PCENH instead of
  DIDEVTYPEKEYBOARD_JAPAN106, so the Japanese key mapping in dinput is never
used:
  @ and : are reported as 0x1a and 0x28 (US [ and ') instead of DIK_AT and
DIK_COLON.
- Ro, Yen and Henkan arrive with wrong DIK codes (0x59, 0x7c, 0x5c), Muhenkan
and Katakana/Hiragana
  do not arrive in DirectInput at all.

Applications that decide by the keyboard type how to show or bind keys show the
wrong characters.
A game I use with Wine shows [ for the @ key, ] for [ and ' for : in its key
binding
screen (correct on Windows with the same keyboard).

STEPS TO REPRODUCE

1. XKB layout jp (e.g. setxkbmap jp, or Plasma with a Japanese keyboard
layout).
2. LC_ALL=ja_JP.UTF-8 wine dinputtest32.exe -o test.log (attached test program,
DirectInput 8
   keyboard, buffered data, logs GetKeyboardType, MapVirtualKey and every DIK
code).
3. Press @ [ ; : ] ^, Ro, Yen, Henkan, Muhenkan, Katakana/Hiragana, Esc to
quit.

The attached logs were made in Xvfb with keys sent through XTEST
(kbd_drive.py), no input method.
The Windows logs were made with the same scan codes injected through
SendInput(KEYEVENTF_SCANCODE)
(see logs/win/NOTE.txt in the archive).

  - Windows 11 (Japanese 106/109)  |  Wine 11.19  |  Wine 11.19 + patch
  - GetKeyboardType(0) / (1): 7 / 2  |  7 / 0  |  7 / 2
  - MapVirtualKey(VK_OEM_102 -> VSC): 0x73  |  0x59  |  0x73
  - DirectInput device subtype: 10 (JAPAN106)  |  4 (PCENH)  |  10 (JAPAN106)
  - @ key: DIK_AT 0x91  |  DIK 0x1a  |  DIK_AT 0x91 (*)
  - : key: DIK_COLON 0x92  |  DIK 0x28  |  DIK_COLON 0x92 (*)
  - Ro key: DIK 0x2b (BACKSLASH)  |  DIK 0x59  |  DIK 0x2b (BACKSLASH)
  - Yen key: DIK_YEN 0x7d  |  DIK 0x7c  |  DIK_YEN 0x7d
  - Henkan / Muhenkan / Katakana: DIK_CONVERT 0x79 / DIK_NOCONVERT 0x7b /
DIK_KANA 0x70  |  0x5c / none / none  |  DIK_CONVERT 0x79 / DIK_NOCONVERT 0x7b
/ DIK_KANA 0x70

(*) With the patch, dinput sets DIK_AT / DIK_COLON / DIK_CIRCUMFLEX in the
device state
(GetDeviceState; the game shows these keys correctly), but GetDeviceData does
not return these
key downs (Windows does return them, see the Windows logs). This is a separate,
already existing dinput issue that only shows up once the keyboard is JAPAN106:
keyboard_enum_objects() and keyboard_create_device() loop over the scan codes
0-0x1ff, and the
extended scan codes 0x110-0x114 also map to DIK 0x90-0x94 (GetKeyNameText
returns "Q", "W", ... for
them), so DIK_CIRCUMFLEX, DIK_AT, DIK_COLON and DIK_KANJI are enumerated twice
(see the OBJ lines in
the logs). I can file it separately if that helps.

PROPOSED PATCH

Map the five keys to their set 1 scan codes in keyc2scan(), as the Japanese
keyboard layout of
Windows (and the Linux atkbd driver) does: KEY_KATAKANAHIRAGANA 0x70, KEY_RO
0x73, KEY_HENKAN 0x79,
KEY_MUHENKAN 0x7b, KEY_YEN 0x7d. With the patch GetKeyboardType(1) returns 2,
dinput reports
DIDEVTYPEKEYBOARD_JAPAN106 and uses its existing Japanese DIK mapping, and the
game shows the keys
like on Windows. The patch only adds cases to the switch; the other layouts are
not affected because
these evdev keys do not exist on them.

ENVIRONMENT

- Ubuntu 26.04.1 LTS (Kubuntu, KDE Plasma 6.6, Wayland session; Wine runs on
XWayland), x86_64.
  Found there with a Japanese 106/109 keyboard; the logged runs use Xvfb +
openbox with the XKB
  layout jp (evdev keycodes), keys sent through XTEST, no input method
(XMODIFIERS=@im=none).
- Wine 11.19 built from the WineHQ source (configure
--enable-archs=i386,x86_64, i.e. the new WoW64
  mode), fresh prefix, LC_ALL=ja_JP.UTF-8, no DLL overrides when running the
test (Mono/Gecko
  installation skipped while the prefix was created). Same results with Wine
11.19 + Staging.
  dlls/winex11.drv/keyboard.c is unchanged in current master (a15ee2cc,
2026-10-09).
- Comparison: Windows 11 26H2, Japanese 106/109 keyboard (HKL 04110411), keys
injected with
  SendInput(KEYEVENTF_SCANCODE).

TEST PROGRAM

dinputtest.c (attached, standalone) creates a window, a DirectInput 8 keyboard
device
(DISCL_FOREGROUND | DISCL_NONEXCLUSIVE, buffered data) and logs
GetKeyboardType,
MapVirtualKey for the Japanese keys, the device subtype, every WM_KEYDOWN /
WM_CHAR (with the
NumLock toggle state) and every DIK key down with its DIPROP_KEYNAME /
DIPROP_SCANCODE. -hook
installs a pass-through WH_KEYBOARD_LL hook, -o <file> sets the log file. Esc
quits and writes a
SUMMARY line. (The KEY vk=0xe5 lines in the Wine logs are bug 60449: Wine's
builtin IME wraps
every key in VK_PROCESSKEY, even without an input method. They are not related
to this report.)

Build: i686-w64-mingw32-gcc -O1 -o dinputtest32.exe dinputtest.c -ldinput8
-ldxguid -mwindows
(64-bit: x86_64-w64-mingw32-gcc).

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 60476] Japanese 106/109 keyboard is not recognized: the Japanese-only keys get made-up scan codes, so GetKeyboardType(1) returns 0 and DirectInput reports a PC enhanced keyboard

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=60476

--- Comment #1 from Kagetaro078 <[e-mail]> ---
Created attachment 82307
  --> http://bugs.winehq.org/attachment.cgi?id=82307
Proposed patch: map the Japanese keys to their scan codes in keyc2scan()

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.