BACKENDS: MacOSX - System cursor always visible when in fullscreen mode.

[macca8]

This report refers to using ScummVM with the global options set to fullscreen mode, and all other options (including Graphics Mode) set to their normal defaults.

ScummVM version: Stable release 2.0.0 (9 Dec 2017 13:39:54), 64-bit only.
Platform: Intel Mac (OS X 10.11.6)

After selecting the 'Start' option or loading a saved game, the system cursor appears on top of the game cursor and tracks its movements across the screen.

When the game cursor disappears (for example, during a cutscene), the system cursor remains visible and responds to mouse movements, but doesn't interact with the game.

The system cursor also behaves the same with the ScummVM cursor when it's in use (for example: Launcher, GMM, save/load screens & dialogs), but not until after ScummVM has launched a game in the current session.

ScummVM must be restarted to remove the system cursor, but then the bug returns as soon as a game is launched (in my case, Riven is the only game installed).

Unfortunately, screenshots failed to record the system cursor’s presence.

This issue does NOT occur in:

• windowed mode.
• ScummVM 2.0.0 (9 Dec 2017 13:38:28) 32-bit, on OS X 10.6.8.
• the current daily build (2.1.0git134 18 Dec 2017).

Not really relevant, but just an observation about unexpected differences between the 2 Intel Mac stable releases:
I don’t know if it’s intentional, but the 32-bit Intel Mac stable release’s general behaviour & appearance is identical to the current daily build, whereas the 64-bit release displays a larger fullscreen image for both the Launcher & game screens, plus the Filter Graphics option is always available (and in my case, required).

[csnover]

Thanks for your report! Unfortunately, I am not able to reproduce any issue with the mouse cursor in fullscreen mode using 64-bit ScummVM 2.0.0 on macOS 10.12.6 (and I never noticed any persistent mouse issue like this in pre-release versions when I was still using 10.11), using NVIDIA GPU in dual monitor configuration running on the primary monitor. As such, I’m not sure if this is an issue only with 10.11.6, or an issue with your configuration, or some other thing.

I do know that from time to time SDL will just fail to control the visibility of the system cursor successfully (in all applications, not just ScummVM, and not just in fullscreen mode), in which case ⌘+tabbing out and back in to the affected application often fixes the problem. You may also try hitting ctrl+m to toggle mouse grab when in fullscreen mode and move the mouse out and back in to the game area.

If you continue to have difficulty, it will be necessary to provide more detailed reproduction information and information on your setup, since here, running 64-bit ScummVM 2.0.0 (using either OpenGL or HQ2x renderers) in fullscreen mode works correctly when starting ScummVM normally and then hitting ⌘+enter to enter fullscreen mode.

[macca8]

Thanks for your response csnover.

I’ve performed some tests and identified the following:

• the issue is triggered when the Launcher is set to fullscreen mode, and then only in certain scenarios.
• the game screen cursor (including associated in-game items, such as the GMM) is independent of the Launcher cursor, as far as applying a manual fix is concerned… each must be fixed separately.
• the issue doesn’t occur in the 32-bit stable release when run on OS X 10.11.6 (or 10.6.8)… am I correct in assuming that the 32-bit release is made with SDL1 & the 64-bit release with SDL2?

These scenarios reproduce the issue:

• launching a game that is set to be displayed in fullscreen mode (either a new or saved game) from a fullscreen Launcher… this attaches the system cursor to all cursors used in the game screen (game & ScummVM).
• returning to a fullscreen Launcher from a game displayed in fullscreen mode… this attaches the system cursor to the Launcher’s cursor.
• returning to a fullscreen Launcher from a game displayed in windowed mode… this attaches the system cursor to the Launcher’s cursor (note that if no action has occurred since the game was loaded, then the issue may not appear).

The following options are used (otherwise standard defaults):

• Global options: Graphics mode is <default>.
• Global options: Fullscreen is enabled.
• Game options (1st & 2nd scenarios): use global graphics.
• Game options (3rd scenario only): override global graphics, but use game’s default settings.

As for handling the issue, your suggestion to use Cmd+Tab & Ctrl+m both removed the system cursor (except Ctrl+m which failed in the Launcher, presumably because the Launcher occupies the full screen), but only for as long as no switch is made between the Launcher and the game.
I also found that using Alt+Enter (technically, Alt+return on my keyboard) to switch to windowed mode, then back to fullscreen mode, also worked, with the same caveat.

Still, a better result is to actually prevent the issue in the first place. Assuming that you still can’t reproduce the issue, either of the following methods can avoid the issue:

• always leave fullscreen disabled in the Global Options, or
• launch the game directly from the dock & quit from in-game (avoiding the Launcher completely).

As far as my setup is concerned, I have a 2008 Intel Core 2 Duo iMac, with ATI Radeon HD 2600 Pro graphics, running OS X 10.6.8 & 10.11.6 on separate partitions.

[macca8]

csnover, regarding your test criteria with the 64-bit 2.0.0 stable release:

• I can confirm that this issue doesn’t occur when Graphics mode is set to OpenGL, though OpenGL has its own long standing issue of displaying a fullscreen background with windowed-size elements (including the cursor) when the Launcher (or Save/Load screen) is displayed in fullscreen mode on Mac OS X, but that’s not relevant here.
• other Graphics modes dependent on SDL2 (including HQ2x) are affected by this issue (which includes the <default> setting as noted above).

