https://bugs.winehq.org/show_bug.cgi?id=35907
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #6 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Ken Thomases from comment #5)
So, this may require that, when the hardware message is queued for the destination thread, the wineserver also queue a fake version of the message into every other thread's queue, too. The fake message would never be returned from Get/PeekMessage(), but when it reaches the front of the queue, it would alter the keystate just like the real message does for the destination thread.
My analysis of bug 27238 and 31899 shows that the key state is also updated even though there is no main message loop (and I have also tested and confirmed that manually with a small test code). I have more the impression that as soon as there are no further queued key/input events, then the key state gets "magically" synced again with the async key state.