PCSX2 / pcsx2

PCSX2 - The Playstation 2 Emulator
https://pcsx2.net
GNU General Public License v3.0
11.85k stars 1.63k forks source link

[BUG]: Emulator qt window lost ability to fullscreen itself but the wxwidgets variant works #6917

Closed NetSysFire closed 2 years ago

NetSysFire commented 2 years ago

Describe the Bug

When enabling automatic fullscreen on game start in the settings (can only be set to borderless fullscreen as there is no other option), the emulator window does lose its window decorations but is not actually fullscreen, so I have to force fullscreen via my window manager, awesomewm.

This is a regression and likely related to the new UI. It worked in the past.

Reproduction Steps

  1. Use a standalone window manager (unsure if related, as I know no other PCSX2 users on Linux).
  2. Enable automatic fullscreen in the settings.
  3. Window does not fullscreen.

The following is in the emuLog.txt when starting any game:

updateDisplay() fullscreen=true render_to_main=false surfaceless=true

Relevant config snippets:

PCSX2.ini

[UI]
SettingsVersion = 1
DisplayWindowGeometry = AdnQywADAAAAAAAAAAAAHgAAB38AAAQ3AAAAAAAAADgAAAO/AAAENwAAAAACAAAAB4AAAAAAAAAAOAAAB38AAAQ3
StartFullscreen = true
MainWindowGeometry = AdnQywADAAAAAAAAAAAAHgAAB38AAARRAAAAAAAAADgAAAO/AAAENwAAAAACAAAAB4AAAAAAAAAAOAAAB38AAARR
MainWindowState = AAAA/wAAAAD9AAAAAAAAB4AAAAPuAAAABAAAAAQAAAAIAAAACPwAAAABAAAAAgAAAAEAAAAOAHQAbwBvAGwAQgBhAHIAAAAAAP////8AAAAAAAAAAA==
RenderToSeparateWindow = true
HideMouseCursor = true

PCSX2_ui.ini

[GSWindow]
CloseOnEsc=enabled
DefaultToFullscreen=enabled
AlwaysHideMouse=disabled
DisableResizeBorders=disabled
DisableScreenSaver=enabled
WindowSize=960,1024
WindowPos=0,30
IsMaximized=disabled
IsFullscreen=enabled
EnableVsyncWindowFlag=disabled
IsToggleFullscreenOnDoubleClick=disabled
AspectRatio=16:9
FMVAspectRatioSwitch=Off
Zoom=100

Expected Behavior

Window is actually fullscreen. I can either hit Alt+Return a couple of times and it will fullscreen correctly or I can instruct my window manager to make that window fullscreen, which works perfectly and on the first try.

PCSX2 Revision

v1.7.0.dev.r4138.g8b2966e29-1

Operating System

Linux (64bit) - Specify Distro Below

If Linux - Specify Distro

Arch Linux

stenzek commented 2 years ago

Works fine for me. I'm gonna say package issue and/or an incompatibility with your WM. The -1 on the end of the revision suggests it has been patched, in which case, we don't provide support for it.

The following is in the emuLog.txt when starting any game: updateDisplay() fullscreen=true render_to_main=false surfaceless=true

updateDisplay() doesn't get called when starting, only when toggling.

weirdbeardgame commented 2 years ago

On pcsx2-git, I can confirm the window still fullscreen's automatically when the option is enabled. Might be the WM or something along those lines

ps1freak26 commented 2 years ago

It happens for me when I enable start in fullscreen it always hides the window with the game list. image

NetSysFire commented 2 years ago

The -1 on the end of the revision suggests it has been patched, in which case, we don't provide support for it.

It has not been patched in a way that makes it unsupported. This is just makepkg adding the pkgrel which is present on every package. This is how packaging on Arch Linux works. The pkgrel will also get changed for soname bumps. In order for PCSX2 to work at all I am depending on the patch at https://github.com/kenshen112/pcsx2/commit/160deb2ec928b171370f33b6fbc0146bc5fd9910 which adjusts the resource path and no other behavior of the application as you can see.

Might be the WM or something along those lines

This is not the case since it did work before the new UI has been introduced. Every other application can also properly fullscreen itself. Only PCSX2 has these issues.

I have no idea how to debug this, except for posting a log of me booting into the PS2 BIOS to resolve the mystery about updateDisplay(). Bisecting is unfortunately not really possible because manually patching the issue about the resource paths is going to be very painful. I already tried and failed in epic proportions.

stenzek commented 2 years ago

Doesn't matter. We only support the appimage, end of story. If you have package problems, take it up with the packager, not us.

So, that said,dDoes it happen with the appimage? If it does and I can get this WM on Ubuntu then I can look at what's going on, but I am not spending hours setting up an arch install.

NetSysFire commented 2 years ago

Yes it does. It behaves exactly the same as my arch installation. Do you still want logs?

stenzek commented 2 years ago

Logs don't really say much. But I would suggest trying a different wm to at least narrow down the problem, like I said, it just may not be compatible with the way we initialise things.

