https://bugs.winehq.org/show_bug.cgi?id=33479
--- Comment #45 from Sebastian Lackner sebastian@fds-team.de --- I think I found whats going wrong here. So far I didn't have any proper way to reproduce this issue, but thanks to Béla ( https://bugs.wine-staging.com/show_bug.cgi?id=16#c2 ) for pointing out a demo which triggers the issue reliably.
Without the offending commit X11DRV_ClipCursor was basically a no-op for the desktop window thread. The commit changed the behaviour so that X11DRV_ClipCursor is also called when WM_WINE_CLIPCURSOR messages arrive for the desktop thread. What happens here is:
--- snip --- 0009:fixme:cursor:ClipCursor Clipping to (0,0)-(1920,1080) 0009:fixme:cursor:X11DRV_ClipCursor Clipping to (0,0)-(1920,1080) 0015:fixme:msg:handle_internal_message got WM_WINE_CLIPCURSOR 0015:fixme:cursor:X11DRV_ClipCursor Clipping to (0,0)-(1920,1080) 0015:fixme:cursor:X11DRV_ClipCursor data->clip_hwnd == NULL 0015:fixme:cursor:ungrab_clipping_window no longer clipping --- snip ---
As you can easily see when taking a look at http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winex11.drv/mouse.c#l1... the code was never written be executed from a different thread/process, but that is what the commit enabled.
The desktop thread will unset clipping again, which is what causes the broken mouse input. As multiple threads are involved there is _very_ small chance that it will still work, which is probably also why it is more or less difficult to reproduce with various apps and why some people don't have any issues.
I've wrtten a patch to fix this regression, without reverting Henri's original idea: https://github.com/wine-compholio/wine-staging/blob/master/patches/server-Cl...
Béla already tested it successfully with various games (thanks!), but in order to submit it, it would be nice if someone experienced with this particular area could take a look, and confirm that this is the proper way to solve it.