(SDL) Starting ppsspp full screen is broken

[orbea]

What happens?

With the SDL front end using either OpenGL or Vulkan and starting ppsspp full screen will cause it to render a tiny ppsspp window in the corner of the full screen. With opengl the rest will be black and with vulkan it will render graphical garbage / static. They will also occupy different corners.

The mouse cursor will be relative to the entire screen and not the tiny displayed window making it impossible to use effectively while the keyboard still works, but toggling full screen in the ui will not take effect until ppsspp is closed and then started again.

Edit: Actually toggling the full screen setting in the ui does work, but ppsspp doesn't resize the window automatically. Manually resizing the window works for OpenGL and OpenGL ES, but with vulkan it triggers issue #11014.

If ppsspp starts windowed and not full screen then toggling full screen in the ui works fine.

With OpenGL ES and the SDL front end this problem does not occur, but ppsspp always starts full screen and the full screen toggle does nothing. (#11627)

After PR #11632 this issue is now exposed for OpenGL ES too.

With the Qt front end this is not a problem, but the full screen toggle does take effect until ppsspp closes and starts again. Double clicking the mouse does immediately toggle full screen here like in mpv or pcsx2. (#11626)

OpenGL / OpenGL ES

Vulkan

What should happen?

It should be possible to start ppsspp as a full screen program without issues.

What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues.

OS: Slackware64-current
Linux: 4.19.5
ppsspp: 95ffa15
mesa: https://github.com/mesa3d/mesa/commit/94bfb8bf386b560e8e6095727ed1cf08522a027d
SDL: 2.0.9
vulkan-sdk: 1.1.92.1
xorg: https://cgit.freedesktop.org/xorg/xserver/commit/?id=82f8cf8990009f6cac567814dd6b7fd41cfad82d
window manager: conformal/spectrwm@b365987
GPU: AMD RX Vega 56 (amdgpu + radeonsi)

$ glxinfo | grep -e Core -e GLES
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.0.0-devel (git-94bfb8bf38)

[orbea]

Maybe the same issue as #7301.

[orbea]

An easy way to reproduce on my system is with xinit(1).

From an unused tty.

xinit /usr/games/ppsspp -- :1

Or

xinit /usr/bin/xterm -- :1

And then start ppsspp in the spawned xterm.

Note that xinit requires a full path to the program you wish to start.

Also testing this with vulkan is potentially seizure inducing...

[orbea]

PR #11632 now exposed this for OpenGL ES too where the behavior matches regular OpenGL. I'm not sure this is really a regression as much as it is a clue.

[orbea]

Another correction is that the full screen toggle in the ui actually does work, but it doesn't automatically resize the window making it seem like its non-responsive. With OpenGL or OpenGL ES the window can be resized manually which corrects the rendered ui to match the new window size.

With Vulkan resizing the window freezes ppsspp which becomes unresponsive and has to be forced to close. (#11014)

My understanding is that ppsspp is resizing the rendered ui, but not the actual window or vica versa in some cases. Unfortunately I am not sure where to look in the code.

I have not yet tested the pending fix for the above vulkan issue in PR #11451.

[unknownbrackets]

Is this the same as #6562, or related?

-[Unknown]

[orbea]

There is not enough information in that issue to confirm if its the same or not, but it probably is the same issue. I suspect it affects many users who do not use a complete desktop environment, maybe ppsspp is relying on something that is only supported in a few places?

[orbea]

I'm not sure why the previous comment was deleted, but thanks for pointing out --fullscreen. This seems to only be an issue with the ui toggle.

[vnctdj]

Are you still affected by this issue now that #11014 has been fixed, @orbea ?

[orbea]

@unknownbrackets You can wait more than 4 hours to add a No Feedback tag....

@vnctdj I tested the master (54e102c) and this issue is fixed, but I found two remaining issues with SDL + fullscreen.

1. When ppsspp is started in fullscreen mode or with --fullscreen the fullscreen toggle in the menu doesn't do anything. This is similar to issue (Qt) Full screen toggle does not take immediate effect #11626.
2. The fullscreen toggle keybind doesn't do anything with the SDL frontend, it works with the qt5 frontend.

[unknownbrackets]

It's also outdated now, which means "possibly fixed but not confirmed". I use it on some filters so it's handy to apply, sorry if it seemed like I was rushing you.

-[Unknown]

[unknownbrackets]

Does it improve anything to change this in SDLMain.cpp?

void ToggleFullScreenIfFlagSet(SDL_Window *window) {
	if (g_ToggleFullScreenNextFrame) {
		g_ToggleFullScreenNextFrame = false;

		Uint32 window_flags = SDL_GetWindowFlags(window);

Change the last line to:

		Uint32 window_flags = SDL_GetWindowFlags(window) & SDL_WINDOW_FULLSCREEN_DESKTOP;

Also, what version of SDL2 are you using?
https://bugzilla.libsdl.org/show_bug.cgi?id=2479

-[Unknown]

[orbea]

I am using SDL-2.0.9.

I realize now that I misinterpreted the first issue. The menu toggle works, just the window resolution resets to the original resolution which when started as fullscreen is the same as the fullscreen resolution. Since I don't have window borders I did not notice it was windowed and not fullscreen...

The suggested change doesn't help here nor does it help the 2nd keybind issue which does nothing even if I set it to F11 in the menu.