alt + tabbing back into Wine fullscreen windows makes them freeze about kwin-lowlatency

[tildearrow]

Issue confirmed and reproduced on this Intel laptop. Now to fix it...

[ZaWertun]

Can't reproduce the bug with nvidia.
I'm running some windows games with steam & proton.
I can recheck running some game in wine.

[tildearrow]

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...

[aufkrawall]

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.

[tildearrow]

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?

[aufkrawall]

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.

[tildearrow]

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).

[aufkrawall]

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.

[aufkrawall]

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.

[tildearrow]

Does it do modesetting on Alt-Tab as well?

[aufkrawall]

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.

[kakra]

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:

1. Exclusive vs borderless windowed full screen mode (can be fixed by switching to borderless windowed mode): The game freezes (sound stops, Xorg client has to be sigkilled), there's probably some bug left in the graphics pipeline as usually also the graphics driver freezes or crashes, this can also happen when resizing the game window. I think this happens when the game should react to a Vulkan signal to recreate the swapchain, and that's not properly propagated to the game.
2. Wine restores the game rendering surface to the wrong size/position upon restore from minimize, resulting in rendering to the wrong surface: The game still renders and runs but your screen isn't updated (or only some tiny area of it).

[aufkrawall]

Thanks for your explanations. Though I just wanna mention again that the "seemingly freeze" issue after alt + tabbing is only there when

1. kwin-lowlatency is used instead of upstream kwin
2. Compositing is enabled before starting the game (no matter if the game's window later gets unredirected or not)

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.

[kakra]

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.

[aufkrawall]

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.

[aufkrawall]

It really is that option. So it has nothing to do with this fork, closing.