MACOS: mouse cursor appearing / failing to capture when in fullscreen mode

[almeath]

In ScummVM 2.7.0 (or later daily builds), in macOS Ventura (13.3.1) when in fullscreen mode and using either SDL or OpenGL rendering, in any game, the macOS mouse cursor will appear at random, super-imposing itself over the top of the relevant game cursor. The issue is discussed and illustrated in this thread on the ScummVM forum:

​https://forums.scummvm.org/viewtopic.php?p=98272#p98272

This video demonstrates the behavior of the cursor when moved to the edge of the screen, when in fullscreen mode:

​https://www.dropbox.com/s/jt7f24mnaa0pyqo/Ventura%20mouse.mp4?dl=0

Sometimes, however, the cursor will appear at random, following clicks of the mouse, when still within the perimeter of the game window.

While there are suggestions this is related to SDL2, I have not been able to re-produce this exact behavior in other SDL2-reliant apps. Also, the behavior is manifesting itself when setting ScummVM to use either OpenGL or SDL rendering.

I tested further in macOS Mojave, and the issue does not occur with the same builds of 2.7.0 (either self-compiled, or downloaded from the ScummVM website) so the issue appears to be specifically in relation to how current builds of ScummVM are interacting with macOS Ventura.

[ahrib]

I also experience this in fullscreen mode. This could possibly have something to do with the "notch" on the macbook screen.

Surprisingly this issue is not present if you start in windowed mode and use the window control to enter full screen.

The easiest way I have found to repeat the issue is:

1. Start ScummVM in fullscreen mode
2. Move the mouse cursor UP all the way to the top of the screen (aim for a little further than the top of the screen)

Workaround:

1. Start ScummVM in windowed mode (fullscreen mode not enabled)
2. Enter full screen by clicking the green window control button on the top left of the window

ScummVM 2.7.0
macOS 13.4.1
MacBook Pro (14-inch, 2021) ​https://support.apple.com/kb/SP854

[SirBogman]

I tested this in different scenarios:

• On a 2023 Mac laptop with the camera notch, this issue occurs when using the built-in laptop screen.
• On a 2023 Mac laptop with the camera notch, this issue doesn't occur when using an external monitor as my primary screen.
• On a 2019 Mac laptop without the camera notch, this issue doesn't occur at all.

Enter full screen by clicking the green window control button on the top left of the window

This works as a workaround. It's worth noting that it's not quite the same as what happens when you start a game in fullscreen.

When you enter fullscreen via the green button on the window: when you move the cursor to the top of the screen, the macOS menu bar and the title bar for the ScummVM window temporarily become visible. But when you move the cursor back down, it goes away and you only see the in-game cursor.

When you enter fullscreen via ScummVM, either by starting in fullscreen or by using option+return to enter full screen: when you move the cursor to the top of the screen, the macOS menu bar does not become visible, but when you move the cursor back down you see both the macOS cursor, and the in game cursor, on top of each other. The macOS cursor goes away if you toggle fullscreen with either option+return (twice) or command+tab (twice).

[SirBogman]

This seems to be related to capturing the mouse in fullscreen. When you enter fullscreen via the green button on the window, the mouse is not captured and the issue doesn't occur. If you capture the mouse with control+m, then the issue occurs as it would in normal fullscreen, which captures the mouse.

[SirBogman]

| Also, the behavior is manifesting itself when setting ScummVM to use either OpenGL or SDL rendering.

This doesn't matter. SDL is always used to manage the visibility of the system cursor on macOS.

This is most likely a bug in SDL, although it may be possible to workaround it without modifying SDL. The APIs SDL_SetWindowMouseGrab and SDL_SetWindowMouseRect are related to capturing the mouse. In a local build, I modified SdlWindow::setMouseRect to adjust the rectangle so that y is at least 44 and height is reduced by the same amount. This fixes the bug where the system cursor shows up when you move to the top of the screen, but it also means that you can't move the mouse all the way to the top of the screen. It's not a proper fix. With an unmodified rectangle, SDL is allowing the system cursor to reappear after the mouse is moved to this region, even though we have indicated that it should not via SDL_SetWindowMouseGrab. Tested with SDL 2.30.0.

Also, there is a different scenario that can cause the system cursor to be visible over the in-game cursor. Taking a screenshot with cmd+shift+4 and then clicking on the window. This is likely a separate SDL bug and for this one, it doesn't matter whether you are using the built-in display of a newer macbook. It always happens.

One way to get rid of the double cursor, when it occurs, is to use ctrl+m to uncapture the mouse, then move it offscreen, then move it back onscreen, then capture it again with ctrl+m.

[SirBogman]

I made a local build of SDL 2.30.0 that fixes the issue almost completely. The one exception is that I know of is, if you take a screenshot with cmd+shift+4, then the system cursor is visible until you move them mouse (I'm ok with this).

ScummVM is constantly calling SDL_ShowCursor(0), when the mouse moves, to hide the cursor.

In the implementation of SDL_ShowCursor, if the desired state (visible or not) matches the state cached in SDL_Mouse::cursor_shown, then nothing is done. The problem is that the state of SDL_Mouse::cursor_shown can get out of sync with the actual state of the system cursor visibility. If I remove the comparison to the cached state and just always update the cursor visibility, then it works. I'll look into whether I can fix this in a way that is appropriate for submission to the SDL library.

[SirBogman]

As far as I can tell, this bug seems to be entirely Apple's fault. It's easy to reproduce in a very simple test application. But I'm trying to come up with a suitable workaround that can be implemented in SDL.

[SirBogman]

I have a proposed workaround in SDL: ​https://github.com/libsdl-org/SDL/pull/9294

[SirBogman]

This is fixed in SDL 2.30.2.