tildearrow / kwin-lowlatency

archived - X11 full-screen unredirection and lots'a settings for KWin
373 stars 10 forks source link

alt + tabbing back into Wine fullscreen windows makes them freeze #25

Closed aufkrawall closed 4 years ago

aufkrawall commented 5 years ago

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

tildearrow commented 5 years ago

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

ZaWertun commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Does it do modesetting on Alt-Tab as well?

aufkrawall commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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