<div><div dir="auto">I was hoping Brendon or Chip would give some feedback on this but guessing there busy and not noticed this yet.</div><div dir="auto"><br></div><div dir="auto">This looks good to me and has been tested with a couple of games.</div></div><div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 19, 2022 at 2:40 PM Tim Clem <<a href="mailto:tclem@codeweavers.com" target="_blank">tclem@codeweavers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">The Mac driver has historically used session-wide CGEventTaps to<br>
implement ClipCursor. In macOS Mojave, such event taps started<br>
requiring Accessibility permission from the user. That's problematic<br>
on two levels:<br>
<br>
First, it's a hassle. Unlike, say, microphone permissions, the user<br>
can't just click "Approve" on a dialog box. Instead they have to go to<br>
the System Preferences app, enter their password, and click a checkbox<br>
(which will have the name of the preloader). This is especially bad<br>
because ClipCursor is frequently called by fullscreen games, which<br>
means the permission prompt will be hidden.<br>
<br>
Second, many apps misbehave if ClipCursor fails. For instance, some<br>
Unity games (e.g. Raft, The Forest) exhibit erratic mouse movement in<br>
that case. But apps are likely to end up in that state since<br>
Accessibility permission is deny-by-default and there is no blocking<br>
call to check for the permission. The attempt to install an event tap<br>
immediately fails until the permission is granted.<br>
<br>
As of 10.13, there is an undocumented NSWindow method<br>
-setMouseConfinementRect: that is in many ways a better option. It<br>
does not support certain uncommon scenarios (clipping to regions<br>
outside of a window), but it is far simpler and requires fewer<br>
workarounds than the event tap. It also does not require permission<br>
from the user.<br>
<br>
This series of patches factors the existing clipping code out of<br>
cocoa_app.m into its own class. It then adds a second implementation<br>
of that interface that uses -setMouseConfinementRect:. Finally it<br>
enables that approach by default in 10.13+, adding a registry key to<br>
enable the old behavior if needed.<br>
<br>
I'd welcome any feedback or suggestions. If you know of any apps that<br>
clip the cursor to a region outside of a single frontmost window, I'd<br>
also love to hear about those.<br>
<br>
Tim Clem (5):<br>
  winemac.drv: Factor out cursor clipping code to its own class.<br>
  winemac.drv: Create a protocol to represent a cursor clipping handler.<br>
  winemac.drv: Factor common cursor clipping methods into functions.<br>
  winemac.drv: Add a cursor clipping implementation using<br>
    -setMouseConfinementRect:.<br>
  winemac.drv: Use -setMouseConfinementRect: for cursor clipping by<br>
    default.<br>
<br>
 dlls/winemac.drv/Makefile.in            |   1 +<br>
 dlls/winemac.drv/cocoa_app.h            |  11 +-<br>
 dlls/winemac.drv/cocoa_app.m            | 333 ++--------------<br>
 dlls/winemac.drv/cocoa_cursorclipping.h |  73 ++++<br>
 dlls/winemac.drv/cocoa_cursorclipping.m | 510 ++++++++++++++++++++++++<br>
 dlls/winemac.drv/macdrv_cocoa.h         |   1 +<br>
 dlls/winemac.drv/macdrv_main.c          |   4 +<br>
 7 files changed, 626 insertions(+), 307 deletions(-)<br>
 create mode 100644 dlls/winemac.drv/cocoa_cursorclipping.h<br>
 create mode 100644 dlls/winemac.drv/cocoa_cursorclipping.m<br>
<br>
-- <br>
2.34.1<br>
<br>
<br>
</blockquote></div></div>
</div>