http://bugs.winehq.org/show_bug.cgi?id=35907
--- Comment #3 from Ken Thomases ken@codeweavers.com --- (In reply to Dmitry Timoshkov from comment #2)
(In reply to Ken Thomases from comment #1)
The thread-specific state is only updated when that thread gets a WM_KEYDOWN for VK_CAPITAL.
If that would be true then turning Caps Lock on before running notepad would lead to wrong results as well, but that's not the case.
No, because then the thread owning the Notepad window does receive the VK_CAPITAL key-down. The wineserver's notion of the async key state starts out cleared. When X11 delivers a KeyPress, the X11 driver examines the async key state and compares it to the event state to decide whether it should synthesize a VK_CAPITAL key down. The event state has LockMask but the Wine key state does not indicate that VK_CAPITAL is toggled on, so the X11 driver synthesizes a key-down, key-up pair. The thread receives the WM_KEYDOWN.
The WM_KEYDOWN is not associated with the window/thread that was current when the actual Caps Lock key was pressed or occur at the time it was pressed. It occurs at the time that the X11 driver notices the mismatch between the X11 state and the Win32 async key state, and is delivered to the target window's thread (and only that thread).