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

[Ken Thomases]

On Nov 10, 2015, at 10:30 PM, Sebastian Lackner <sebastian(a)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

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

[Sebastian Lackner]

On 11.11.2015 07:11, Ken Thomases wrote:
> On Nov 10, 2015, at 10:30 PM, Sebastian Lackner
> <sebastian(a)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.

Thanks for the confirmation.
> 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.

I think this is an issue which should be fixed independently. The
delayed call to the ClipCursor driver function could always cause
problems, if the app for example quickly changes the clipping
rectangles multiple times. Obviously the desktop should not override
the applications decision in this case.
> 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