SUMMARY: Long-time user of kde, when it actually works, but a normal issue is it has never been able to deal with a very large framebuffer which is a constant issue from 4.x days. It appears to be a systemic issue that has never been addressed, as this has been the same for over 10 years that it cannot deal with large frame buffers, prior 11520x1080 resolution (6x 1080 displays), upgraded now to 11520x2160 (3x 4k displays). It still destabilizes the same from 4.x days into current. STEPS TO REPRODUCE 1. Connect 3x 4k displays with an nvidia display, any driver version (currently 430.34-2). 2. Use with uptime over a week or three. 3. Watch for windows to stop refreshing when interacted with. OBSERVED RESULT: Windows stop refreshing when interacted with, such as clicking, typing in consoles, anything inside KDE. Browsers, console sessions, anything expected to be instantly refreshed upon click/type/change, and watch them not do so until minimized or otherwise forcibly refreshed. This is most noticeable using a browser, clicking on things the display never changes, until minimized and brought back to change to the new page, or same for a terminal session with konsole that doesn't show typed commands until minimized and brought back. EXPECTED RESULT: Updates to the windows as typing, clicking, other occur. They do not when kwin gets wonky. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.16.3-1 KDE Frameworks Version: 5.60.0-1 Qt Version: 5.13.0-1 ADDITIONAL INFORMATION: This condition has existed from the beginning of time, and always ignored when reported in various ways. As a core component of the DE, it's pretty sad this persists, but does without resolution. I normally just switch between Cinnamon, Mate, or KDE, depending on which is more stable, but I really like KDE, when it's not terrible to use. This condition sometimes depending on version manifests itself quickly (within an hour) to weeks (best-case). Work-around for me is restarting compositing regularly, where after a few weeks of uptime, is every 3-4 days. Switching in display/compositor settings from OpenGL 2.1 and 3.0, back and forth fixes it, for a while again. Neither is better, just switching between either resolves it until it destabilizes again.
Are you sure that you're not hitting bandwidth issues? Is your video card capable of driving six 1080 monitors?
I am pretty sure not, it's a 1070GTX. This only occurs with kde/kwin so far, where I've been testing again of late, but otherwise have been using Mate/Cinnamon mostly as kde's been a basketcase for me the past year or so. I do a fair amount of gaming on this too, never have an issue running linux-native or proton-based windoze steam games, so long as it's not freaking out at the moment, it works just fine. Thus I really don't think it's a video bandwidth/capabilities thing, but the compositor. I just toggle opengl modes in ksettings, and it's good again for a few days. Kwin currently is using about 3.8gb of ram, and plasmashell uses 17.4gb, so it's quite resource intensive to use, but having a 20-core system with 128gb of ram helps, but it just seems to come unglued at some point. I'm trying to put gputop on this to watch it, I've done so with my laptop in the past, but the package seems broken for arch currently yay install it...
So today after 40 days of uptime, kde is finally angry and won't restart compositing. Cairo-dock effects still work in gl, but I get a black band behind it due to lack of a compositor to fill it in. Journalctl only give me "kwin_x11[36260]: kwin_core: Compositing is not possible" when trying to restart compositing via settings. I can never tell if this is more the video drivers or the compositor, but this is the longest uptime I've had on KDE in a bit before I just lose displays waking up at all and needing to restart it to even get sddm to restart the desktop. Nothing logs anywhere that says video is unstable, or the system in general, only kwin refuses to composite further. When it gets like this, I suspect I'll need a full reboot to rectify, as often restarting sddm fails.
> Compositing is not possible If you get this message, then it could mean couple things. Either some important X11 extension is missing, or OpenGL compositing is unsafe. We consider OpenGL compositing unsafe if it takes too long (more than 15 seconds) to "render" a frame. Did you see "Freeze in OpenGL initialization detected" along "kwin_x11[36260]: kwin_core: Compositing is not possible" in journalctl output by any chance? Please run two commands below when kwin is not able to restart compositing and post the output here. qdbus org.kde.KWin /Compositor openGLIsBroken qdbus org.kde.KWin /Compositor compositingNotPossibleReason
Also, please provide output of qdbus org.kde.KWin /KWin supportInformation
Created attachment 122583 [details] Requested qdbus kwin output.
No, only the single output I pasted in the last message, nothing more via journalctl related to video or kde all together. Certainly, attached my output to the ticket as requested. Thank you Vlad.
> Windows stop refreshing when interacted with, such as clicking, typing in > consoles, anything inside KDE. Browsers, console sessions, anything > expected to be instantly refreshed upon click/type/change, and watch them > not do so until minimized or otherwise forcibly refreshed. This is most > noticeable using a browser, clicking on things the display never changes, > until minimized and brought back to change to the new page, or same for a > terminal session with konsole that doesn't show typed commands until > minimized and brought back. Can you move frozen windows with mouse? You may also want to re-enable compositing in KWin. Go to compositor settings and check "Enable compositor on startup"
> Can you move frozen windows with mouse? I can move the window itself, but content within such as the current webpage does not refresh. I have to minimize, unhide to get it to force a refresh to change the page position, see refreshed click on a link, scroll up/down, etc. > You may also want to re-enable compositing in KWin. Go to compositor settings > and check "Enable compositor on startup" That doesn't work anymore, such that I updated this yesterday. That is normally my fix, to flip gl versions, or disable/enable as you said, but now I just get the kwin "Compositing is not possible" error when trying to restart in *any* capacity. It's degraded itself to be systemically broken at this point far as I can tell, and always gets to this point. Last time prior trying this 8-10mo ago, Kwin compositing would lag something fierce upon boot, and destabilize within the day about the same ways, just at a much accelerated pace. Trying this the past few months, it's been much improved, but still degrades over time like a bad memory or other resource leak. I'm sure I see this as one of few with a 11520x2160 framebuffer to actually stress-test the video subsystems, but perhaps there needs to be a valgrind-ish tool for the compositor world to test this.
(In reply to Michael Butash from comment #9) > That doesn't work anymore, such that I updated this yesterday. That is > normally my fix, to flip gl versions, or disable/enable as you said, but now > I just get the kwin "Compositing is not possible" error when trying to > restart in *any* capacity. It's degraded itself to be systemically broken > at this point far as I can tell, and always gets to this point. Uh, yeah... Open ~/.config/kwinrc, remove OpenGLIsUnsafe line, and restart kwin_x11 by running the following command kwin_x11 --replace
(In reply to Michael Butash from comment #9) > I can move the window itself, but content within such as the current webpage > does not refresh. I have to minimize, unhide to get it to force a refresh > to change the page position, see refreshed click on a link, scroll up/down, > etc. Hmm, I don't think that's a bug caused by kwin given what you wrote above. Most likely, something goes wrong when kwin calls these two functions glXReleaseTexImageEXT glXBindTexImageEXT Please post output of qdbus org.kde.KWin /KWin supportInformation one more time, but only when compositing is on. It doesn't matter whether windows are frozen.
Created attachment 122635 [details] Requested qdbus kwin output with compositing active. Here is the requested output with compositing re-enabled.
Thanks Vlad, that worked to let me reenable compositing now, and attached the qdbus output of that.
Does the freeze occur if you add the following line to [Compositing] section in your kwinrc GLStrictBinding=1
Ok, I've added that, will continue to use and see if windows start going wonky again. Sometimes takes days/weeks... Anything more I can pull to help resolve this when it *is* acting weird again? I did do a kwin_x11 --replace again after, and while the GLStrictBinding shows in the kwinrc (it even moved its ordering), I got this output on the replace that says it's not (?): kwin_x11 --replace & OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 1070/PCIe/SSE2 OpenGL version string: 4.6.0 NVIDIA 430.34 OpenGL shading language version string: 4.60 NVIDIA Driver: NVIDIA Driver version: 430.34 GPU class: Unknown OpenGL version: 4.6 GLSL version: 4.60 X server version: 1.20.5 Linux kernel version: 5.2.2 Requires strict binding: no <<< GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no Use of qdbus to view systemInfo shows about the same: Direct rendering: Requires strict binding: no
> Requires strict binding: no That line shows whether loose binding is supported by the driver. Use this command instead qdbus org.kde.KWin /KWin supportInformation | grep glStrictBinding If everything is okay, you should see glStrictBinding: true glStrictBindingFollowsDriver: true
Created attachment 122742 [details] Requested qdbus kwin output with compositing active 20190919 So I'm starting to get the gl compositing issues again with cairo-dock freezing, which it always begins there, and getting some lag when scrolling through windows (browser, text editors, terminals), so it's destabilizing again. I pulled a supportInformation again, but looks about the same as it has when working diff'ing the files. Anything else helpful to look at further before I restart compositing?
> Anything else helpful to look at further before I restart compositing? Yeah, it would be great to have a look at your Xorg.0.log and dmesg output.
Created attachment 122758 [details] Output from Xorg.0.log Sure, I sterilized some of the ip's, names, and macs that pop up, but otherwise here you go.
Created attachment 122759 [details] Output from dmesg Here's the dmesg output of what is left in buffer to current.
So last night my desktop finally broke entirely, where after it woke up, all I got was a blank display. At this point I was left with no choice but to reboot it, and did so gracefully from an alt tty. A reboot would get me to sddm login, but once logging in, I get the framebuffer start same black display, but I could see the mouse moving as it would normally across the displays, just no apps. Restarting sddm and trying Mate or Cinnamon, I now get the black screen for anything beyond sddm. Installing and using GDM doesn't seem to work either, but not sure that isn't just a config thing having never used it before anyways. It's odd, I get no error from xorg logs, journalctl looks fine through launching sddm and into plasma, until it gets to kwin_x11 gives "qt.qpa.xcb: QXcbConnection: XCB error: 3 (Bad Window) 9 (Bad Drawable). All other log output for the session seems like apps are starting fine. I had this happen once before similarly, seems something I installed upgraded some core components, and an entirely pacman -Syu fixed it, so did so here, but still no change, same as before upgrade. Now I'm not even sure where to start with this to get a working desktop again now.
Interesting part I find is it does seem to be compositing, it's just not showing me anything but a black window. When I use an alt terminal to log in at shell, I see kwin_x11 --replace running, and qdbus supportInformation shows compositing up and running. Very odd behavior, something new. If I try to restart compositing with Ctrl-Alt F12, I get the console screen again just blinking, until I switch to F3 and back to F1, then I get the composited black screen again. Almost like there's nothing behind the compositor there to show. I don't know how this went from compositor instability to desktop no longer works, but it sure did. I haven't installed anything new in a while, but it was up to around ~50 days of uptime too. I will post an updated qdbus supportInfo as well post-upgrade and currently broken.
Created attachment 122844 [details] Output of qdbus kwin supportInfo post upgrade and current breaking Updated supportInfo post full system upgrade and still having a total failure of kde/kwin currently.
> OpenGL platform interface: EGL Hmm, that's strange. Did you force the EGL platform interface? Try running kwin with KWIN_OPENGL_INTERFACE=glx
Back to the bug, I don't see why kwin would stop updating window contents. Could you report this bug to NVIDIA developers?
> Hmm, that's strange. Did you force the EGL platform interface? No forcing of anything. It broke, I rebooted, it came up broken still. Only things I've done was trying to restart sddm and review logs for any sort of hints as to why this is occurring suddenly.
Created attachment 122966 [details] QDBus KWin support information
Comment on attachment 122966 [details] QDBus KWin support information I can confirm that I have seen similar behaviour with KDE over the past few years and also that, it occurs while my laptop is up for many weeks. The following things happen (I think they are related): 1. Windows stop refreshing or paint selectively. If I am typing text in an input box I won't see until I do alt+tab twice or minimize the window and restore it. I also see strange things like flashing icons. For example, if I click on a menu button on a web page then the icon is supposed to be replaced with another one (highlighting). In this case the previous icon still remains while the new icon appears on top of it, thus, creating some strange effect which is animated (hard for me to even explain). I notice this behaviour mostly on Chromium (probably because Konsole and Chromium is 95% of my work). It occurs on all tabs in that window so I have to close all tabs and then close this window, rest of the Chromium windows remain open and work fine. This happened right now and that is why I wanted to report a bug and came across this bug report. My uptime is *17 days* right now. The only output which I got from journalctl today when this happened: ``` Oct 01 20:10:24 Rise org.kde.KScreen[5383]: kscreen.xrandr: XRandR::setConfig Oct 01 20:10:24 Rise org.kde.KScreen[5383]: kscreen.xrandr: Requested screen size is QSize(1920, 1080) Oct 01 20:10:24 Rise org.kde.KScreen[5383]: kscreen.xrandr: Needed CRTCs: 1 Oct 01 20:10:24 Rise org.kde.KScreen[5383]: kscreen.xrandr: Actions to perform: Oct 01 20:10:24 Rise org.kde.KScreen[5383]: kscreen.xrandr: Primary Output: false Oct 01 20:10:24 Rise org.kde.KScreen[5383]: kscreen.xrandr: Change Screen Size: false Oct 01 20:10:24 Rise org.kde.KScreen[5383]: kscreen.xrandr: Disable outputs: false Oct 01 20:10:24 Rise org.kde.KScreen[5383]: kscreen.xrandr: Change outputs: false Oct 01 20:10:24 Rise org.kde.KScreen[5383]: kscreen.xrandr: Enable outputs: false Oct 01 20:10:24 Rise org.kde.KScreen[5383]: kscreen.xrandr: XRandR::setConfig done! ``` 2. I have seen occurrences of blank desktop after logging in. Can't remember if it was SDDM or the earlier KDM. 3. If I connect an external monitor and then disconnect it, I am not able to use my keyboard within the *Present Windows* effect. As if the keyboard input stops getting captured when the effect is on (even Esc key doesn't work). The effect works all fine otherwise but goes haywire only after I disconnect an external monitor. And, this problem doesn't fix itself if I reconnect/disconnect monitors after it has occurred. Attached: QDBus KWin support information. PS: Please let me know if I should be creating separate bugs for the above behaviour.
This bug was reported against an outdated version of KWin. We have made many changes since the. If the issue persists in newer versions can you reopen the bug report updating the version number.