[Bug 35907] Caps Lock state gets confused with multiple processes/threads

[wine-bugs at winehq.org]

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

--- Comment #3 from Ken Thomases <ken at 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).

-- 
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.