Issue with al_set_mouse_xy on secondary monitor (Mac)

[Dominator101]

I've encountered what appears to be an issue with how the set mouse function is behaving when used on my non-primary monitor where rather than jumping to the display coordinates in the window it ends up instead jumping to the seam between the screens. Here's a video of it occurring since it might not come across well in text (in this video my primary monitor is to the right of the monitor being recorded, and the recording captures up to the right edge of the screen). This uses the stock ex_mouse_warp example.

AllegroMouseWarp.mov

For reference, this was originally seem in a different project, in case that might be helpful to see what we've already discussed, but I'll try to give the most relevant tests I've done.

• This only seems to happen on secondary monitor, the primary monitor traps the mouse correctly
  • Switching which monitor is my primary changes which screen works/doesn't, so it does seem to be that rather than an issue with the specific monitor
• I've tested with the System Preference "Displays have separate Spaces" both enabled and disabled, same behavior

I'm running MacOS 10.14.5 (Mojave)

Let me know if there's any other information I can provide.

[SimonN]

I don't have a Mac to debug this, but here are ideas:

• Look at macosx/qzmouse.m, function osx_set_mouse_xy(), it does some coordinate mathematics. Are they semantically correct?

• Which of the coordinates in the mathematics are global, which are monitor coordinates?

The global display coordinate system spans across all monitors. The primary monitor's (0, 0) coordinate matches the global (0, 0). Any secondary monitors will have their own (0, 0) sit at some global (x, y) different from the global (0, 0). Source: Mac API docs for CGMainDisplayID().

Confusing global coordinates with monitor coordinates will lead to bugs on a secondary monitor, even when it wouldn't have mattered on the primary monitor where both coordinate systems match. Since Dominator's bug happens only on the secondary monitor, the hunch is to look for such a confusion:

• Are there any bugs from using a global coordinate where the Mac API expects a monitor coordinate, or vice-versa?

• The types in the math are CGPoint, NSPoint and NSRect, are the conversions correct?

• Does the A5 code get the correct display ID from CGGetDisplaysWithRect()?

I'm the author of Lix where the original bug was filed. The debugging ideas above come from Forestidia's thread on Lemmings Forums about this bug; Forestidia watches both github bugs (this A5 1236 and Lix's 419) and will reply in that thread.

[SimonN]

@Dominator101: Does our bug still manifest with Allegro 5.2.8.0?

Allegro 5.2.8.0 merged #1286, the fix for OSX coordinates. That fixes #923 and, as pedro-w suggests, has a chance to also fix our bug here.