When going fullscreen from a maximized window (vlc, chromium or firefox playing video and could be other examples I did not test) the screen goes definitely black (until depress of the escape key exiting fullscreen) This is a regression from 5.21.5 This impacts (at least) nvidia-drivers + x11 backend + opengl 3.1 + compositing enabled users. The bug has been reported (and acknowledged) on the KDE Bug tracking system : https://bugs.kde.org/show_bug.cgi?id=441904 Being in there reported as a regression from 5.22.4 I followed the advice given by Nate Graham in comment N 4 of the above mentioned bug. I did the same as Mikael Hirki reported in comment N 12 and came to the same conclusion : Reverting this commit ( https://invent.kde.org/plasma/kwin/-/commit/f432ba7821cea2302d040c8bfc7e3cb7d9540874 ) actually fixes the issue. Nota : While I cannot experience any sort of undesirable side effect after reverting that patch, be anyhow aware that Vlad Zahorodnii (the author of the commit that needs to be reverted) does not think it's the right thing to do, as one can read in comment N 13 Anyway, works for me. Reproducible: Always
Created attachment 741450 [details, diff] Patch fixing the regression observed with kwin-5.22.5 when going fullscreen This patch reverts https://invent.kde.org/plasma/kwin/-/commit/f432ba7821cea2302d040c8bfc7e3cb7d9540874 (Avoid discarding previous pixmap)
Odd, I can't seem to reproduce (1070 card, single monitor, x11, kwin-5.22.5 compositor enabled, maximized window, go full screen in VLC/firefox and it's just normal) -- but I'm likely missing something, haven't tried that much. For the record, what drivers are you using? 470.74 in my case, haven't tried older drivers. I don't maintain kwin but bug caught my interest because I thought this may be about a regression in 470.74 with fullscreen and gsync resulting in a black screen, but looking at the bug it's something else and people are reporting various driver versions.
(In reply to Ionen Wolkens from comment #2) > For the record, what drivers are you using? Gentoo-unsupported 340.108 But indeed, I do not think this bug is nvidia-driver version dependent since, as you noticed, contributors on that kde bug are running many different versions. Interesting indeed that you cannot reproduce this bug. Do you get whatever plasma pannel ? Which visibility did you set : Always visible / Auto-Hide / Windows can cover / Windows go below ? If not already set to Windows can cover, could you please retest going fullscreen on whatever app with this particular setting for the pannel ? And BTW, make sure you did not select XRender as compositor rendering backend because that bug does not occur in this case.
(In reply to Eric F. GARIOUD from comment #3) > If not already set to Windows can cover, could you please retest going > fullscreen on whatever app with this particular setting for the pannel ? Hadn't set anything beside OpenGL 3.1 given you mentioned it (over the 2.0 default). This is out-of-the-box defaults. VLC was covering the panel either way, and I'm still not able to reproduce with VLC, probably some other setting missing. /But/ I did reproduce with firefox+youtube when setting panel to windows can cover now. So, x11 + windows-can-cover-panel + maximized-window + going-fullscreen + opengl compositor + nvidia (sure is rather specific, but it's a thing).
(In reply to Ionen Wolkens from comment #4) > So, x11 + windows-can-cover-panel + maximized-window + going-fullscreen + > opengl compositor + nvidia (sure is rather specific, but it's a thing). windows-can-cover-panel is only one of the possible conditions I can be sure about. There can indeed be many others such as no panel at all (which is often the case on a secondary monitor), not to mention possible latte-docks and display animations influence. But I get very limited means (und Wille zur Macht) for testing them all. ;-)
I would wait for upstream to come up with a real fix.
The bug mentioned by Andreas as See Also (427920) is IMHO not related to the bug I reported here. The bug I reported here is a regression towards 5.21.5 (previous gentoo-stable) It can actually be fixed by either downgrading to 5.22.4 or reverting a commit made in between 5.22.4 and 5.22.5 When, AFAIU, KDE Bug 427920 was reported against 5.20.0
(In reply to Eric F. GARIOUD from comment #7) > The bug mentioned by Andreas as See Also (427920) is IMHO not related to the > bug I reported here. The symptoms are the same. As downstream best we can do is track relevant upstream bugs of the symptoms you are seeing.
Fair enough! I won't argue with you as the work you achieve on these plasma-* packages actually saves me a considerable amount of time. Therefore, thanks instead of arguments. Of course, standing at the very end of the stream and having even more limited means, I like to keep things SS : Whenever a commit breaks my system, I revert it and leave to others' wisdom the invention of better solutions that would incidentally fix other possibly similar bugs. And... at the end of the day... what is **this** bug (814992) all about ? A single rather simple conditional expression as part of a single rather simple .qml ? which, in addition, as Ionen's rightly wrote, would impact only "rather specific" environments ? I'm sure you get far more important problems to solve under your elbow. ;-)
(In reply to Eric F. GARIOUD from comment #9) > Fair enough! > I won't argue with you as the work you achieve on these plasma-* packages > actually saves me a considerable amount of time. > Therefore, thanks instead of arguments. > > Of course, standing at the very end of the stream and having even more > limited means, I like to keep things SS : Whenever a commit breaks my > system, I revert it and leave to others' wisdom the invention of better > solutions that would incidentally fix other possibly similar bugs. > > And... at the end of the day... what is **this** bug (814992) all about ? A > single rather simple conditional expression as part of a single rather > simple .qml ? which, in addition, as Ionen's rightly wrote, would impact > only "rather specific" environments ? > I'm sure you get far more important problems to solve under your elbow. ;-) :s/qml/cpp/
Upstream fix? https://invent.kde.org/plasma/kwin/-/commit/52c9dbb487f4ac98017b83a1deee912546cbff5f
(In reply to Andreas Sturmlechner from comment #11) > Upstream fix? > > https://invent.kde.org/plasma/kwin/-/commit/ > 52c9dbb487f4ac98017b83a1deee912546cbff5f Ha! That is precisely the question I had asked : https://bugs.kde.org/show_bug.cgi?id=441904#c24 ;-) Being acknowledged that I am definitely not familiar with these KWayland thingies (and do not even want to understand why my kwin needs parts from kde-plasma/kwayland-server :-( ) : I am not convinced that the commit you mention is meant to stand alone. I would even tend to believe that, for coherency sake, one should also consider https://invent.kde.org/plasma/kwin/-/commit/8ac93a59ffb1a09bf6df46c7012bea7910e6b883 as being part of the "real fix". BTW, I tested gentoo's ~kwin-5.23.0 (which contains both of the abovementioned commits) and **this** bug (814992) appears resolved fixed. I did not try backporting them to my 5.22.5 considering that my problem was actually Q&D solved by the revert of a very simple commit when the so called "real" fix reworks too many parts well above my competence. As far as I feel concerned, I'll then be happy to wait for the "real" fix to automagically happen in whatever future kwin-5.23 stable. Of course, in the case you would want the "real" fix to happen sooner (on current kwin-5.22.5) and think it could be of some help for you, I am ready to test the backports on my system. (But won't investigate if whatever goes wrong).
I can confirm that this glitch no longer occur after upgrade of kde-plasma/* to 5.23.4. Thanks.
