SUMMARY KWin compositing makes Proton fullscreen games freeze with a black window after alt + tabing out of the game window and back into it. STEPS TO REPRODUCE 1. Keep compositing enabled and start a game via Steam Proton, e.g. Dishonored 2 with Proton 4.11-10. 2. Switch to another window via alt + tab. 3. Switch back to the game window. OBSERVED RESULT It just stays black and the process has to be killed. EXPECTED RESULT The game window should continue unaffected by the focus switch. This is the case when KWin compositing is manually disabled before the game is started. It doesn't matter if "Allow applications to block compositing" is enabled or not. It also breaks when manually turning compositing on again after the game was minimized, as at seems to receive focus in that moment. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux 5.4.3 (available in About System) KDE Plasma Version: recent / self-compiled git-master as dependency for kwin-git KDE Frameworks Version: recent / self-compiled git-master kwin-git Qt Version: 5.13.2 GPU: RX 570 with recent mesa 20 git-master ADDITIONAL INFORMATION Happens also on Wayland. Doesn't happen with other compositors. Might be related to the Proton fullscreen hack that prevents unnecessary modeline switches and provides upscaling resolutions to games. It can't be disabled.
>This is the case when KWin compositing is manually disabled before the game is started. So if compositing is off, and stays off the game still breaks?
(In reply to David Edmundson from comment #1) > So if compositing is off, and stays off the game still breaks? Then it doesn't break. :)
Info was provided.
Ok, so it only breaks if compositing toggles. That will almost certainly be the fault of the game not handling that well. You only see it in kwin as that's one of the few window managers that support toggling. Please report to the game devs / proton.
I think you misunderstood: It's unrelated to toggling compositing. It also breaks as long as compositing is just enabled, compositing is never toggled during the process.
(In reply to tempel.julian from comment #5) > I think you misunderstood: It's unrelated to toggling compositing. It also > breaks as long as compositing is just enabled, compositing is never toggled > during the process. Normally on games composition is auto-toggled (as you know instead of unredirect) so you are sure composition does not get toggled off automatically? Anyway I will investigate a bit more later today. I don't think it's necessarily the game's fault.
(In reply to Roman Gilg from comment #6) > Normally on games composition is auto-toggled (as you know instead of > unredirect) so you are sure composition does not get toggled off > automatically? That's why I checked whether "Allow applications to block compositing" makes a difference. :) I think it should never toggle with the option turned off? Even though it would be really unfortunate if toggling would be additionally problematic, as I really would like to have the option to use compositing when minimizing a game for a longer period of time (e.g. game's matchmaking taking very long etc.). There unfortunately is a bit more oddness involved though: Not every game inside Proton necessarily triggers the issue, even though if they all use DXVK/D9VK. However, some games like Dishonored 2 always trigger it.
Found the cause of the issue: It sits in front of my PC. The issue is caused by setting KWin to always keep window thumbnails, not just for shown windows. At this occasion, I also found out that the Proton fullscreen hack also automatically tells KWin to resume compositing when minimizing a game. Though e.g. the native Linux port of Shadow of the Tomb Raider by Feral doesn't do this.
(In reply to tempel.julian from comment #8) > Found the cause of the issue: It sits in front of my PC. > The issue is caused by setting KWin to always keep window thumbnails, not > just for shown windows. Good find. It's still an issue but this restricts the search area and it might make sense to ignore the issue since it is a rather special case. But does this issue also occur without the recent compositing overhaul? If no, we should try to fix the regression for sure. > At this occasion, I also found out that the Proton fullscreen hack also > automatically tells KWin to resume compositing when minimizing a game. > Though e.g. the native Linux port of Shadow of the Tomb Raider by Feral > doesn't do this. Also interesting. Didn't know that Proton does this automatically but other (major) players like Feral don't.
(In reply to Roman Gilg from comment #9) > > At this occasion, I also found out that the Proton fullscreen hack also > > automatically tells KWin to resume compositing when minimizing a game. > > Though e.g. the native Linux port of Shadow of the Tomb Raider by Feral > > doesn't do this. > > Also interesting. Didn't know that Proton does this automatically but other > (major) players like Feral don't. This patch was actually contributed by me: If the wine surface switches to full screen resolution, it will set the "bypass compositor" hint via a X11 protocol flag. This reduced game stuttering a lot for me (a real lot). The DXVK author jumped in and confirmed my patch: The kwin compositor (and compositors in general) are a potential source of stutters in games. I think this is mostly due to compositors putting their own vsync routine and the game engine doesn't know of this. May work fine sometimes (some reports even say games are tear-free then), but most other times it breaks smoothness. I haven't seen the freezing problem in a long time now. But actually seeing the relation to window thumbnails here: Yes, I turned off keeping current thumbnails for all windows also a while ago because it seems to improve game performance. So I tend to confirm that kwin window thumbnails may be the issue. BTW: I was also able to freeze native Linux games that way when run under kwin but that's a few years back.
Thanks for your improvements to the fullscreen hack, it really is a game changer for me! Though I think Proton might be the positive exception here. With unredirect we wouldn't need to worry about whether an application is willing to cooperate or not. In the kwin-lowlatency fork there also is a window rule option to keep compositing enabled for single applications that would work better that way (e.g. browsers).
Forgot to add: The Proton fullscreen application also freezes with KWin's default settings when executing "kwin_x11 --replace" while the application is running.
I tried it out now with https://phabricator.kde.org/D26216 being applied on top of master and alt-tabbing in and out of Dishonored 2 worked without problems for me in the tutorial starting area. System was an AMD RX 5700 XT, MESA (close to) master, Linux kernel 5.4.6. This was independent of me enabling that apps can block compositing or switching on/off compositing mid-game. Could you test if there are still problems for you with the above patch applied?
(In reply to tempel.julian from comment #12) > Forgot to add: The Proton fullscreen application also freezes with KWin's > default settings when executing "kwin_x11 --replace" while the application > is running. This in contrast is still happening to me. But taking away the compositor while the game is running is quite drastic and handling that is probably not been done correctly in Proton in this case (and I don't think it's worth for them to look into fixing that). On another note: I didn't notice any performance difference between having the compositor block compositing and with full compositing still going on while in-game, what would point to the compositing rework being done right. Can you confirm?
With the default setting of keeping window thumbnails only for shown windows, the issue completely disappeared for me. Thanks to your rework and Proton's intelligent use of compositor suspend, I can finally really enjoy KWin compositing for the first time. With the patch you provided, the game still freezes with a black window when setting it to "always" and then alt + tabbing, so it has not changed. The same btw. happens also on Wayland, but not just with Plasma, also with Sway. So the issue might indeed lie in the Proton fullscreen hack, and not the compositors. For some reason it works with Gnome though. Workarounds are to switch to borderless mode in the Windows games or use a Wine virtual desktop. Regarding performance: In Heroes of the Storm, it's 154fps without compositor vs. 147fps with kwin-git. So it's a ~4.5% loss, which I think is fine. Windows DWM performs very similarly. I think KWin Wayland and Sway are a tiny bit faster though. But I personally really disdain compositor vsync in games in general, I can't stand the added input latency and uneven frame output due to repeated/discarded frames vs. direct tearing. ;)
> The issue is caused by setting KWin to always keep window thumbnails, not just for shown windows. This problem is still present, and on wayland this setting is missing from the compositor settings so the solution might not be immediately obvious. However, switching to an X session, changing this setting, and then switching back to wayland does actually fix the problem. So somehow even though the setting is not show in wayland it does actually have an effect on wayland sessions (possibly because the proton games are running in Xwayland?). This might be a reason to unhide the setting in wayland sessions (See also Bug 446709)