Opened 6 days ago

Closed 8 minutes ago

#11893 closed defect (fixed)

Switching to fullscreen and back to windowed mode captures the mouse cursor

Reported by: eriktorbjorn Owned by: ccawley2011
Priority: normal Component: Graphics
Keywords: Cc:


If I start ScummVM in windowed mode, hits Alt+Enter to switch to fullscreen, and then again to switch back to windowed mode, the cursor is captured. (This threw me off for a while, because the game where I first saw it had no visible mouse cursor at this point.)

From what I understand, this is because of how SdlWindow::createOrUpdateWindow(9 is implemented. In fullscreen mode, it will automatically grab the cursor (in case the fullscreen graphics doesn't actually cover the entire screen, perhaps?). When returning to windowed mode, it sees that the cursor was grabbed and assumes it should still be.

It can be released with Alt+M, of course. But is this really the intended behavior?

Change History (8)

comment:1 by macca8, 5 days ago

This appears to have been introduced with the latest daily build (2.3.0git9436).
I'm seeing the same behaviour when returning from a fullscreen game to a windowed Launcher.
Users will either love it or hate it, depending on their need to leave the window.

comment:2 by eriktorbjorn, 5 days ago

Well, unless I've explicitly locked the mouse cursor to the window myself, I would think that switching from fullscreen to windowed mode is a pretty clear sign that I do want to leave the window. Or is that just me?

comment:3 by macca8, 5 days ago

Windowed mode gives access to your desktop, and the opportunity to leave the window for any number of reasons. In this situation of switching between screen modes, then leaving, having to continually release the cursor for each exit is, in my opinion, an unnecessary burden on affected users.

Last edited 5 days ago by macca8 (previous) (diff)

comment:4 by sluicebox, 3 days ago

I hope this isn't intentional because it ruins the program for me.

comment:5 by sluicebox, 3 days ago

Phew, it looks like this is just an unintentional result of a refactor:

comment:6 by macca8, 35 hours ago

It appears that on macOS this change in behaviour is restricted to the 64 bit build. The 32 bit build is unaffected on both macOS 10.6.8 & 10.11.6.

comment:7 by ccawley2011, 3 hours ago

Owner: set to ccawley2011
Resolution: fixed
Status: newpending

This should be fixed by PR #2554.

comment:8 by ccawley2011, 8 minutes ago

Status: pendingclosed
Note: See TracTickets for help on using tickets.