Also, I note that the current pre-release version (2.0.1pre9 21 Dec 2017) appears to be built with SDL1.2, and doesn’t have this issue in OS X 10.11.6.

If the pre-release versions of 2.0.0 you tested in OS X 10.11, were also built with SDL1.2, or you only used OpenGL, then that would explain why you didn’t see the issue before the official release.

Secondly, are you using a compact Apple keyboard (with a single return/enter key), or a full-size keyboard (with separate return & enter keys)?

I have a full-size Apple keyboard, and a second issue has emerged when using the Enter key as part of the Alt+enter combination, but again, only with the 64-bit 2.0.0 stable release.

In my case, it appears that Enter is mapped to the separate Return key (which makes sense, given the different keyboard layouts available), but NOT the separate Enter key (or at least, incorrectly).

As a result, Alt+return successfully toggles between screen modes, whereas Alt+enter does not.

Alt+enter does nothing in the game screen (expected behaviour in this scenario), however, things get weird when using Alt+enter in the Launcher.

In this case, pressing Alt+enter launches the currently selected game’s start screen… the equivalent of clicking the Launcher’s Start button (occurs in both windowed & fullscreen modes).

Incidentally, you refer to using Cmd+enter to toggle fullscreen (or was that just a typo?). For me, both Cmd+enter & Cmd+return share the same anomalies as Alt+enter in this case.

Can you reproduce this issue on a full-size keyboard?

Note that, unlike the main issue, this applies when Graphics mode is <default>, and also when set to OpenGL.

I don’t understand how all this ties together, but hopefully it makes some sense to you.

[macca8]

Just a few additional comments about what I’m seeing on my system…

Firstly, the system cursor is displayed at its system’s default size (similar to windowed mode cursor size), never scaled to match fullscreen ScummVM or game cursors.

Secondly, since the presence of a fullscreen Launcher (when switching to or from a game) is required to trigger this cursor display issue, and it only occurs with the SDL2 backend, and NOT SDL1 (or versions thereof) or OpenGL, what differences apply in fullscreen mode?

A fullscreen Launcher in SDL2 displays:

• a window that fills the entire screen (no black borders).
• a properly scaled full-size red arrow cursor (significantly larger than the system cursor, when present).

On the other hand, these differences apply in the unaffected backends:

• SDL1: displays a window that is surrounded by black borders on all sides… also applies to game screens.
• OpenGL: ALWAYS displays a windowed-size red arrow cursor (regardless of screen mode)… also applies when used inside a game screen (though game cursors are correctly scaled).

Make of this what you will, but it does suggest that BOTH SDL2 Launcher conditions must be present to trigger the bug.

An interesting point is that OpenGL leaves lingering effects when switched to another Graphics Mode, which can cause unexpected behaviour in the new Graphics Mode, and distort testing, if ScummVM is not immediately restarted after the switch is completed.

The effects can be as obvious as retaining OpenGL’s behaviour (when switching to <default>), to simply repositioning the windowed-mode window in the top left corner of the screen when switching from fullscreen.

[macca8]

SDL fullscreen launcher - screenshots don't capture the black borders of SDL1, so both SDL1 & 2 images are identical.

[macca8]

OpenGL fullscreen launcher - note windowed-size elements, including cursor.

[digitall]

Since the user has provided replication information, this artifact is no longer pending. Though will need a MacOS developer to try to replicate.

@criezy: Any chance of taking a look?

[criezy]

I have never noticed such issue in fullscreen mode myself, and I tried today to replicate exactly the steps as describe here on both macOS 10.9 and 10.12, and I cannot reproduce.

However I randomly have similar issues myself when starting ScummVM in windowed mode. Sometimes, but not always, I have both the ScummVM cursor and the system cursor visible in the launcher. This seems to be a focus issue as the system cursor disappears if I click oustside the ScummVM window and then click in the window to give it back the focus.

[macca8]

The issue regarding the misbehaving Enter key in #comment:3 has been resolved by later versions of SDL.
At this stage, best case scenario for the system cursor issue is that it's limited to MacOS 10.11, but it may well end up being a local issue.

FWIW, the 64-bit v2.1.0 release and the 64-bit daily builds (developmental & stable) all display the system cursor issue on macOS 10.11.6, at least for me.

[macca8]

At the end of March 2021, buildbot upgraded its macOS 32-bit & 64-bit daily builds to SDL 2.0.14, resulting in both 32-bit & 64-bit daily builds now displaying this behaviour.

At the time, OpenGL was still exempt, however the implementation of the HiDPI scaler that followed mid April 2021 changed the status of OpenGL, such that it also now displays this behaviour.

A significant change in that implementation was an increase in OpenGL's GUI scaling by a factor of 1.5, resulting in larger GUI elements, including the ScummVM cursor, when viewed in fullscreen mode.

Currently, only the 32-bit v2.2.0 release remains fully exempt from this issue.

With respect to other builds, only switches involving 3D games remain exempt.

[criezy]

I had another look at this, and I still cannot reproduce.
I tested both my own builds and the 64 bit intel daily build.
I tested on 4 different systems (10.9 and 10.12 iMac, 10.15 MacBook Pro, and 11.5 M1 MacBook Air).

This might be an issue specific to Mac OS 10.11, but that would be strange.

Are you sure there is not something running on your mac that might be stealing the focus and causing the system cursor to appear?

This might also be related to bug #12646.

[sev-]

This is not a case anymore, at least not with modern macOS. Closing as 'works for me'