http://bugs.winehq.org/show_bug.cgi?id=59962 --- Comment #1 from Ola Nordmann <olanordmann@duck.com> --- I did further debugging with WINEDEBUG=+key,+dinput and found the root cause, plus a workaround that confirms it. Root cause: the game (Neverwinter Nights Diamond 1.69, 32-bit) reads world hotkeys via DirectInput buffered data (dinput.dll, DirectInputCreateA, keyboard with SetCooperativeLevel DISCL_NONEXCLUSIVE|DISCL_FOREGROUND, GetDeviceData polled every frame) and GUI input via window messages. Under Wine, a single physical keystroke becomes visible in the dinput buffer *before* the same keystroke's WM_KEYDOWN is pumped by the game's main thread, because builtin dinput fills its queue from Wine's dedicated input thread (low-level hook path). Sequence from the attached trace (one physical V press; X11 delivers exactly one KeyPress, xev verified, autorepeat disabled): X11DRV_send_keyboard_input vkey=0056 scan=002f flags=0000 input_thread_ll_hook_proc calling dinput_keyboard_hook <- dinput queue filled immediately dinput_keyboard_hook wparam 0x100 vkCode 0x56 [game polls GetDeviceData, sees V, opens quickchat GUI] dinput_device_Unacquire <- game switches to GUI input mode NtUserTranslateMessage Translating key VK_V (0056) <- same keystroke's message pumped now NtUserTranslateMessage -> PostMessageW WM_CHAR "v" [open GUI receives the message, treats it as a new V press, closes -> "flash"] dinput_device_Acquire Only world->GUI transitions double-fire; closing GUI elements is always clean because the keyboard is unacquired while the GUI is open (single input path), which is consistent with the analysis. Reproduced identically on wine 10.20, 11.5, 11.10, 11.11 and wine-cachyos (Proton-derived), X11 and Wayland sessions, KDE Plasma 6.7.1, virtual desktop on/off, keyboard autorepeat on/off. Not a regression — long-standing behavior. Game works correctly on real Windows 10/11 on the same machine. Workaround confirming the diagnosis: overriding with the native Windows XP SP3 dinput.dll (5.03.2600.5512; imports only msvcrt/kernel32/advapi32/user32/winmm, all provided by Wine) via HKCU\Software\Wine\AppDefaults\nwmain.exe\DllOverrides dinput=native fixes the issue completely — with the XP DLL doing its own buffering, the game evidently never observes a dinput event for a keystroke whose window message it has not yet processed. (Native Windows 10/11 dinput.dll cannot be used for comparison: it fails with 0xc06d007e delay-loading ext-ms-win-mininput-inputhost-l1-1-0.dll.) So the defect appears to be event-ordering between builtin dinput's buffered keyboard queue and the thread message queue: buffered dinput data for a keystroke should not be observable by the application before the corresponding keyboard message can be retrieved by the window thread. -- 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.