SUMMARY When updating to kwin 5.15.90, certain windows like Chromium, Atom, Godot Engine and other windows that are 3D accelerated stop refreshing entirely. The window needs to force a refresh by doing something like switching desktops, resizing or minimizing-then-maximizing the window. Shutting kwin_x11 down also makes the window refresh again, normally. Going back to 5.15.5 makes everything work as normal as well. Whenever it happens is not entirely clear but it seems to have something to do with windows taking focus, for example Atom asking for github credentials, or Godot starting a project. Switching windows can also trigger it but not always, it's not entirely reliable, what makes it more disruptive because it seems it's fixed but then it strikes. STEPS TO REPRODUCE 1. Open a 3D accelerated window (Chromium, Godot, Discord, possibly others) 2. Switch focus away or spawn other windows. 3. Eventually display will stop refreshing. OBSERVED RESULT Window will stop updating. It's still working (trying to scroll will scroll, sound is emitted, popups appear, but image is completely frozen for that window. EXPECTED RESULT Window should just update normally. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Ubuntu 19.04 amd64 (available in About System) KDE Plasma Version: 5.15.90 KDE Frameworks Version: 5.15.90 Qt Version: 5.12.2 ADDITIONAL INFORMATION Video card: GeForce GT 710. OpenGL version: 4.6.0 NVIDIA 430.14 GL kernel module: nvidia Running non-composited kwin-x11. Reverting to 5.15.5 stops the issue, this is ONLY on 5.15.90. This only seems to happen in 3D accelerated windows. Doing something like disabling 3D acceleration on Chromium or Discord makes it not be affected by this bug anymore. Other applications like konsole, krusader, quiteRSS and such seem to never freeze. If enabling info display in nvidia-settings, only the windows that have a display are affected, so I'm fairly sure it only affects 3D windows. I run my desktop with compositing disabled, but enabling it didn't seem to make a difference, it still freezes windows at random. Note that enabling or disabling compositing will force a redraw, but doesn't prevent windows from freezing randomly again. I tried OpenGL 2.0, 3.0 and XRender backends, none of them fix the issue. I also tried messing with vsync in both compositing and nvidia settings. Nothing I tried seemed to stop the issue from happening at inconvenient times. Because of this, it's extremely disruptive of any workflow. Specially when something might have changed the state of the window and resulting in clicking into wherever the mouse pointer happens to land in a window that seems fine but is actually not refreshing. Please help.
Another note, it seems that spawning another accelerated window also has a high rate of making other accelerated windows freeze.
I'm really sorry I seem to be unable to post comments. I meant to add to the last comment in that that only seems to happen when the new accelerated window takes the space another accelerated window on screen. I divide my desktop in a very large window (browser, editing tools like Krita or Blender, etc) and two windows at a side (usually a media player and Discord). Since Discord is at a side, it rarely freezes compared to Chromium or Atom.
Can you post output of `env` when windows are frozen?
Created attachment 120210 [details] Output of env Gladly.
It seems that 5.16.0 does not have the issue anymore. I'm waiting just a bit before closing the issue, but so far it does seem fine.
Seems to only happen with Discord now. When opening something like Virtualbox or Atom it might, but not always, freeze ,requiring a refresh. Or disabling hardware acceleration. However, other apps that gave me trouble earlier seem to not be having issues anymore, so the severity of this bug seems to be much lower now. Since it's still a thing that happens, it'd be better if someone else decides whether it's worth investigating or close the issue. If any data is needed for debugging ask me. Note that the update to kwin 5.16.0 didn't involve any changes in my hardware, system config or drivers, outside from the update itself and assorted newer KDE packages.
Actually, scratch those last two comments. It seems to happen less often, but it still happens when launching 3D accelerated windows, like opening a project in Godot. That means every time I run a project the editor I'm using to edit the code of that project will freeze, alongside Godot itself, Discord, and Chromium. Although Chromium seems to freeze the least, where it used to freeze the most in the previous package when I reported this. That difference made me think the problem was solved, but apparently it just changed behavior slightly. Since my distribution has already taken 5.16.0 packages in the standard channel, I cannot roll back to a previous version easily anymore. What are my options here? I really cannot do any work like this.
Might be related to bug 406180. Using the XRender backend instead of an OpenGL backend in KWin could workaround this issue until it is fixed.
I have composition disabled though. Would that help even if I'm using it this way?
If you see this bug with compositing disabled, then it isn't a KWin bug. Without a compositor, the applications talk directly to the X11 server.
But it only happens under kwin and while kwin is active. I confirmed it didn't happen with a previous kwin version and it also doesn't happen with other window managers.
Note that by "compositing" I mean "desktop effects", I find my system faster when they are disabled. (is...is there a way to edit comments? I apologize, this is terrible, but I can't seem to find a way)
Setting backend to XRender made no change.
XRender still is compositing. Please test with disabled effects, you can toggle them with Shift+Alt+F12.
Happens both ways. Although as mentioned earlier switching it on/off does refresh and unfreeze the windows, but doesn't prevent them from freezing again in either mode.
Then see comment #10.
Please listen to what I am saying. How can it not be a kwin bug when it explicitly depends on the version of kwin? Why does it happen with the current version of kwin ONLY but not the previous version of kwin? I have even tried to update other packages while holding back kwin in particular and the freezing only, ONLY happens when kwin is updated past 5.15.5. Why do the windows magically unfreeze themselves when shutting kwin down, or forcing kwin to refresh? Why does it not happen with any other window manager, composited or not? Why is kwin so ubiquitous in this whole mess when it has nothing to do with anything, despite everything I'm reporting? You are ignoring my previous reports entirely. I DID mention the problem happened whether composition is active or not, I only keep it disabled by default because it adds extra overhead. I am not an English speaker, thank you for your patience. You have not asked for a single bit of data to actually help, and only tried to dismiss it deflecting the blame or something. This is why I and many others never bother reporting KDE bugs. What is with that attitude? I know the user is implied to be an idiot, but don't give me that, I am not linux-illiterate, I know enough about my system to know the problem is linked to kwin because it's the only component that causes the problem when updated. You think I didn't bother testing first? I did more testing than you did! I only got asked for my ENVIRONMENT that cannot possibly contain anything of value for this situation, other than the data I already included in the report. Alright, we are at a standstill here, because I'm unable to do MY work thanks to this little issue that, if you get your way, will remain unresolved until it starts affecting more people and then "whoops we didn't get anyone reporting it! report bugs!" Am I supposed to return to IceWM in 2019 or what? You guys need a code of conduct. Your behavior is unacceptable and reflects on the entire project by proxy. I wouldn't DARE dismiss my users when they report bugs like this. Just because I'm not programming on the same project as you doesn't make me less of a programmer. Even if the bug is somehow not tied to kwin it's still a regression that wasn't there one version ago. If you want to turn your back and act like nothing is wrong, that's on you. Don't ask for people to report bugs if you are going to dismiss them even when they already said three times IT HAPPENS WHEN COMPOSITING IS ENABLED TOO.
And you know, if it's ACTUALLY not a Kwin bug, then relocate it to wherever it's pertinent instead of rudely closing it as not a thing.
> when they already said three times IT HAPPENS WHEN COMPOSITING IS ENABLED TOO You didn't understand. If the bug happens when compositing is DISABLED, it cannot be a KWin bug. The window manager doesn't decide when and what to draw on the screen if the compositor is disabled. > then relocate it to wherever it's pertinent instead of rudely closing it as not a thing. Comment #10 says the issue is between the application (and with that also the libraries and toolkits that it uses), and the X server (and with that also the drivers that it uses). With compositing disabled, KWin doesn't even know when and what the application wants to render. It is simply not involved. I cannot know which of those components is responsible. A good test would be to swap between NVIDIA binary drivers and Mesa drivers (both nouveau and swrast) for OpenGL. They have their share of issues, but it could help to understand the issue.
Created attachment 120929 [details] Screenshot 1 Sadly I cannot afford to run other drivers. My current work needs the nvidia binary drivers, things don't render well with the free ones. Something else which is interesting is that thumbnails are detecting changes. (I have "keep thumbnails" as always. Although, from what you said, shouldn't that feature not work at all with compositing disabled?) Look at the included screenshot, it's a bit hard to tell if you don't use Godot, but I managed to get the Godot window in the back frozen when launching the project. The game had an error, and it should be showing the debugger screen below (ignore the screen in front, since the project crashed it's all weird and "hall of mirrors"-y, that's normal, I didn't want to move it out of the way to not disturb the crime scene). If you look at the thumbnail from the task manager, it's showing the current state of the window, with an error in red, while the window itself is entirely frozen even when it's changing actively (and I think it even sets an alert state). So, the big question is, if the culprit is not kwin, what other component of KDE that has changed from 5.15.5 to 5.16.0 could be causing this. Let me reiterate that rolling back does fix it. Anyway, things I know: -Enabling and disabling "keep window thumbnails". No change. -Enabling and disabling compositing in all 3 backends. No change. -Disabling vsync with flipping enabled/disabled in nvidia-settings. No change. -Reverting to 5.15.5. The issue doesn't happen again. -Downgrading nvidia drivers. No change. -Upgrading nvidia drivers. No change. -Reverting to the nvidia drivers I had to begin with. No change. -Disabling hardware acceleration in Discord and Chromium. They aren't affected anymore, but perform a bit worse. This is not viable for Atom, it's too slow to use otherwise. Downright impossible to do with Godot or Blender as it's always accelerated. -Upgrading plasma but not kwin. The issue doesn't happen. -Killing kwin makes windows update again. The problem doesn't happen with no window manager. -Switching desktops, minimizing and restoring the window, resizing the window, switching compositor state will unfreeze the windows, but they will freeze again eventually. -Ubuntu default desktop cannot reproduce the issue (hardly a solution, I consider it unusable and can't waste time tinkering with it). -Tried installing other X11 window managers like icewm or fvwm. Issue doesn't happen either. -Windows exclusively freeze when a new accelerated window is created. If no windows are created at all, the issue won't trigger ever. -Switching back and forth between windows, even quickly, does not seem to trigger it either. Only window creation as far as I can tell. Additional notes: -I use a single screen setup, very basic. -The only non-default plasmoid I have is Latte-Dock. -No exotic or unusual hardware, just keyboard, mouse and a wacom tablet, none give issues in KDE or other desktops/apps. -KDE install is pretty much default. The only unmanaged KDE tool is Krusader which I compile from git. And Krita from their PPA (which I installed after creating this issue). No other additional changes to it. -No changes to kernel or any fancy patches. No unusual video hacks or anything either other than the nvidia-settings slider set to max performance. -No unusual cpu or video load, video glitching or anything strange when windows freeze, they just remain static even if windows move in front of them (unlike the execution aborted Godot window in the attachment which has a "hall of mirrors" thing to it) -No settings at user level that could affect things. .profile just contains various program options, no preload hacks or anything. -Most "exotic" app in the whole system is fcitx for language support. Shouldn't be a factor, but just in case.