SUMMARY After performing certain actions, compositor just renders a black frame and turns system unusable. This was introduced in the wake of current KWin overhaul. STEPS TO REPRODUCE Case 1: 1. Have compositing enabled and change compositor shadow or animation settings. Case 2: 1. Have compositing enabled and start a Vulkan fullscreen game. 2. Disable compositing while in the game via shift + alt + f12 3. Minimize the game and turn compositing on again. OBSERVED RESULT Compositing turns completely black and can sometimes not be deactivated via hotkey. If it still can be restarted, it still shows just a black top layer and the session needs to be restarted to make compositing work again. EXPECTED RESULT Compositing should alway turn on and off gracefully. 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 Continuation from: https://bugs.kde.org/show_bug.cgi?id=344433
* Which Vulkan game specifically? * Does the issue persist when you start KWin with the envvar KWIN_USE_INTEL_SWAP_EVENT set to 0, i.e.: > $ KWIN_USE_INTEL_SWAP_EVENT=0 kwin_x11 --replace
It seems to apply to any fullscreen application (that triggers page flipping?), I could also confirm with CS:GO OpenGL. KWIN_USE_INTEL_SWAP_EVENT=0 makes the issue disappear, though it makes everything stutter again.
Created attachment 124538 [details] poc patch I can reproduce on Intel. The issue lies in the swap event not being registered correctly after compositing went down while a page flip is ongoing (probability for that high when often changing content on the screen like a game). Please compile KWin with the attached proof-of-concept patch and see if that solves the issues for you.
I can confirm that your patch fixes the issue for me. Finally I'll be able to recommend Plasma without turning off KWin compositing, thanks for your efforts! :) Though I really wished you guys would reconsider implementing fullscreen unredirect. I've been using it for two years inside Plasma via Compton/Picom and it works just totally reliably, while it is much more comfortable than KWin's suspend compositing feature. It also seems to work fine in Gnome.
(In reply to tempel.julian from comment #4) > I can confirm that your patch fixes the issue for me. > Finally I'll be able to recommend Plasma without turning off KWin > compositing, thanks for your efforts! :) Thanks for testing! Early feedback like yours is super helpful. Would be great of course if you could stay on master in the future to continue with feedback if something breaks and by that shield inexperienced users from bugs they would not able to recover from on their own. :) I need to look into the code some more for a final patch. The above one was just done rather quickly to test the assumption. > Though I really wished you guys would reconsider implementing fullscreen > unredirect. I've been using it for two years inside Plasma via Compton/Picom > and it works just totally reliably, while it is much more comfortable than > KWin's suspend compositing feature. It also seems to work fine in Gnome. I understand your sentiment but from my perspective I would need to dig into how exactly unredirect is supposed to be implemented and even then to my knowledge there are certain structural constraints of unredirect that make it a subpar experience. On the other side we have the Wayland session where in the future we will be able to do an optimal direct scanout of client buffers and on the other side still have lots of other things to do to make it work on every user install without issues. So I would like our devs to concentrate on improving that rather.
(In reply to Roman Gilg from comment #5) > Thanks for testing! Early feedback like yours is super helpful. Would be > great of course if you could stay on master in the future to continue with > feedback if something breaks and by that shield inexperienced users from > bugs they would not able to recover from on their own. :) I think it would be helpful if it was less hassle due to a lot of git master dependencies. It's really painful to compile kwin-git on Arch, while e.g. gnome-shell-git or xfwm4-git are easy to compile. There are so many KDE packages, I'd suppose that there is a lot of potential for combining them into fewer. > I need to look into the code some more for a final patch. The above one was > just done rather quickly to test the assumption. I'll stick with the git packages until 5.18 is released and report back in case of oddities, no big deal. > I understand your sentiment but from my perspective I would need to dig into > how exactly unredirect is supposed to be implemented and even then to my > knowledge there are certain structural constraints of unredirect that make > it a subpar experience. > > On the other side we have the Wayland session where in the future we will be > able to do an optimal direct scanout of client buffers and on the other side > still have lots of other things to do to make it work on every user install > without issues. So I would like our devs to concentrate on improving that > rather. I totally understand your situation. Perhaps suspend of compositing could be improved instead? Maybe my thinking is too simple, but wouldn't it work if KWin polled e.g. every 0.5s if there was a fullscreen window covering everything else, and in case it isn't (e.g. after alt + tabbing out of a game), resume compositing (and vice versa)? The result basically should be the same of unredirecting, without the need to actually implement it. I think I also found a bug of KWin compositing in conjunction with Proton fullscreen hack patch for Wine, where the fullscreen window just stays black after alt + tabbing out of it and back into it. This does not happen when I disable compositing before. Gonna open a new report for it.
Bug report for the Proton issue: https://bugs.kde.org/show_bug.cgi?id=415286
I have cleaned up / reformulated the patch. Could you test this patch one more time if it works for you like the previous poc one? Thanks! https://phabricator.kde.org/D26090
(In reply to Roman Gilg from comment #8) > I have cleaned up / reformulated the patch. Could you test this patch one > more time if it works for you like the previous poc one? Thanks! > > https://phabricator.kde.org/D26090 Issue is still gone, afaict till now.
Git commit ba2c0324d2ef21a5c42ec182e851a435180b51ac by Roman Gilg. Committed on 23/12/2019 at 22:55. Pushed by romangilg into branch 'master'. Reset buffer swap state on stop Summary: When the compositor is stopped there might still be a buffer swap ongoing, in particular when a client blocks compositing on X11. Depending on the backend the next buffer swap event might be handled in bufferSwapComplete (Wayland) or not be handled (X11 GLX, since a new GLX window will be created while the swap event is sent for the old one). With this patch the buffer swap state is reset on stop such that on later start no outdated data might create errors and instead a new repaint can be triggered with updated data. Test Plan: Manually on X11 and Wayland. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D26090 M +5 -6 composite.cpp https://commits.kde.org/kwin/ba2c0324d2ef21a5c42ec182e851a435180b51ac