[Bug 31702] Mouselook (raw input) is bound to a box every other click in Guild Wars 2

[wine-bugs at winehq.org]

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

--- Comment #27 from Henri Verbeet <hverbeet at 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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.