http://bugs.winehq.org/show_bug.cgi?id=60059 me@papayadev.net changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression --- Comment #2 from me@papayadev.net --- Yes, I'm a real human with a real issue. Apologies for the overly dense text above — I had AI help me draft it from my testing notes and should have condensed it before posting. The attachment is just a small program that cleanly reproduces the problem; it originally showed up in real games I run. Final Fantasy XI is where I first noticed it. The short version: this is a regression from cbc657a244d1 ("winex11.drv: Force changing lock keys state if hooks blocked keyboard input processing.", 2018-10-23), and it's still present in current git. Whenever any app on the desktop has a global WH_KEYBOARD_LL hook (lots of games install one), the CapsLock and NumLock state starts flipping on every keystroke, for every process in the prefix. Typing comes out in random case, like "the QuicK brown fox jumps Over the lazy dog". To reproduce with the attached ditest3.c (no game needed): 1. Make sure physical NumLock is on, and start from a fresh wineserver. 2. WINEDEBUG=-all,+key,+keyboard wine ditest3.exe hook 3. Type a few letters into the window. You'll see "adjust_lock_state ... probably blocked by hooks" warnings on every keystroke (277 out of 277 in my log), and GetKeyState(VK_NUMLOCK)&1 flips with every key. Run it again without the "hook" argument and the same NumLock mismatch gets fixed up silently on the first keystroke and stays in sync — that's the expected behavior, and it shows the LL hook is the trigger. What's going on: adjust_lock_state() sends a synthetic lock-key down/up, then immediately re-reads the key state, and if nothing changed it assumes a hook blocked the event and force-writes the toggle bit. The problem is that when a low-level hook is installed, the server doesn't apply the key state until the hook thread has responded, and the driver's send doesn't wait for that. So the re-read always sees stale state, the force-write happens, and then the deferred synthetic KEYDOWN gets applied anyway and flips the toggle right back. That repeats on every key event. Before cbc657a244d1 the delayed event simply applied late and everything converged; the force-write is what turned this case into a permanent loop. I have a patch ready and will open an MR shortly. The approach is to not route the driver's own lock-sync events through low-level hooks at all — Windows never generates events like these, so no hook on Windows ever sees an equivalent — and that also makes the state change synchronous again, so the existing "did it change" check works as intended. Simply reverting cbc657a244d1 wouldn't be right either, since hooks that genuinely block lock keys (bug 42891) still need the force-write. -- 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.