I've got a setup where at boot I start 2 X servers, each used by a different account. I switch between the two using Alt-F8 & Alt-F9. This has worked for me for a long time. Since the latest update I see that the off-screen kwin (the one that doesn't have access to the physical screen and keyboard, so for the user not being displayed) is using up 100% CPU time. Using strace on the offending kwin process, I see it's looping with a repeating select(16, [4 5 9 10 14 15], [], [], {0, 0}) = 0 (Timeout) recvfrom(9, 0x22a74e4, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) So instead of a blocking select there's one that times out immediately, causing the CPU hog. Reproducible: Always Steps to Reproduce: 1. start an extra X server using "StaticServers=:0,:1" in kdmrc 2. log in with one user on server 0 3. switch to server 1 4. log in with another user on server 1 5. switch between the two servers and follow cpu usage using top Actual Results: off-screen kwin starts using 100% CPU Expected Results: quiet down
can you try to disable desktop effects before switching the VT?
When I switch desktop effects off, the cpu usage goes away
funny thing is, even when I now switch desktop effects back on, the CPU usage stays low (< 0.7 %)
and also (w/ compositing) - provide the output of qdbus org.kde.kwin /KWin supportInformation - try xrender compositing ("kcmshell4 kwincompositing", 3rd tab) In case it's an nvidia board, try export __GL_YIELD="USLEEP" kwin --replace &
> qdbus org.kde.kwin /KWin supportInformation qdbus: could not find a Qt installation of '' > kwin --replace & QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 550 Ti/PCIe/SSE2 OpenGL version string: 4.2.0 NVIDIA 304.88 OpenGL shading language version string: 4.20 NVIDIA via Cg compiler Driver: NVIDIA Driver version: 304.88 GPU class: GF100 OpenGL version: 4.2 GLSL version: 4.20 X server version: 1.14.3 Linux kernel version: 3.11 Direct rendering: yes Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no kwin(18670) KWin::ColorServerInterface::callFinishedSlot: QDBusError("org.freedesktop.DBus.Error.UnknownObject", "No such object path '/modules/kolorserver'") kwin(18670): Update of color profiles failed kwin(18670) KWin::ColorServerInterface::callFinishedSlot: QDBusError("org.freedesktop.DBus.Error.UnknownObject", "No such object path '/modules/kolorserver'") kwin(18670) KWin::ColorServerInterface::callFinishedSlot: QDBusError("org.freedesktop.DBus.Error.UnknownObject", "No such object path '/modules/kolorserver'")
After "export __GL_YIELD="USLEEP"; kwin --replace &", getting the output above, I switched to the other user and the CPU usage leveled out at 100% again.
after switching to xrender (from opengl 2.0) and switching to the other screen, CPU usage had dropped to 0.9%
> qdbus: could not find a Qt installation of ' https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1177823 see comment #10 for where the binary is probably shashed...
Created attachment 83791 [details] output of "qdbus org.kde.kwin /KWin supportInformation"
errrrmmm... on the problematic gl compositing settings, please =)
Created attachment 83808 [details] output with OpenGL2 as compositing driver
thanks. try setting the tearing prevention to "none" and deactivate the blur and diminactive effects. if that doesn't help, see whether it also happens for singlescreen setups. I guess that you know you can sigstop "the other kwin" when changing VT (i fear this is in the driver and our würgaround could only be to in the same way poll vtstat.v_active ... ewwww) Does it btw. matter which compositing is suspended? (ie. does the problem only exist for two active GL compositors or is active GL compositing on the inactive VT only sufficient to cause this?)
any update?
I've switched the tearing prevention to none and compositing type to opengl 3.1. This seems to have solved the issue, but of course there is some tearing now. The OpenGL version doesn't appear to matter, but as soon as I switch tearing prevention on the cpu usage goes up when I switch to the other screen. Sigstopping is inelegant, because when I forget to start it again and switch to the session, it freezes my box and I have to go in through my table in order to sigstart it. I've just switch on tearing prevention for the other session and now I'm back at this session the inactive kwin is at 100% CPU. I sigstopped it, and started it again. CPU didn't go up, but switching to the other screen showed it had crashed.
Try tearing prevention: "full scene repaints" - the setup likely dislikes reading the frontbuffer. Problem should be gone with https://git.reviewboard.kde.org/r/114162/ (KDE 4.12.1 / KWin 4.11.5) https://bugs.kde.org/show_bug.cgi?id=319995
I've switched to full scene repaints, will monitor CPU usage for a while. It's low now both on the active and inactive vt
Just upgraded to fedora23 with kwin 5.5.0 and this issue seems to have re-appeared. I do have a Nvidia card. Have previously turned on __GL_YIELD="USLEEP" (which helped earlier) and the xorg.conf settings contain: Option "NoLogo" "True" Option "CoolBits" "1" Option "TripleBuffer" "True" Haven't tried the trick in Comment 15 yet, but I thought this was supposed to been fixed already in kwin 4.11.5 already? Regression?
KWin has never fixed and actually cannot fix this (we'd need to track the VT and that requires root permissions), the behavior is completely in the driver (we just could at some point omit the code that sometimes reads the frontbuffer - iff that turns out to be the ultimate cause)
Ok. Thanks for clarifying! The question now is then what triggers this in 5.5.0 compared to the 4.x I used earlier where the __GL_YIELD worked. And what can be done about this. I will later, when at this machine try some things and report back. Any suggestions are of course also welcome.
(In reply to Thomas Lübking from comment #18) > KWin has never fixed and actually cannot fix this (we'd need to track the VT > and that requires root permissions), the behavior is completely in the > driver (we just could at some point omit the code that sometimes reads the > frontbuffer - iff that turns out to be the ultimate cause) $ xprop -root | grep VT XFree86_has_VT(INTEGER) = 1 XFree86_VT(INTEGER) = 7
Ah, nifty. Seems oracle added it for virtualbox in 2014. Martin, are you fine with autosuspending (adding a new cause) based up on the property? (I'd rather not stop updating, aka. "freeze, based upon a root property, but suspending the compositor would at worst be annoying)
hmm I hope we can destroy the OpenGL context when not on the current VT. Otherwise: maybe rather use the logind information and use it to freeze. It's more "trustworthy".
(In reply to Martin Gräßlin from comment #22) > hmm I hope we can destroy the OpenGL context when not on the current VT. Works for me™ > Otherwise: maybe rather use the logind information and use it to freeze. Which one? Our session VTNr should remain constant and there's no guarantee the active VT even runs a session (could be getty and/or some global top/dmesg stuff) Ie. can we at all (ignoring a bit that this will upset BSD users ;-)
> Which one? signal LogindIntegration::sessionActiveChanged > there's no guarantee the active VT even runs a session (could be getty and/or some global top/dmesg stuff) AFAIU logind should still indicate whether the session is active. And of course rather a corner case :-) > Ie. can we at all (ignoring a bit that this will upset BSD users ;-) nah, it's a workaround for a corner case. It's not like we are taking away a feature or anything. I'd prefer to first try with freeze on session change. I'm a little bit worried about the overhead for suspend/resume when switching VTs.
This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
I have bought a new (simpler) desktop in the mean time, an MSI cube, with integrated intel video. I have not noticed the issue since. So from my perspective this can be closed as resolved. -- Lyon