Advanced Strategic Command (asc): mouse confined to less than full screen

[smcv]

Prerequisites:

• Debian testing (Debian 12 alpha)
• Video: GNOME 43 in Wayland mode (with Mesa 22.2.0 on AMD Vega, if it matters)
• Audio: Pipewire 0.3.59, with pipewire-pulse emulating PulseAudio
• apt install barrage (Debian package version 1.0.5-1)
• Some relevant libraries:
  • libsdl1.2-compat commit 63e4393 (locally built) to avoid Advanced Strategic Command (Debian: asc): crash + busy-loop #230
  • libsdl2-2.0-0 version 2.24.1+dfsg-1
  • libsdl-image1.2 version 1.2.12-13+b1
  • libsdl-mixer1.2 version 1.2.12-17+b2
  • libsdl-sound1.2 version 1.0.3-9+b1
  • libsdl1.2debian (real SDL 1.2) version 1.2.15+dfsg2-8

To reproduce:

• asc
• LD_LIBRARY_PATH=.../sdl12-compat/_build asc
• SDL_VIDEODRIVER=wayland LD_LIBRARY_PATH=.../sdl12-compat/_build asc

Expected result: mouse can be moved anywhere

Actual result: real SDL 1.2 works. With sdl12-compat the mouse is confined to a subset of the screen and cannot enter the menu bar. The exact bounds seem to be unpredictable (uninitialized?)

[icculus]

So what's weird about this is that there isn't an SDL API in either SDL 1.2 or SDL2 to confine the cursor to a subregion of a window, so I'm not sure what is causing this yet.

The game is not calling SDL_WarpMouse either.

[icculus]

If I alt-tab out of the game and back, it fixes itself and I can move the cursor to the top of the screen.

Happens with both Wayland and XWayland...could it be a window manager bug?

[smcv]

Running asc on the same GNOME version in Xorg mode, I can't reproduce the bug.

[psycho-driver]

Seeing same behavior in Rune

5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64 GNU/Linux (MX-21)

sdl12-compat checked out 1/1/23 af404f0f9cd9a4f51a43a0d4078cbae70cca637c
libsdl2-2.0-0 2.0.14+dfsg2-3+deb11u1

EDIT:
For Rune's case the problem goes away if I set CaptureMouse=False in Rune.ini

With normal SDL1.2 the mouse behaves as expected with CaptureMouse=True

[smcv]

libsdl2-2.0-0 2.0.14+dfsg2-3+deb11u1

That's quite old, you might want to try with a locally-built SDL2.

[icculus]

Under the assumption this isn't an sdl12-compat bug, I'm bumping this out of the current milestone. But if anyone has some insight (including "it went away when I upgraded my system"), it would be welcome!

Eventually, if we don't find a reasonable way to track this issue down, I'll throw up my hands and close the issue outright, but it can live on for now.

[smcv]

I'm still seeing this with sdl12-compat 1.2.64 and SDL 2.26.5, in GNOME 43 on Debian 12.

The region I can't move the mouse into seems vaguely similar to the size of GNOME's top menu bar? That's space that's available to fullscreen apps like this one, but not used by maximized windows (analogous to the Windows taskbar).

Alt+Tab continues to be a workaround for this. Pressing the Windows key to go to the overview, and then going back into the fullscreen game, is also a workaround.

[icculus]

I'm wondering if this reproduces with a simple SDL_WINDOW_FULLSCREEN_DESKTOP app in SDL2 itself. I'll see if I can scratch together something comparable as a minimum reproduction case...but it's surprising this has never come up before, so it might be something about the exact sequence of things sdl12-compat does with SDL2...?

[smcv]

I'm wondering if this reproduces with a simple SDL_WINDOW_FULLSCREEN_DESKTOP app in SDL2 itself.

If I install the libsdl2-tests package, /usr/libexec/installed-tests/SDL2/testgeometry --fullscreen-desktop doesn't reproduce this issue.

[smcv]

Happens with both Wayland and XWayland...could it be a window manager bug?

It could be. I couldn't reproduce the bug with KDE Plasma (again in Wayland mode) on the same hardware, also under Debian 12. If it's a window manager bug then it seems odd that it's specific to sdl12-compat, though...

[smcv]

I opened https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038738 in the hope that Debian's asc maintainers might have some ideas.

[rebsol]

I have the same problem in OpenXCom issue 215. Just realized, I solved it by using Xorg instead of Wayland.