KDE starts beautifully, then eventually decays to visible un-usability ... *** After a reboot KDE/Plasma runs beautifully. However after a certain amount of time, usually 3-5 days, windows "appear" to be (re)painted completely black, or are not painted at all (it's hard to tell since it happens so fast). (In X, everything is a window of some type; menus, window contents (I haven't seen decorations do this behaviour yet, but have seen it with all components of the task bar.)) When this happens the following are sometimes TRUE: 1. when resizing is available, sometimes resizing the window provides visibility to its painted contents (this is hit or miss and the contents will flash correctly or not); 2. sometimes iconifing the window, or closing and re-opening the window will allow visibility to its painted contents; and likewise dismissing and reengaging a menu (window) will allow the menu to be visibility painted. 3. This happens across all applications, even programs written in basic X (e.g. /usr/bin/xv) to wildly complex programs like firefox and everything in between. My workspace consists of 4 virtual desktops and switching to another desktop and back has no effect on windows painted as "black." > I really don't know if the window is "properly" rendered then over-painted as the process is too quick for the eye ...? When it happens, I have to exit the workspace and init S/control-D to reload everything back to "clean the slate," but this is temporary and eventually the cycle repeats. I had hoped 5.27 would have cleaned this up, but it's still there. *** STEPS TO REPRODUCE: 1. Run the workspace for several days including cycles of screen locking, etc. 2. Use the workspace normally (I run several konsoles, firefox, thunderbird, and a few other applications on and off). OBSERVED RESULT Eventually, some windows will be painted as "black." Kinda happens infrequently at first, then becomes more and more common as time progresses. EXPECTED RESULT I'm used to uptimes measured in the years and expect no less from my workspace. I upgraded from Fedora 34 KDE (exactly the same hardware) and have never seen this happen. HACKS TRIED: - most of the kernels released under Fedora 37 - NVIDIA-Linux-x86_64-515.76.run, NVIDIA-Linux-x86_64-520.56.06.run, NVIDIA-Linux-x86_64-525.60.11.run, and NVIDIA-Linux-x86_64-525.89.02.run. - I did NOT think to disable desktop effects (I will if it happens again) to see what happens. SOFTWARE/OS VERSIONS: Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.12-200.fc37.x86_64 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 1700 Eight-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1060 3GB/PCIe/SSE2 ADDITIONAL INFORMATION Appearance - Breeze Dark Application style - Breeze Plasma Style - Infinity-plasma Windows decorations - Breeze DESKTOP EFFECTS: Magnifier, Mouse Mark, Translucency, Wobbly Windows Virtual Desktop Switching - slide w/desktop background DISABLEd WINDOW BEHAVIOUR: Focus under mouse w/raise on hover after 750ms 4x Virtual desktops on TWO physical monitors xwininfo: Window id: 0x1c00011 "Desktop — Plasma" Absolute upper-left X: 2560 Absolute upper-left Y: 0 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 2560 Height: 1440 Depth: 32 Visual: 0x7a Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x1c00010 (not installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +2560+0 -0+0 -0-0 +2560-0 -geometry 2560x1440-0+0
Immediately after I filed this report, it started happening again. I tried toggling the desktop effects (Alt+Shift+F12) and its seems to have cleared it up ...
toggling the desktop effects... After toggling the desktop effects, it clears up the painting issue, but only briefly. Between minutes to maybe an hour or two. It's a temporary hack to return the desktop's usability, but whatever's causing issue is not corrected entirely (resetting via init S or rebooting resets things to the 2-3 days state before the issue appears).
Can reproduce in 5.27.1 with amdgpu
*** Bug 466774 has been marked as a duplicate of this bug. ***
Likely a driver bug somewhere.
I think this is a regression. I've been using Plasma since forever and I only started seeing this since switching to Plasma 5.27. I tried reverting to an older kernel (5.15.0) in neon and the error persisted. Main kernel is now 5.19.0.
I should add the 5.15 kernel was what I was using on 5.26 with no issue.
Just to confirm, I started noticing windows/menus/tooltips sometimes opening black in Plasma 5.26 and still happens in 5.27. Minimizing the affected app or reopening the menu seems to fix it. Specifically I've seen the bug to happen when a minimized window is maximized/menu is opened/tooltip pops up; I don't at least remember seeing an already-open window go suddenly black. Back then I wondered if it could be some remnant of bug #456511 that got fixed in 5.26 but probably not related. (KDE Neon User Edition, X11, amdgpu, Radeon RX Vega 56)
Apologies for the late reply (work trip over weekend) but update Neon to 5.27.3 and unfortunately this is still an issue.
Just in case it isn't clear, for me, only way to get system back is a logout/restart, notifications turn to black boxes, but the Kicker/systray is un-clickable. It doesn't update as I close apps down. At the moment this is a restart every day.
Updating the title and raising the priority since it seems the symptom is graver than it reads at first.
Created attachment 157729 [details] journald logs from the incident Operating System: Kubuntu 22.10 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 Kernel Version: 5.19.0-38-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i3-10100 CPU @ 3.60GHz Memory: 15,6 GiB of RAM Graphics Processor: AMD Radeon RX 6600 Manufacturer: Gigabyte Technology Co., Ltd. Product Name: B460MDS3H
Cannot reproduce recently. I think a Mesa update fixed it.
KDE Neon latest update still seeing this, just had it this morning. Effectively I need to log out and back in every 24hrs as once it starts it becomes unusable.
I think I'm seeing the same thing (openSUSE Tumbleweed), except that I can make the problem go away by closing a lot of things. Typically what I close to fix it, at least temporarily is Firefox. I am someone who tends to have a pathological number of browser tabs and windows open so this closes a lot. Sometimes I can make the problem go away for a shorter amount of time by closing some other large application instead. It feels to me as if there were some system resource like window handles or some such that gets exhausted, something that the system is not cleaning up for reuse quickly enough. I'm not saying it must be that, but that's the feel of the behavior.
This appears to be fixed for me since the Mesa updates on Neon on 2023-05-24, something in here fixed. Upgrade: libgles2-mesa-dev:amd64 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), libglx-mesa0:amd64 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), libglx-mesa0:i386 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), libgbm1:amd64 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), libgbm1:i386 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2),libgbm-dev:amd64 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), libxatracker2:amd64 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), mesa-va-drivers:amd64 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), mesa-va-drivers:i386 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), libgl1-mesa-dev:amd64 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), libgl1-mesa-dri:amd64 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), libgl1-mesa-dri:i386 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), libegl1-mesa-dev:amd64 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), mesa-vulkan-drivers:amd64 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), mesa-vulkan-drivers:i386 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), libglapi-mesa:amd64 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), libglapi-mesa:i386 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), libegl-mesa0:amd64 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), libegl-mesa0:i386 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2), mesa-vdpau-drivers:amd64 (22.2.5-0ubuntu0.1~22.04.1, 22.2.5-0ubuntu0.1~22.04.2)
Hmm, I have an up-to-date KDE Neon and saw a black window just yesterday. Doesn't seem to be fixed here.
*** Bug 466317 has been marked as a duplicate of this bug. ***
I have noticed that over time Plasma rendering gets more sluggish (overall low framerate, things like menu item highlight changes etc. behave sluggishly) and that seems to be when I really start getting the black windows too. The Xorg process will have high CPU usage when doing something like playing a video in Firefox (but not when I'm not doing anything on the desktop). Not sure what is cause and what is symptom in this case though. In my case running kwin --replace fixes the sluggishness, Xorg CPU usage returns to being always at low levels and windows seem to render normally again (at least until things start slowing down again).
*** Bug 471962 has been marked as a duplicate of this bug. ***
This is still a problem on OpenSUSE Tumbleweed using the latest NVIDIA drivers 535.54.03 and KDE Plasma 5.27.6 X11.
*** Bug 471011 has been marked as a duplicate of this bug. ***
Could any plasma developer comment as to whether what I said in my previous comment (#15) makes any sense? Tthat is, whether there is any sort of windowing resource which the system can "run out" of? The behavior I see effects not just windows but thing like menus and tool tips. Sometimes I just have to open and close a menu repeatedly to get it to paint, as if some of this resource which the system ran out of eventually got garbage collected (or something like that).
Could be inodes or inotify watches. Might wanna check up on those. Lowering priority since we haven't gotten any new reports in a while and no developer has been able to reproduce it yet.
I can still see frozen windows sometimes, but they are all Firefox windows.
I'm also not able to replicate it anymore. Not sure if it's entirely resolved, but I haven't encountered it anymore since I reported it. Might've been related to nvidia / mesa graphics.
I still see it (using 5.27.8). Possibly less often / it takes longer to start occurring. I do have nvidia.
I've been experiencing this bug ever since switching to KDE about a year ago. I'm pretty sure it's not memory exhaustion, since both my RAM and VRAM rarely cross 50% used. Perhaps it's related to what apps are being run. I have Firefox, another Firefox (Librewolf), Chromium, Jetbrains IDEA, Zim the desktop wiki and Yakuake running 24/7. Black windows start appearing every couple of days or weeks, I have a `kwin_x11 --replace` shortcut on my desktop for this reason. To be noted that after restarting kwin this way all Firefox windows are filled with garbage or pure transparency until they repaint. Currently reproducible on: Operating System: Gentoo KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.5.5 Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 5800X3D 8-Core Processor Memory: 125,7 GiB of RAM Graphics Processor: AMD Radeon RX 5700 8GB
This is still a thing btw, and I can also report that locking has nothing to do with anything (I have everything disabled here, but screen dimming and sleep). Operating System: Manjaro Linux KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.113.0 Qt Version: 5.15.12 Kernel Version: 6.6.10-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 6 × Intel® Core™ i5-9600K CPU @ 3.70GHz Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 2080 SUPER/PCIe/SSE2 (545.29.06)
A few days of bliss and then blackouts. Using Slackware, updating often, so I'm at Plasma Version 5.27.10, Frameworks Version 5.115.0, Qt Version 5.15.12, and Kernel Version 6.6.20 (64-bit), Graphics Platform X11. I first noticed the issue at kernel version roughly 6.1.15. Stephen's description of the issue mirrors my symptoms exactly. 1. I have discovered is that even though the pointer doesn't change when over buttons in the blacked out window, the button will still respond to a click. The window is not inactive, just unpainted. 2. If the graphics can be recovered by resizing the affected window, the window will often black out again once it is sized back to the original "black out" size. Something is remembering the blacked out state of the window in its original blacked out size. If the window is resized enough, it seems to force a more basic repainting of the window and it appears normally. 3. It seems to affect pop-ups, program windows, terminal windows, pop-outs, drop downs, panels, almost everything. The one window/panel that has never appeared blacked out is the drop down when you enter Edit Mode (Alt-D, E). HTH
I'm still observing the symptoms described in issue 466317 (I hadn't seen it for a long time, but just now I got a black context menu, I think it was in Dolphin), which I'm not entirely convinced is the same as this bug bit it's marked as duplicate. Operating System: Manjaro Linux KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 Kernel Version: 6.6.26-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 12 × 12th Gen Intel® Core™ i7-1255U Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: Vivobook_ASUSLaptop X1502ZA_F1502ZA System Version: 1.0
I've first seen this on Plasma 6 with Gen4 Intel iGPU using wayland. It doesn't happen with Xorg on that same system. Maybe related: On my NVIDIA system, the same thing happens with wayland quite easily if I run wayland during gaming/streaming with OBS. It's really bad, I've gone back to Xorg. But even with Xorg, kwin_x11 and plasma-shell often crash and restart after 2+ hours, causing severe stutters in game and causing framedrops in recording/streaming. When this happens, plasmashell already uses 2 GB of VRAM. I really don't know why it eats so much VRAM, and it probably crashes because it fails to allocate anything more. VRAM usage of plasmashell it absurd, even when idle, it already uses 800+ MB, after some light usage, it easily uses 1+ GB already. The nvidia-drivers can do some cleanup every once in a while (a feature called "CPMM", please ask NVIDIA developers about the details, I'm not allowed to disclose the tuning parameters: it's active by default with 10min cleanup interval). It brings usage down from 800 MB initially to only 170 MB (using 15 seconds cleanup interval [1]). But that only means that plasmashell piles up a lot of render surfaces or render buffers it never cleans up on its own. This feature only works for GL, so if you switch to Vulkan using "kcmshell6 qtquicksettings", it shows the bad behavior again. Unfortunately, using the software renderer no longer works in Plasma 6: it renders icons to the wrong positions or completely removes them from rendering as soon as you hover the mouse over them. But in this mode, plasmashell uses only 4 MB of VRAM and I'm seeing no negative performance impact. In Plasma 5, this has been the game changer. Now with Plasma 6, the system isn't really usable if you stress the system with VRAM allocations as games usually do. And that's not limited to NVIDIA, it happens on Intel iGPUs too, and usually very quickly because of the low amount of shared VRAM. And with wayland, all of this is handled exceptionally bad, Xorg is a little more forgiving. While wayland works beautifully (ultra-smooth desktop, proper scaling etc) for light desktop usage, everything causes havoc if you do some real work like having lots of open windows on multiple monitors (4 in my instance), rendering or gaming, especially with OBS. Plasma starts to fight with every process in the system over GPU resources. There's no longer an option to use software rendering because rendering is just broken with it. I really don't need hardware accelerated rendering for the plasmashell: In the end, it's just a bar to switch between applications, and launcher and notification manager. But it's the main consumer of GPU resources on a KDE desktop, and it fights for it really hard, hurting performance more than what is gained by hardware rendering. Currently I can work around it by using QSV with OBS (instead of NVENC), limiting my main game VRAM usage through DXVK and using a short CMPP interval only for plasmashell. But that only helps short term, longer sessions are really borked, and after more than 2 days of usage, I'd rather need to reboot before trying anything else. Also, it's a little more stable by using the NVIDIA open kernel drivers: they seem to handle VRAM a little different. But even if drivers can or should fix it, VRAM usage of plasmashell is still absurdly high and it will hurt performance for gaming - no matter what a driver can do. I hope this gets fixed sooner than later, that would be great. :-) [1]: This low interval has some unwanted side-effects in OBS as it cleans up OBS render resources, too, leading to repeated frametime spikes during recording or streaming.
I experienced this bug on Debian Bookworm using 5.27.x, X11, NVidia Tried many things mentioned by others in this thread, to no or very little effect. Even swapped my NVidia card for AMD. Bug still occured, although it takes a little longer to manifest. Finally I uninstalled the latte-dock package. Plasma is stable again.
Stephen, can you reproduce that as well?
(In reply to Ben Hay from comment #33) > Even swapped my NVidia card for AMD. Bug still occured, although it takes a > little longer to manifest. > > Finally I uninstalled the latte-dock package. > Plasma is stable again. This is probably because latte-dock is a heavy user of GPU resources, probably in terms of VRAM. I don't think this is caused by latte-dock per se, there's something generally going wrong deeper in the stack. Same probably applies to plasmashell.
This issue appears to be X11-specific; it you're seeing something that looks like it on Wayland, it's likely something else.
I have encountered what i believe to be this issue, affecting kubuntu 24.04 for me note i have not seen a process freeze yet, cycling the minimized/restored state can get a window visible Found some threads that appear to be this issue: https://www.reddit.com/r/Kubuntu/comments/1fhunnw/24041_anyone_seeing_windows_menus_andor/ https://superuser.com/questions/1766652/black-out-application-window-on-kde-plasma-after-long-uptime https://www.reddit.com/r/kde/comments/15kot7w/is_there_a_fix_for_the_compositor_causing/ https://forum.manjaro.org/t/black-windows-issue-after-prolonged-usage/144339 claims a kernel parameter solved the issue
Absolutely terrible bug make your computer unusable. Menus and windows gradually go black. After "upgrading" to 24.04 LTS System: Kernel: 6.8.0-47-generic arch: x86_64 bits: 64 compiler: gcc v: 13.2.0 Desktop: KDE Plasma v: 5.27.11 Distro: Kubuntu 24.04.1 LTS (Noble Numbat) base: Ubuntu plasmashell 5.27.11 Qt: 5.15.13 KDE Frameworks: 5.115.0 kf5-config: 1.0 qtpaths 1.0 6.8.0-47-generic x11 Model name: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz Mem: 62Gi 19Gi 1.8Gi 533Mi 42Gi 43Gi 01:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 730] (rev a1)
I have the same issue in Linux Mint 22.1 Xia with nvidia 3080 ti
Adding the x11-only keyword
I am suffering from this bug for over 2 years now on my machines. I can't go a full week without having to reboot 1-2 times. I first came across it in OpenSuse Leap (where the bug appeared for me with Plasma 5.27 (it was NOT an issue before that version)), and that bug was one of the reasons which made me switch over to Debian 12, only to re-encounter the bug there as well. Furthermore, I can confirm I encountered this issue not only on my workstation, but as well on my computer at home, and they both have different GPUs (Nvidia vs AMD)(though I have the feeling on the AMD GPU the issue is happening much later (but this computer is much less used and in sleep over the night/days, while my workstation is on 24/7 and only on lock screen during the nights). I went through several different iterations of kernels, GPU drivers and likely MESAs as well, without resolution, which imho all points towards a change in KDE Plasma/kwin which is causing this. Furthermore, I can also confirm that the Alt+Shift+F12 combo only brings temporary, very limited relief. The same goes for "kwin_x11 --replace". Only a full restart resolves the issue (until 3-4 days later, when it re-appears).
I started using a RX 5600 XT (was using a RX 580) along with linux 6.13-rc5 and the issue takes way longer to occur, i think i noticed it once in the time since that was the current RC kernel (about 3.5 months)
(In reply to Carsten from comment #41) > ... > I first came across it in OpenSuse Leap (where the bug appeared for me with > Plasma 5.27 (it was NOT an issue before that version)) > ... So are you experiencing this with Plasma 5.x and Frameworks 5.x? And is this Wayland or X11?
(In reply to Michael from comment #43) > (In reply to Carsten from comment #41) > So are you experiencing this with Plasma 5.x and Frameworks 5.x? And is this > Wayland or X11? Currently: Operating System: Debian GNU/Linux 12 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.0-32-amd64 (64-bit) Graphics Platform: X11 Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor Memory: 125.7 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3050/PCIe/SSE2 I think (but not 100% certain since its so long ago), I first encountered the issue after ugprading Opensuse Leap 15.4 to 15.5 which changed Plasma from 5.24 to 5.27. It might have been one version earlier Leap 15.3 to 15.4 (Plasma 5.18 to 5.24) already...but I don't have any reliable documentation on that from back when. After I switched to Debian 12 (Plasma 5.27) the issue remained. All observed under X11. I tried to use Wayland at times, and I never encountered the issue under Wayland, but since I ran into other, unrelated issues/showstoppers in Wayland, I never used Wayland long enough to tell for sure if the issue is not applicable to Wayland. Showstoppers for Wayland were mostly GPU driver related, Davinci related and color calibration related. Since I consistently run into this issue every couple days...are there any specific log files or further information I could collect to help resolve this?
Okay, so you're running the 5.x series of Plasma. I wonder how much energy the developers will be putting into tracking down issues in 5.x as they're currently focusing on making 6.x the best it can be? I'm guessing not much. I know that this doesn't help you, but I originally had this issue when running under 5.x but do not experience it running under 6.x.
(In reply to Félim Whiteley from comment #16) > This appears to be fixed for me since the Mesa updates on Neon on > 2023-05-24, something in here fixed. > > Upgrade: libgles2-mesa-dev:amd64 (22.2.5-0ubuntu0.1~22.04.1, [...] mesa-vdpau-drivers:amd64... (no plasma packages in the update) I just asked Félim Whiteley if this indeed fixed the error on their machine, and yes he confirmed. This is the best evidence that has been presented in this issue that involves a fix and it clearly points to Mesa. I understand this bug is quite awful for all involved, but in light of this evidence I think we should close this issue. Honestly, even if it the culprit WOULD be plasma, the reality of the difficulty of backporting fixes to an earlier version is an enormous challenge and expecting a good support is just not realistic. If you're interested, please see Nate's explanation of this here: https://discuss.kde.org/t/how-long-plasma-5-will-be-mantained/7276/5