server: Only send WM_WINE_CLIPCURSOR for forced clip resets. (resend)

[Ken Thomases]

On Nov 10, 2015, at 10:30 PM, Sebastian Lackner <sebastian at fds-team.de> wrote:
> 
> It would be nice if someone familiar with winemac.drv could confirm/test that
> removing the duplicate notification doesn't break anything.

It shouldn't break anything.  The Mac driver works very differently from the X11 driver in this area.  Cursor clipping isn't closely related to the delivery of relative mouse movement events.  There's nothing like grabbing the pointer or the use of an extra window, etc.

Also, the desktop owner doesn't ever present a window (no virtual desktop mode support, yet), so it's never the active Mac process.  So, calls or lack of calls to macdrv_ClipCursor() in that process make no difference.


All of that said, it seems the problem is specific to the X11 driver and the solution should probably be restricted to there, too.  No matter what thread or process receives WM_WINE_CLIPCURSOR, it gets the cursor clipping rectangle and (re)establishes that via the driver.  The driver should never do the wrong thing when it receives a request that's appropriate to the current state.

The fact that cursor clipping and relative mouse movements are closely intertwined is an artifact of X11.  If grab_clipping_window() is going to be used for both, then the X11 driver has to take care not to call ungrab_clipping_window() just because one of those two needs is not currently in effect.

-Ken