New subject: [Bug 59737] IME/VK_PROCESSKEY path loses scan code in follow-up WM_KEYDOWN under Chinese HKL

May 9, 2026

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

            Bug ID: 59737
           Summary: IME/VK_PROCESSKEY path loses scan code in follow-up
                    WM_KEYDOWN under Chinese HKL
           Product: Wine
           Version: 11.7
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: P2
         Component: user32
          Assignee: wine-bugs@list.winehq.org
          Reporter: ax+3lzp806u@fxzx.ident.com.es
      Distribution: ---

### Summary

When Wine runs under a Chinese locale / Chinese HKL (`00000804`), or after a
Chinese IME path is activated, normal key presses are delivered through a
`VK_PROCESSKEY` path.

The initial `VK_PROCESSKEY` message contains the correct scan code in `lParam`,
but the following real `WM_KEYDOWN` message for the actual key, such as `VK_W`
or `VK_BACK`, has scan code `0`.

This breaks games and engines that rely on scan codes for keyboard input or key
binding.

### Environment

* Affected HKL: Chinese layout, `00000804`
* Working HKL: US layout, `00000409`

The runtime XKB map appears normal:

```text
key <BKSP> { [ BackSpace, BackSpace ] };
key <AD02> {
    type= "ALPHABETIC",
    symbols[Group1]= [ w, W ]
};
```

So this does not appear to be caused by a broken XKB layout.

### Steps to reproduce

1. Run Wine under a Chinese locale, or use a session where Wine selects Chinese
HKL `00000804`.
2. Start an affected game or test program that logs Windows keyboard messages.
3. Press normal keys such as `W` or `Backspace`.
4. Observe the generated `WM_KEYDOWN` messages and their `lParam` scan-code
bits.

The problem may also appear after a Chinese IME / input method is activated
during the same Wine session.

### Actual behavior

Wine reports Chinese keyboard layout:

```text
NtUserGetKeyboardLayoutName ret L"00000804"
layout 0x8040804
Default IME
Wine IME
WM_IME_NOTIFY
```

Pressing `W` produces:

```text
WM_KEYDOWN  wp=000000e5 lp=00110001   # VK_PROCESSKEY, scan code = 0x11
WM_KEYDOWN  wp=00000057 lp=00000011   # VK_W, scan code = 0
WM_CHAR     wp=00000077 lp=00000011
WM_KEYUP    wp=000000e5 lp=c0110001
WM_KEYUP    wp=00000057 lp=0000c011
```

Pressing `Backspace` produces:

```text
WM_KEYDOWN  wp=000000e5 lp=000e0001   # VK_PROCESSKEY, scan code = 0x0e
WM_KEYDOWN  wp=00000008 lp=0000000e   # VK_BACK, scan code = 0
WM_CHAR     wp=00000008 lp=0000000e
WM_KEYUP    wp=000000e5 lp=c00e0001
WM_KEYUP    wp=00000008 lp=0000c00e
```

The scan code is present on the `VK_PROCESSKEY` message, but is lost in the
follow-up real key message.

### Expected behavior

When Wine sends the final real key message after IME processing, the scan code
in `lParam` should be preserved.

Expected examples:

```text
WM_KEYDOWN  VK_W     lp=00110001
WM_KEYDOWN  VK_BACK  lp=000e0001
```

The real key message should not have scan code `0`.

### Working case

When Wine is launched with an English locale:

```sh
LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 wine <app>
```

Wine uses US layout:

```text
NtUserGetKeyboardLayoutName ret L"00000409"
```

No `VK_PROCESSKEY` message is generated, and scan codes are correct.

For `W`:

```text
WM_KEYDOWN dispatched  wp=00000057 lp=00110001
WM_KEYUP dispatched    wp=00000057 lp=c0110001
```

For `Backspace`:

```text
WM_KEYDOWN dispatched  wp=00000008 lp=000e0001
WM_CHAR dispatched     wp=00000008 lp=000e0001
WM_KEYUP dispatched    wp=00000008 lp=c00e0001
```

### Additional observation

The issue can reappear after a Chinese IME/input method is activated inside the
session.

Before IME activation, keyboard input may work normally. After the IME appears
or composition is activated, affected games may start receiving real key
messages with scan code `0`.

This suggests the issue is likely in Wine's IME / `VK_PROCESSKEY` handling
path, not only in initial locale selection.

### Impact

Games and engines that depend on scan codes for keyboard input or key binding
ignore affected keys.

Observed symptoms include:

* `W` is not recognized unless pressed as `Alt+W`.
* `Backspace` is ignored in some games.
* Plain letter keys may fail in some games.
* The problem disappears when Wine is launched with an English locale.

`Alt+W` works because it goes through the system-key path and receives a
correct scan code:

```text
WM_SYSKEYDOWN wp=00000012 lp=20380001   # Alt
WM_SYSKEYDOWN wp=00000057 lp=20110001   # W, scan code = 0x11
```

### Workaround

Launching Wine with an English locale avoids the problem:

```sh
LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 XMODIFIERS=@im=none
wine <app>
```

### Suspected cause

Wine appears to construct the follow-up real `WM_KEYDOWN` message incorrectly
after `VK_PROCESSKEY` handling.

The correct scan code is available in the `VK_PROCESSKEY` message, but is not
preserved in bits 16–23 of `lParam` for the real key message.

-- 
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 59737] New: IME/VK_PROCESSKEY path loses scan code in follow-up WM_KEYDOWN under Chinese HKL

WineHQ Bugzilla

WineHQ Bugzilla

WineHQ Bugzilla

WineHQ Bugzilla

tags

participants (1)