http://bugs.winehq.org/show_bug.cgi?id=31702
--- Comment #27 from Henri Verbeet hverbeet@gmail.com 2012-09-24 04:12:22 CDT --- (In reply to comment #26)
As far as I can tell, "ClipCursor( NULL );" is only called when quitting the game.
Concerning WM_X11DRV_CLIP_CURSOR being sent from mouse.c with SendMessageW or SendNotifyMessageW, I made the following observations:
When moving the mouse WITHOUT pressing a button, ungrab_clipping_window() is triggered on every mouse move event, causing WM_X11DRV_CLIP_CURSOR to get spammed via SendMessageW.
Right when pressing a mouse button (and not yet moving the mouse), grab_clipping_window(RECT) is called, sending WM_X11DRV_CLIP_CURSOR with SendMessageW.
When moving the mouse with a button held down, WM_X11DRV_CLIP_CURSOR is never sent.
When releasing a mouse button, ungrab_clipping_window() sends WM_X11DRV_CLIP_CURSOR with SendMessageW. Subsequently, as expected from the comments, clip_cursor_notify(HWND, HWND) is called sending WM_X11DRV_CLIP_CURSOR with SendNotifyMessageW.
I don't know how to interpret this behavior.
I think we're mostly interested in what behaviour in the application causes all the resets. ungrab_clipping_window() is only called from a couple of places: X11DRV_ClipCursor(), and X11DRV_WindowPosChanged() and X11DRV_FocusOut() through reset_clipping_window(). The latter two seem unlikely, though it would be good to verify. The first one suggests the application calling ClipCursor(). If the application is indeed calling ClipCursor() on mouse moves, we'd like to know what rectangle it's using, and if that rectangle changes.