Closed aufkrawall closed 4 years ago
Issue confirmed and reproduced on this Intel laptop. Now to fix it...
Can't reproduce the bug with nvidia. I'm running some windows games with steam & proton. I can recheck running some game in wine.
Bad news: I've been running vkQuake many times yesterday during the night in hope I can reproduce this, and it didn't reproduce anymore...
Could you check if fullscreen is enabled in wine vkquake's settings? It can run in "kind of fullscreen" when setting its resolution to screen native without having the fullscreen option actually enabled. Then it doesn't freeze when alt + tabbing.
I always use wine-tkg with the Proton fullscreen hack enabled: https://github.com/Tk-Glitch/PKGBUILDS/tree/master/wine-tkg-git However, I've just been able to reproduce the vkquake freeze with vanilla wine from Arch repo, as long as the fullscreen option is enabled.
I have enabled fullscreen in vkQuake from first launch. Apparently vkQuake sets the resolution every time I Alt-Tab, even if it has the same resolution as desktop.
Maybe Heroes of the Storm reproduces more often. Can you tell me if HotS also sets the resolution when Alt-Tabbing?
I suspect this is some weird wine behavior, as I have only one resolution with one refreshrate available via xrandr, and it tries some senseless switching regardless. The Proton fullscreen hack prevents this.
This means... the issue only occurs when an application tries changing modelines? I'll try checking if this can be reproduced with a resolution-changing Linux application in a few hours (when I come back to my computer).
It seems that this is well possible, as HotS doesn't freeze when I set it to borderless mode instead of exclusive, which on Windows means that it can't change modeline.
There is a free demo for Euro Truck Simulator 2: https://store.steampowered.com/app/227300/Euro_Truck_Simulator_2/ It offers Linux support, but Proton can be activated in its Steam game settings. It seems to trigger the issue more reliably than vkquake.
Does it do modesetting on Alt-Tab as well?
I can't really tell, as also Valve's official Proton uses its fullscreen hack and there is no variable to turn it off at runtime. I wanted to provide an example which hopefully is more reproducible than vkquake. Though I think lots of, if not all, games playable via Proton should trigger the freeze.
Despite the fullscreen hack, this issue affects Proton games, too. The issue is with exclusive fullscreen only as far as I can tell. Borderless windowed fullscreen does not have any such problems.
The fullscreen hack of Proton just redirects any game through an additional drawing surface, and instead of switching the native resolution, it will stretch the surface to your native desktop resolution. That way, games will no longer switch your Xorg resolution which could otherwise lead to all sorts of funny effects (like KDE Plasma reordering your taskbar applets and orientation, or the resolution not being reset to native when quitting the game, leaving you with a funny 800x600 resultion on a Hi DPI 4k monitor). The downside is: Stretching costs a bit of performance. When native and game resolution are identical, the fshack operates in pass-thru mode with no performance hit.
I've contributed a patch to Proton fshack which bypasses kwin compositing when the game indicates fullscreen mode. It works for borderless windowed fullscreen and exclusive fullscreen, non-fullscreen games won't bypass compositing so we don't impair rendering of desktop effects. This already reduced stuttering a lot for fullscreen games. The patch has been merged into Proton 3.16 and 4.2, not sure about older versions.
Another problem with games freezing is that they may go into some sort of "tiny render surface" mode, usually icon-sized (e.g., 32x32px), or even smaller. The rest of the game thus simply stays black or seemingly froze (because it no longer renders to the full surface). This can be fixed by a patch series by Zeb which fixes iconize/minimize/maximize in Wine. I think there's work currently going on in merging this to Proton. I successfully used that in my own Proton branch to fix the few games still having the freezing problem.
So we basically seem to have two problems resulting in seemingly freezing:
Thanks for your explanations. Though I just wanna mention again that the "seemingly freeze" issue after alt + tabbing is only there when
Wine fullscreen applications and the Proton FS hack work totally fine here in general. E.g. I can use upstream KWin as a window manager (not compositor) and Compton as a compositor with auto unredirect, then I can alt + tab as much as I want without issues.
Maybe I should take note: My observations were from using upstream kwin some months ago, most issues seem to be fixed. I'm currently considering using kwin-lowlatency but didn't make the switch yet.
Upstream KWin shows the issue as well with window thumbnailing enabled for all windows: https://bugs.kde.org/show_bug.cgi?id=415286 So I should check out this option the next time I try this fork.
It really is that option. So it has nothing to do with this fork, closing.
It seems to affect any Wine fullscreen window and is not related to unredirect: Start any game (e.g. vkquake or Heroes of the Storm) in Wine in fullscreen mode. Then use alt + tab to switch to the desktop and use it again to switch back into the game. Result: The game's window stays black and freezes (while audio continues running), its process has to be killed to make the system usable again. This does not happen with native Linux games.
The issue does not occur when applications are allowed to suspend KWin, so the checkbox for it should be unticked when trying to reproduce.
Log file for vkquake in Wine (not sure if it contains the required information): kwin.log