(Especially since every other compositor I've used is fine)

weirdbeardgame commented 2 years ago

And it's working on my end with pcsx2-git as I mentioned. That being said, I'd also be curious what Graphics card you have. Could be a case with the driver doing some odd behavior though I'd bet it's the WM as well

NetSysFire commented 2 years ago

This is a rx570. The issue is a regression, it worked before the update to qt. I assume using the build with wxwidgets would rule this out?

weirdbeardgame commented 2 years ago

Not nessacarily. The best course would be to try and test the older QT AppImage builds to figure out if or when it regressed in QT

NetSysFire commented 2 years ago

Last time it worked was when I used the non-qt build, so it might have never worked with qt, so I am unsure if trying older builds would help here.

F0bes commented 2 years ago

You're the one with the issue. Please test by bisecting.

weirdbeardgame commented 2 years ago

^ another question. Are you using Xorg, or Wayland

NetSysFire commented 2 years ago

awesomewm is Xorg-only. So Xorg.

weirdbeardgame commented 2 years ago

Can you try it on a non tile based desktop like Plasma or gnome based environments real quick?

NetSysFire commented 2 years ago

Sorry, I can not install an entire desktop environment for this. I just tried the wxwidgets build and it works. So the issue is with qt only.

Edit: And to be absolutely clear: Everything works, except PCSX2. This is not an issue with my wm because nothing changed. This is probably an issue with the qt-build missing some fullscreen implementation which the wxwidget-build has.

stenzek commented 2 years ago

So you won't try to narrow down the problem, but expect us to install your desktop environment to do so?

stenzek commented 2 years ago

Tested with whatever version of awesome is included with Ubuntu 20.04, with auto-fullscreen on both command-line game starting and game list starting, works perfectly fine.

Closing as invalid since can't reproduce. If you continue to have issues with the package, please report it to the packager, not us.

NetSysFire commented 2 years ago

please report it to the packager, not us

This affects the appimage you wanted me to test. As I said, the appimage behaves exactly like my build plus I managed to reproduce those issues on the appimage.

So you won't try to narrow down the problem, but expect us to install your desktop environment to do so?

First of all, my "desktop environment" is a singular window manager that comes without a myriad of applications.

I did:

  1. attempt to bisect, only to discover that I would need to manually patch plus the resulting build is not even supported by you
  2. try different versions (wxwidgets vs qt in this case, to prove that this is not "my wm")
  3. search all logs and config files for anything relevant and shared all the results.

Installing an entire desktop environment pulls in all of their tools, clutters the home directory, /etc and more, plus it is a pretty giant download, which you should know. You simply can not compare the two like this.

Anyways. I am a bit disappointed that all I got so far was anything but hints on how to debug this. wxwidgets works, qt does not. I have a feeling this might be related due to how PCSX2 does the actual fullscreen invocation. I highly doubt this is related to qt because all the qt applications I use can fullscreen themselves just fine. And to be very clear here: Every application I use can fullscreen itself without any problems. Only the qt build is having trouble. It looks like what PCSX2 is doing is maximizing but dropping the window decorations. I doubt it would make sense to bisect the qt build here because I have a feeling it never worked in the first place.

If I had to guess, I would say that the problem could be screen padding, where you can reserve space for e.g a bar. A proper fullscreened window will always override this, so this is another indication that PCSX2 does not fullscreen correctly.

weirdbeardgame commented 2 years ago

The issue is, so far. You've been the only one having this issue regardless of whether it's been package or AppImage. And I told you, go back to older QT versions not WX and see if there's one that works you don't necessarily have to DL ALL of them just do it in segments of every 5 or 10 versions. If there is a working one, that's a start.

Not necessarily. The best course would be to try and test the older QT AppImage builds to figure out if or when it regressed in QT

stenzek commented 2 years ago

I went to the effort of installing your WM and testing it, and it works fine for me. Dunno what else you want or expect me to do, as this is now a support issue rather than a bug report.

I came across a post recently which I'm going to start responding with when people get unhappy: https://boyter.org/posts/the-three-f-s-of-open-source/

NetSysFire commented 2 years ago

And I told you, go back to older QT versions

The first ever appimage build of the qt version is from july 5th, which has this issue, too.

Dunno what else you want or expect me to do

To actually test it with screen padding like I said all the time. What your application is doing is to resize the window to the size of screen (e.g 1920x1080, in my case) and make it borderless (see qt documentation for this), which does not work because part of the space is reserved. It does not actually send a fullscreen signal because if it would, like the wxwidgets version does, it would behave properly.

stenzek commented 2 years ago

To actually test it with screen padding like I said all the time.

The version I used appeared to have this (the top of the screen was reserved). It worked fine.

What your application is doing is to resize the window to the size of screen (e.g 1920x1080, in my case) and make it borderless (see qt documentation for this), which does not work because part of the space is reserved.

Then this is not a problem with PCSX2. Look at how we're setting up the window: https://github.com/PCSX2/pcsx2/blob/b45748fead3fb25b1d648306b31aa608c0f26043/pcsx2-qt/MainWindow.cpp#L1886-L1897

In other words, we're doing none of what you're claiming.

It does not actually send a fullscreen signal because if it would

Maybe you should take it up with Qt instead. Because I'm definitely not polluting our code with special handling for window manager I didn't even know existed.

like the wxwidgets version does, it would behave properly.

Good. If wx is so great, keep using it.

NetSysFire commented 2 years ago

Then this is not a problem with PCSX2

Then why does it work with literally every other Qt application on my system using the same function? How would you like me to debug this?

Because I'm definitely not polluting our code with special handling for window manager

Welcome to Xorg. Enjoy your stay. Besides, this will also affect other window managers with screen padding, e.g openbox with screen_edge_strength.

The version I used appeared to have this (the top of the screen was reserved)

awful.screen.connect_for_each_screen(function(s)
    s.padding.top = s.padding.top+30
end)

Put that in rc.lua and try again. That puts 30 pixels of padding on the top of the screen. The default configuration uses wibar, which does not setup any actual padding. If you are unsure where to put that snippet, here is the upstream default configuration, the s.padding bit must go where the screen is exposed: https://github.com/awesomeWM/awesome/blob/master/awesomerc.lua#L132

stenzek commented 2 years ago

No thanks. I've already wasted enough time replying here and investigating.

If there is an issue here, you're free to debug it and submit a patch. If it's not a terrible hack for your particular environment, there'll be no problems merging it.

But this issue thread is closed, and I am not going to respond any further.