Created attachment 167654 [details] EDID data SUMMARY Since the upgrade to 6.0 I experienced a spin up of my CPU fans every time the screen engages. I have now had time to investigate this a bit by logging into the system via SSH and running top/htop. When I locked the screen, kwin_x11 jumped from ~5% CPU to ~70% and Xorg from ~3% to ~50%. ksmserver also moved into the top three processes. I tried again and attached gdb to the running process, interrupting it now and then. At the beginning (let's say first 1-2 minutes) the backtrace often included the KWin::Edid constructor, mostly in some memory allocation calls. Later on I only manages to interrupt it while it was in some XCB call. I can also not reproduce on a second system with relatively similar software state (both KDE Neon with the same updates installed). Two potentially related hardware differences are GPU and number of monitors. Workstation (which runs into the CPU load issue): AMD Radeon RX 550 / 550 Series, 3 monitors Laptop (which does not have the issue): Intel UHD Graphics 620, only internal monitor STEPS TO REPRODUCE 1. lock screen 2. observe CPU load via remote connection OBSERVED RESULT kwin_x11 and Xorg (though one might "drag along" the other) jump in CPU load to about 10 times their usual load EXPECTED RESULT CPU load staying atthe same as the unlocked system. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: KDE Neon 6.0.2 (?) (available in About System) KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION AMD Radeon RX 550 / 550 Series, 3 monitors (all 1920x1080, one is from a different vendor). Attaching output of get-edid (and parsed via parse-edid)
Can confirm I observe the same behaviour, both kwin_x11 and Xorg together using 100% CPU. This is with kwin 6.0.2-3 on manjaro. Interestingly, when I move the mouse and the screen goes from black to background image, CPU usage goes back to normal. Also interesting is that I use a LG TV as display, not a monitor, so there is no "proper" display suspend, but rather the TV shows a no-signal background picture for a while.
Hotspot profiling data pointing to where these processes are using all those cpu cycles would be extremely helpful.
(In reply to fanzhuyifan from comment #2) > Hotspot profiling data pointing to where these processes are using all > those cpu cycles would be extremely helpful. I did some profiling on kwin_x11 with debuginfod data and this is the gist of it. You can get the full trace from https://pub-32f46577ac8f4e2b84ba6635b1d55699.r2.dev/pepe.perf and load it in https://profiler.firefox.com or https://www.speedscope.app/ I have used a simple "perf report" to generate the lines below: Samples: 62K of event 'cycles:P', Event count (approx.): 23722680927 Children Self Command Shared Object Symbol - 36,84% 0,00% kwin_x11 kwin_x11 [.] 0x000055638a2d3ef4 ◆ 0x55638a2d3ef4 ▒ __libc_start_main ▒ 0x7f905a643ccf ▒ 0x55638a2cfc24 ▒ - QCoreApplication::exec() ▒ - 36,84% QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ▒ - 36,83% QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ▒ - 36,81% g_main_context_iteration ▒ - 36,62% 0x7f9059c973a6 ▒ - 36,58% 0x7f9059c38f68 ▒ - 19,21% 0x7f90559ecbd6 ▒ - 19,18% QXcbConnection::processXcbEvents(QFlags<QEventLoop::ProcessEventsFlag>) ▒ - 18,69% QXcbConnection::handleXcbEvent(xcb_generic_event_t*) ▒ - 10,83% QAbstractEventDispatcher::filterNativeEvent(QByteArray const&, void*, long long*) ▒ - 8,47% KWin::Workspace::workspaceEvent(xcb_generic_event_t*) ▒ - 6,78% KWin::Workspace::createUnmanaged(unsigned int) ▒ + 3,75% KWin::X11Window::X11Window() ▒ + 2,18% KWin::X11Window::track(unsigned int) ▒ + 0,65% operator new(unsigned long) ▒ + 1,30% KWin::Workspace::updateXStackingOrder() ▒ + 2,19% 0x7f905dbbf6d9 ▒ - 7,78% QXcbConnection::initializeScreens(bool) ▒ - 7,75% QXcbConnection::initializeScreensFromMonitor(xcb_screen_iterator_t*, int, QXcbScreen**, bool) ▒ - 6,57% QXcbConnection::updateScreen_monitor(QXcbScreen*, xcb_randr_monitor_info_t*, unsigned int) ▒ - 3,51% QXcbScreen::updateColorSpaceAndEdid() ▒ + 2,06% QEdidParser::parse(QByteArray const&) ▒ + 0,74% QXcbScreen::getEdid() const ▒ 0,69% xcb_wait_for_reply ▒ + 3,04% QXcbScreen::setMonitor(xcb_randr_monitor_info_t*, unsigned int) ▒ 0,62% xcb_wait_for_reply ▒ + 0,54% QXcbConnection::findScreenForMonitorInfo(QList<QPlatformScreen*> const&, xcb_randr_monitor_info_t*) ▒ - 17,34% 0x7f905af75723 ▒ - 17,34% QTimerInfoList::activateTimers() ▒ - 17,33% QCoreApplication::notifyInternal2(QObject*, QEvent*) ▒ - 17,33% QApplicationPrivate::notify_helper(QObject*, QEvent*) ▒ - 17,25% QObject::event(QEvent*) ▒ - 17,25% QTimer::timerEvent(QTimerEvent*) ▒ - 17,23% 0x7f905ad90ca8 ▒ - 17,20% 0x55638a2ddafc ▒ - 6,10% 0x55638a2dd69e ▒ + 6,09% KWin::Edid::Edid(void const*, unsigned int) ▒ + 4,57% 0x55638a2dccba ▒ + 3,02% 0x55638a2dc985 ▒ + 0,77% 0x55638a2dcc32 ▒ + 0,71% 0x55638a2dcfaa ▒ + 0,70% 0x55638a2dd163 ▒ + 0,67% 0x55638a2dcdff ▒
Notice that ksmserver is also using quite a bit of CPU, maybe they are sending each other events in an infinite loop? Perf for ksmserver is here: https://pub-32f46577ac8f4e2b84ba6635b1d55699.r2.dev/ksmserver.perf
Sorry, I missed there is an easier way to share this: https://profiler.firefox.com/from-url/https%3A%2F%2Fpub-32f46577ac8f4e2b84ba6635b1d55699.r2.dev%2Fpepe.perf/calltree/?globalTrackOrder=0&hiddenLocalTracksByPid=1881-2&thread=1&timelineType=category&v=10
Even better (focusing on the suspicious EDID bit). Sorry about the spam: https://share.firefox.dev/4axsSYc
(In reply to Francisco from comment #4) > Notice that ksmserver is also using quite a bit of CPU, maybe they are > sending each other events in an infinite loop? I can confirm that I also see an increased CPU use of ksmserver when the screen is locked. But maybe only twice as much as when the session is active, not 10 times as much I've seen for KWin
I've the same issue on plasma 6.0.3 with X11 and two monitors on NVIDIA.
Same. Plasma 6.0.3-1 with X11. Laptop with x1 external monitor and laptop lid closed.
Same here. plasmashell --version 6.0.3. Open suse tumbleweed with X11. I disabled auto screen lock to protect my hardware.
Unfortunately, same here. OpenSUSE Tumbleweed, Plasma 6.0.3, KWin, X11.
(In reply to leoh from comment #9) > Same. Plasma 6.0.3-1 with X11. Laptop with x1 external monitor and laptop > lid closed. Can you check if the problem also happens when the external monitor is not plugged in?
> Can you check if the problem also happens when the external monitor is not plugged in? I happens for me without the external monitor being plugged in, but only on my laptop (Intel graphics card). On my desktop (NVIDIA card) it does not seem to happen. Let me know if there's any more info I can collect.
(In reply to Kevin Krammer from comment #12) > (In reply to leoh from comment #9) > > Same. Plasma 6.0.3-1 with X11. Laptop with x1 external monitor and laptop > > lid closed. > > Can you check if the problem also happens when the external monitor is not > plugged in? Some more tests: - Happens with or without the external monitor plugged in - Happens always when locked - either blank screen when locked for a while; or lock screen (even if visible for several minutes without unlocking and not allowing screen to go black) - Interesting: if while still locked I go to console (Ctrl+Alt+Fx) it stops - no login required, just change to console.
Today's Neon package updates seem to have fixed the issue for me. It still reports the same Plasma version as before (6.0.3), but I think the Qt library was updated.
Same issue here Operating System: EndeavourOS KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.5-arch1-1 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 9 5900HX with Radeon Graphics Memory: 30.8 GiB of RAM Graphics Processor: AMD Radeon Graphics When screen is locked: %Cpu(s): 4,3 us, 7,5 sy, 0,0 ni, 88,2 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st MiB Mem : 31515,7 total, 17692,4 free, 4709,4 used, 9664,4 buff/cache MiB Swap: 2048,0 total, 2048,0 free, 0,0 used. 26806,2 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 12976 hc 20 0 2238200 192812 128576 R 70,0 0,6 1:26.59 kwin_x11 12770 root 20 0 1267216 170300 124572 R 40,0 0,5 1:06.25 Xorg 12885 hc 20 0 1154660 92904 76048 S 10,0 0,3 0:03.45 kwallet+ 12973 hc 20 0 1148896 93936 79272 S 10,0 0,3 0:15.75 ksmserv+ 13037 hc 20 0 4570164 385232 151264 S 10,0 1,2 0:25.73 plasmas+ %Cpu(s): 5,6 us, 6,2 sy, 0,0 ni, 88,2 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st MiB Mem : 31515,7 total, 17699,9 free, 4702,0 used, 9664,4 buff/cache MiB Swap: 2048,0 total, 2048,0 free, 0,0 used. 26813,6 avail Mem and like leoh - Interesting: if while still locked I go to console (Ctrl+Alt+Fx) it stops - no login required, just change to console. CPU usage goes back to normal. perf record kwin_x11 the first few entries are: 10.91% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009823 9.07% kwin_x11 ld-linux-x86-64.so.2 [.] 0x00000000000097e3 3.87% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009a81 3.51% kwin_x11 ld-linux-x86-64.so.2 [.] 0x00000000000097fc 3.44% kwin_x11 ld-linux-x86-64.so.2 [.] 0x000000000000a40e 3.05% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009ae7 2.28% kwin_x11 ld-linux-x86-64.so.2 [.] 0x000000000000983c 2.25% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009a75 2.08% kwin_x11 ld-linux-x86-64.so.2 [.] 0x00000000000235de 1.96% kwin_x11 ld-linux-x86-64.so.2 [.] 0x000000000000a433 1.50% kwin_x11 ld-linux-x86-64.so.2 [.] 0x000000000000a441 1.47% kwin_x11 ld-linux-x86-64.so.2 [.] 0x000000000000e5f2 1.44% kwin_x11 libGLX_mesa.so.0.0.0 [.] 0x000000000002f356 1.40% kwin_x11 ld-linux-x86-64.so.2 [.] 0x00000000000095b7 1.36% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009854 1.33% kwin_x11 libGLX_mesa.so.0.0.0 [.] 0x000000000002f31e 1.21% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009858 1.03% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009883 0.83% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009872 0.75% kwin_x11 ld-linux-x86-64.so.2 [.] 0x00000000000235e2 0.75% kwin_x11 ld-linux-x86-64.so.2 [.] 0x000000000000e5a1 0.74% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009809 0.70% kwin_x11 ld-linux-x86-64.so.2 [.] 0x00000000000249e8 0.67% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009839 0.61% kwin_x11 libc.so.6 [.] 0x000000000015984b 0.60% kwin_x11 ld-linux-x86-64.so.2 [.] 0x000000000000a426 0.60% kwin_x11 radeonsi_dri.so [.] 0x0000000000030c0c
Is this the same or related to: https://bugs.kde.org/show_bug.cgi?id=484606#1 ? I made comment #6 there.
(In reply to fbm224 from comment #17) > Is this the same or related to: > https://bugs.kde.org/show_bug.cgi?id=484606#1 ? I made comment #6 there. Great find, this does indeed sound like the same problem. I can also confirm the observation that the CPU load returns to normal when switching to a Linux virtual console.
Interesting observation on that other ticket which I can confirm on my system: if I restart kwin_x11 (by running kwin_x11 --replace) it does no longer show the observed CPU load behavior when locking the screen
*** Bug 484606 has been marked as a duplicate of this bug. ***
Does this still happen if you 1. kill kwin_x11 before locking the screen? 2. or disable KScreen2 in the background services settings page?
(In reply to Zamundaaa from comment #21) > Does this still happen if you > 1. kill kwin_x11 before locking the screen? When I kill kwin_x11 or call it manually with --replace then the CPU load does no longer exceed normal levels. > 2. or disable KScreen2 in the background services settings page? Will try next time I re-login
(In reply to Zamundaaa from comment #21) > Does this still happen if you Just tested without changing tty or any settings. The excessive cpu use is gone here. There must have been an update that removed the bug System: Kernel: 6.8.8-arch1-1 arch: x86_64 Desktop: KDE Plasma v: 6.0.4 Distro: EndeavourOS
(In reply to Kevin Krammer from comment #22) > (In reply to Zamundaaa from comment #21) > > Does this still happen if you > > 1. kill kwin_x11 before locking the screen? > > When I kill kwin_x11 or call it manually with --replace then the CPU load > does no longer exceed normal levels. > > > 2. or disable KScreen2 in the background services settings page? > > Will try next time I re-login Disabling KScreen2 also works to avoid the issue.
(In reply to Kevin Krammer from comment #24) > Disabling KScreen2 also works to avoid the issue. Did you disable the service, log out and log in? Because I stopped the KScreen2 service (without a new login), and that was not sufficient to fix the issue for me.
(In reply to Petr Tesařík from comment #25) > (In reply to Kevin Krammer from comment #24) > > Disabling KScreen2 also works to avoid the issue. > > Did you disable the service, log out and log in? Because I stopped the > KScreen2 service (without a new login), and that was not sufficient to fix > the issue for me. Yes, indeed. I disabled KScreen2 and logged out and back in. Locking that session did not cause the CPU load to go up (verified by being logged in via SSH from a second computer) But in that session the order of monitors was not as expected, so I am back to having KScreen2 enabled and killing kwin_x11 once after login
KScreen being stopped preventing this isn't too surprising, as it can trigger output changes and that seems to be what's using so much CPU, but > or call it manually with --replace then the CPU load does no longer exceed normal levels very much is. I don't really have an explanation for that one
(In reply to Zamundaaa from comment #27) > KScreen being stopped preventing this isn't too surprising, as it can > trigger output changes and that seems to be what's using so much CPU, but > > or call it manually with --replace then the CPU load does no longer exceed normal levels > very much is. I don't really have an explanation for that one If only "kwin_x11 --replace" had worked my guess would have been a difference in environment due to being launched from an interactive shell rather than some session manager. But since killing it and having it restarted (by systemd?) also works as a "solution" that's probably not it. Could it be the order in which different components are started? Like trying to detect a D-Bus service, but failing, and falling back to some alternative code path, while succeeding when being restarted?
(In reply to Kevin Krammer from comment #24) > Disabling KScreen2 also works to avoid the issue. Confirmed.
Same issue here with me with plasma 6.0.4 on Fedora 40. Disabling KScreen2 did the trick for me as well. Before somebody stat commenting that F40 KDE cannot run on X - actually this is not the truth. F40 KDE is capable of running "the hidden" X11 session option via manually installing package plasma-workspace-x11 and sddm-x11. These packages are part of the official repos.
I have the same issue on Manjaro, high CPU usage on locked screen after whole system upgrade that includes plasma-desktop 6.0.4-1 (In reply to Kevin Krammer from comment #24) > > When I kill kwin_x11 or call it manually with --replace then the CPU load That solution eliminated high CPU usage for me. (In reply to Kevin Krammer from comment #24) > Disabling KScreen2 also works to avoid the issue. This didn't helped.
The high CPU usage in kwin_x11 is caused by it repeatedly receiving an XCB_CONFIGURE_NOTIFY message here: https://github.com/qt/qtbase/blob/4656fabd8a6ff46f786cb48c220511ebe43ea300/src/plugins/platforms/xcb/qxcbconnection.cpp#L586 This causes a call initializeScreens() which causes EDID data to be reloaded from "/usr/share/hwdata/pnp.ids" which consumes most of the CPU cycles, but this is clearly not the root cause of the loop. I noticed that on my system, the three processes using most CPU are: kwin_x11 (81.1%), Xorg (48.5%), ksmserver (18.3%). Suspending any of these three processes (using `kill -STOP`) causes CPU usage to drop to 0% immediately. Resuming the process (using `kill -CONT`) causes the problem to return. Interestingly, there are a bunch of other processes that are using smaller amounts of CPU (1%-4%), all related to KDE: plasmashell, kscreenlocker_greet, kactivitymanagerd, kded6, org_kde_powerdevil, ... Suspending any of these does NOT fix the high CPU usage, so they are not involved in the loop. However, suspending any of the top 3 DOES stop the high CPU usage of those other processes. This suggests that the cycle is not a one-to-one communication, but a message that is being broadcast to all KDE processes (by Xorg?). Most simply ignore it (hence the low but nonzero CPU usage) while only kwin_x11 and ksmserver do something significant with it, and at least one of these processes triggers another event to be sent.
Reproduced Hardware: ROG Zephyrus G14 GA402RJ CPU: AMD Ryzen 7 6800HS GPU 1: AMD Radeon RX 6700S GPU 2: AMD Radeon 680M Memory: 10.53 GiB / 38.41 GiB (27%) Dual monitor: Display (TL140ADXP01): 2560x1600 @ 120Hz * Display (DELL U2720Q): 3840x2160 @ 60Hz DE: KDE Plasma 6.0.5 WM: KWin (X11) Qt Version: 6.6.2 In my same hardware and software environment. the only difference is: After unplugging the external monitor (DP over Type-C Cable), locking the screen does not cause 100% CPU usage. Only when the second screen (DELL U2720Q here) is connected, the locking screen causes 100% CPU usage.
After upgrade to Plasma 6.1 the behavior is still present but not as bad as before. Xorg still goes up to ~50% of one CPU, but kwin_x11 only to 30% and ksmserver only to 15%
I've been able to reliably reproduce this so far by the following: STEPS TO REPRODUCE 1. Lock the screen 2. Turn off the monitor directly via the power button (for me it's the monitor OSD with a power action) 3. Turn the monitor back on From this point forward, while the screen is locked there will be high CPU load. For me, restarting "kwin_x11" via systemd ("systemctl --user restart plasma-kwin_x11.service") temporarily fixes the issue until the screen ends up turned off again. Operating System: EndeavourOS KDE Plasma Version: 6.1.1 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 Kernel Version: 6.9.6-arch1-1 (64-bit) Graphics Platform: X11 Graphics Processor: AMD Radeon RX 6400
I can confirm this for 6.1.1. I'm using 4 monitors, one of them is sometimes turned off. Perf data looks like this: # Overhead Command Shared Object Symbol # ........ ............... ............................... ........................................................................................................................................................................... # 24.22% kwin_x11 [vdso] [.] __vdso_clock_gettime 15.66% kwin_x11 libc.so.6 [.] __sched_yield 10.43% kwin_x11 [unknown] [k] 0xffffffff81c00150 1.71% kwin_x11 libc.so.6 [.] clock_gettime@@GLIBC_2.17 1.46% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x0000000000b00d13 1.24% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x0000000000b00d00 1.02% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x00000000009eea66 0.78% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x00000000009eea61 0.72% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x0000000000a03904 0.71% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x0000000000b00d30 0.68% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x00000000009eea59 It looks like most of the time is spent in a tight loop getting the clock and yielding. Most of the time is spent outside of kwin_x11 but filtering by dso shows where it is involved: # dso: kwin_x11 # # Total Lost Samples: 0 # # Samples: 5K of event 'cpu_atom/cycles/Pu' # Event count (approx.): 2421254389 # # Overhead Command Symbol # ........ ............... ............................................................................................................... # 0.12% kwin_x11 [.] KWin::BlendChanges::isActive 0.07% kwin_x11 [.] QtPrivate::QCallableObject<void (KWin::ZoomEffect::*)(), QtPrivate::List<>, void>::impl 0.04% kwin_x11 [.] KWin::OutputFrame::presented@plt 0.03% vsync event mon [.] std::chrono::_V2::steady_clock::now@plt 0.03% kwin_x11 [.] KWin::ApplicationX11::metaObject 0.03% kwin_x11 [.] KWin::ContrastEffect::shouldContrast 0.03% kwin_x11 [.] KWin::ContrastEffect::doContrast 0.02% kwin_x11 [.] KWin::ZoomEffect::slotWindowDamaged 0.02% kwin_x11 [.] KWin::GlxLayer::doBeginFrame 0.02% kwin_x11 [.] KWin::PaintData::yTranslation@plt 0.02% kwin_x11 [.] KWin::BlurEffect::blurRegion 0.02% kwin_x11 [.] KWin::EffectsHandler::prePaintScreen@plt 0.02% kwin_x11 [.] KWin::ContrastEffect::isActive 0.02% kwin_x11 [.] KWin::EffectWindow::isDesktop@plt 0.02% kwin_x11 [.] KWin::ContrastEffect::drawWindow 0.02% kwin_x11 [.] KWin::GlxBackend::primaryLayer 0.02% kwin_x11 [.] KWin::SlideEffect::isActive 0.02% kwin_x11 [.] QRegion::end@plt 0.02% vsync event mon [.] KWin::SGIVideoSyncVsyncMonitorHelper::poll 0.02% kwin_x11 [.] KWin::OutputLocatorEffect::isActive 0.01% vsync event mon [.] operator delete@plt 0.01% kwin_x11 [.] KWin::GlxBackend::makeCurrent 0.01% vsync event mon [.] QMetaObject::activate@plt 0.00% vsync event mon [.] QtPrivate::QCallableObject<void (KWin::SGIVideoSyncVsyncMonitorHelper::*)(), QtPrivate::List<>, void>::impl # Samples: 1M of event 'cpu_core/cycles/Pu' # Event count (approx.): 737751025988 # # Overhead Command Symbol # ........ ............... ..................................................................................................................................................................................................................................................................................... ..................................................................................................................................................................... # 0.01% kwin_x11 [.] KWin::BlurEffect::blurRegion 0.00% kwin_x11 [.] KWin::GlxBackend::present 0.00% kwin_x11 [.] KWin::BlurEffect::prePaintWindow 0.00% kwin_x11 [.] QRegion::~QRegion@plt 0.00% kwin_x11 [.] KWin::BlurEffect::blur 0.00% kwin_x11 [.] KWin::GlxBackend::present 0.00% kwin_x11 [.] KWin::GlxBackend::doBeginFrame 0.00% kwin_x11 [.] KWin::GlxContext::makeCurrent 0.00% vsync event mon [.] KWin::SGIVideoSyncVsyncMonitorHelper::poll 0.00% vsync event mon [.] std::chrono::_V2::steady_clock::now@plt 0.00% kwin_x11 [.] KWin::GlxBackend::vblank 0.00% kwin_x11 [.] KWin::ContrastEffect::contrastRegion 0.00% kwin_x11 [.] KWin::ScreenShotEffect::isActive 0.00% kwin_x11 [.] QtPrivate::QCallableObject<void (KWin::VsyncMonitor::*)(std::chrono::duration<long, std::ratio<1l, 1000000000l> >), QtPrivate::List<std::chrono::duration<long, std::ratio<1l, 1000000000l> > >, void>::impl 0.00% kwin_x11 [.] KWin::X11Output::renderLoop 0.00% kwin_x11 [.] KWin::BlurEffect::prePaintScreen 0.00% kwin_x11 [.] QTimer::isActive@plt 0.00% kwin_x11 [.] KWin::KscreenEffect::isActive 0.00% kwin_x11 [.] QRegion::intersects@plt 0.00% kwin_x11 [.] KWin::OutputFrame::presented@plt 0.00% kwin_x11 [.] KWin::OverlayWindowX11::isVisible 0.00% kwin_x11 [.] KWin::OutputLocatorEffect::isActive 0.00% kwin_x11 [.] QRegion::QRegion@plt 0.00% kwin_x11 [.] KWin::ContrastEffect::shouldContrast 0.00% kwin_x11 [.] std::_Hashtable<KWin::EffectWindow*, std::pair<KWin::EffectWindow* const, KWin::BlurEffectData>, std::allocator<std::pair<KWin::EffectWindow* const, KWin::BlurEffectData> >, std::__detail::_Select1st, std::equal_to<KWin::EffectWindow*>, std::hash<KWin::EffectWindow*>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::find 0.00% kwin_x11 [.] KWin::GlxBackend::endFrame 0.00% kwin_x11 [.] std::__detail::_Map_base<KWin::Output*, std::pair<KWin::Output* const, KWin::BlurRenderData>, std::allocator<std::pair<KWin::Output* const, KWin::BlurRenderData> >, std::__detail::_Select1st, std::equal_to<KWin::Output*>, std::hash<KWin::Output*>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true>, true>::operator[] 0.00% kwin_x11 [.] KWin::GlxPixmapTexture::onDamage Is this caused by the blur effects of plasma and konsole?
same here on plasma 6.1.2 on X11
(In reply to Kai Krakow from comment #36) > Is this caused by the blur effects of plasma and konsole? It may have been resolved, at least partially, by https://github.com/NVIDIA/open-gpu-kernel-modules/commit/1795a8bb20fe09f9939ca3e82d76791f5741e467. It mentions KDE here: https://www.nvidia.com/Download/driverResults.aspx/228410/en-us/ I'm using the 555 driver, and since the update, high CPU usage /while/ using the system has gone down.
Hi, Actual Results: kscreenlocker_greet consumes 80-90% CPU. System performance degrades. Increased power consumption and fan activity. Logs and Diagnostics: ps aux --sort=-%cpu | head -10 shows kscreenlocker_greet at the top with high CPU usage, while the screen is locked. Command: top -b -i Output: 1857 root 20 0 24.5g 278128 147164 R 80.1 0.6 119:01.30 Xorg (80.1% cpu usage) System Information: OS: Arch Linux x86_64 Host: Lenovo ThinkPad T15g Gen 1 Kernel: 6.9.9-arch1-1 Shell: fish 3.7.1 Resolution: 2560x1440 DE: Plasma 6.1.2 WM: KWin Theme: Breeze-Dark [GTK2], Breeze [GTK3] Icons: breeze-dark [GTK2/3] Terminal: yakuake CPU: Intel i9-10885H (16) @ 5.300GHz GPU: NVIDIA GeForce RTX 2070 SUPER Mobile / Max-Q (nvidia: 555.58.02) The new driver update didn't help.
I can confirm that I'm having the same problem on Fedora 40 with Plasma 6.1.3.
I don't think it's specific to kwin. I'm having the same issue on Wayland session, plasmashell and kwin_wayland both have high CPU usage.
Another confirmation, both with and without an external monitor connected. Happens both when display is visible and when it's powered off. CPU usages (from `top` over SSH): kwin_x11 ~70-75%, Xorg.bin ~50%, ksmserver ~15%, kscreenlocker_g ~10% Software: * OS: openSUSE Tumbleweed (20240807) * KDE Plasma Version: 6.1.3 (package: 6.1.3-1.1) * KDE Frameworks Version: 6.4.0 * Qt Version: 6.7.2 * Kernel Version: 6.10.3-1-default (64bit) Hardware: * Framework 16 laptop (AMD Ryzen 9 7940HS, with Radeon 780M integrated graphics) * Display: 2560x1600 (external monitor: 1920x1200, connected with DVI->HDMI through a KVM switch)
Switching to a TTY (e.g. Ctrl+Alt+F1) also fixes the CPU usage here. Interestingly (didn't see this mentioned yet) it *stays fixed* when switching back to the TTY that has the locked X/KDE session! Unlocking and re-locking the session makes it reappear.
It looks like on my system it spends *a lot* of time in QPlatformClipboard::emitChanged, full backtrace: #0 QPlatformClipboard::emitChanged (this=0x561ea0b792a0, mode=QClipboard::Clipboard) at /usr/src/debug/qt6-base/qtbase/src/gui/kernel/qplatformclipboard.cpp:87 #1 0x0000715a5cfc6b11 in SystemClipboard::setMimeData (this=0x561ea1d6fd50, data=0x561ea0f7d260, mode=QClipboard::Clipboard) at /usr/src/debug/plasma-workspace/plasma-workspace-6.1.4/klipper/systemclipboard.cpp:112 #2 Klipper::setClipboard (this=this@entry=0x561ea1da6ef0, item=..., mode=mode@entry=2, updateReason=updateReason@entry=Klipper::ClipboardUpdateReason::PreventEmptyClipboard) at /usr/src/debug/plasma-workspace/plasma-workspace-6.1.4/klipper/klipper.cpp:688 #3 0x0000715a5cfc6fba in Klipper::slotReceivedEmptyClipboard (this=0x561ea1da6ef0, mode=QClipboard::Clipboard) at /usr/src/debug/plasma-workspace/plasma-workspace-6.1.4/klipper/klipper.cpp:544 #4 0x0000715a95ba16f7 in QtPrivate::QSlotObjectBase::call (this=<optimized out>, r=<optimized out>, a=<optimized out>, this=<optimized out>, r=<optimized out>, a=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobjectdefs_impl.h:469 #5 doActivate<false> (sender=<optimized out>, signal_index=<optimized out>, argv=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:4086 #6 0x0000715a5cfdbb51 in SystemClipboard::receivedEmptyClipboard (this=0x561ea1d6fd50, _t1=QClipboard::Clipboard) at /usr/src/debug/plasma-workspace/build/klipper/libklipper_common_static_autogen/include/moc_systemclipboard.cpp:210 #7 SystemClipboard::checkClipData (this=0x561ea1d6fd50, mode=QClipboard::Clipboard) at /usr/src/debug/plasma-workspace/plasma-workspace-6.1.4/klipper/systemclipboard.cpp:155 #8 0x0000715a95ba16f7 in QtPrivate::QSlotObjectBase::call (this=<optimized out>, r=<optimized out>, a=<optimized out>, this=<optimized out>, r=<optimized out>, a=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobjectdefs_impl.h:469 #9 doActivate<false> (sender=<optimized out>, signal_index=<optimized out>, argv=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:4086 #10 0x0000715a9691db01 in KSystemClipboard::changed (this=<optimized out>, _t1=<optimized out>) at /usr/src/debug/kguiaddons/build/src/KF6GuiAddons_autogen/include/moc_ksystemclipboard.cpp:142 #11 0x0000715a95ba16f7 in QtPrivate::QSlotObjectBase::call (this=<optimized out>, r=<optimized out>, a=<optimized out>, this=<optimized out>, r=<optimized out>, a=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobjectdefs_impl.h:469 #12 doActivate<false> (sender=<optimized out>, signal_index=<optimized out>, argv=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:4086 #13 0x0000715a961a1a7f in QClipboard::changed (this=0x561ea120f5a0, _t1=<optimized out>) at /usr/src/debug/qt6-base/build/src/gui/Gui_autogen/include/moc_qclipboard.cpp:181 #14 QClipboard::emitChanged (this=0x561ea120f5a0, mode=QClipboard::Clipboard) at /usr/src/debug/qt6-base/qtbase/src/gui/kernel/qclipboard.cpp:558 #15 QPlatformClipboard::emitChanged (this=<optimized out>, mode=QClipboard::Clipboard) at /usr/src/debug/qt6-base/qtbase/src/gui/kernel/qplatformclipboard.cpp:89 #16 QPlatformClipboard::emitChanged (this=<optimized out>, mode=QClipboard::Clipboard) at /usr/src/debug/qt6-base/qtbase/src/gui/kernel/qplatformclipboard.cpp:86 #17 0x0000715a95ba16f7 in QtPrivate::QSlotObjectBase::call (this=<optimized out>, r=<optimized out>, a=<optimized out>, this=<optimized out>, r=<optimized out>, a=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobjectdefs_impl.h:469 #18 doActivate<false> (sender=<optimized out>, signal_index=<optimized out>, argv=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:4086 #19 0x0000715a96f3e596 in ffi_call_unix64 () at ../src/x86/unix64.S:104 #20 0x0000715a96f3b00e in ffi_call_int (cif=cif@entry=0x7ffc45d71330, fn=<optimized out>, rvalue=<optimized out>, avalue=<optimized out>, closure=closure@entry=0x0) at ../src/x86/ffi64.c:673 #21 0x0000715a96f3dbd3 in ffi_call (cif=cif@entry=0x7ffc45d71330, fn=<optimized out>, rvalue=rvalue@entry=0x0, avalue=avalue@entry=0x7ffc45d71400) at ../src/x86/ffi64.c:710 #22 0x0000715a984fe860 in wl_closure_invoke (closure=closure@entry=0x715a6c003900, target=<optimized out>, target@entry=0x561ea1f94fe0, opcode=opcode@entry=2, data=<optimized out>, flags=1) at ../wayland-1.23.0/src/connection.c:1228 #23 0x0000715a984ff0d9 in dispatch_event (display=display@entry=0x561ea0a22d50, queue=queue@entry=0x561ea0a22e48) at ../wayland-1.23.0/src/wayland-client.c:1670 #24 0x0000715a984ff4f3 in dispatch_queue (display=0x561ea0a22d50, queue=0x561ea0a22e48) at ../wayland-1.23.0/src/wayland-client.c:1816 #25 wl_display_dispatch_queue_pending (display=0x561ea0a22d50, queue=0x561ea0a22e48) at ../wayland-1.23.0/src/wayland-client.c:2058 #26 0x0000715a9774c456 in QtWaylandClient::QWaylandDisplay::qt_static_metacall (_o=<optimized out>, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>) at /usr/src/debug/qt6-wayland/qtwayland/src/client/qwaylanddisplay.cpp:227 #27 0x0000715a95ba194a in doActivate<false> (sender=<optimized out>, signal_index=<optimized out>, argv=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:4098 #28 0x0000715a95da2d05 in QAbstractEventDispatcher::awake (this=0x561ea0b89cc0) at /usr/src/debug/qt6-base/build/src/corelib/Core_autogen/include/moc_qabstracteventdispatcher.cpp:158 #29 QEventDispatcherGlib::processEvents (this=0x561ea0b89cc0, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:401 #30 0x0000715a95b4f01e in QEventLoop::processEvents (this=0x7ffc45d717c0, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventloop.cpp:100 #31 QEventLoop::exec (this=0x7ffc45d717c0, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventloop.cpp:182 #32 0x0000715a95b4934d in QCoreApplication::exec () at /usr/src/debug/qt6-base/qtbase/src/corelib/global/qflags.h:74 #33 0x0000715a97af83ba in QApplication::exec () at /usr/src/debug/qt6-base/qtbase/src/widgets/kernel/qapplication.cpp:2555 #34 0x0000561e686d7d86 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/plasma-workspace/plasma-workspace-6.1.4/shell/main.cpp:188
kwin spins in: Thread 1 "kwin_wayland" hit Breakpoint 4, wl_client_connection_data (fd=<optimized out>, mask=<optimized out>, data=0x5e5ad315a060) at ../wayland-1.23.0/src/wayland-server.c:409 409 if (!(resource_flags & WL_MAP_ENTRY_LEGACY) && (gdb) print message $39 = (const struct wl_message *) 0x70fce9d254d8 <zwp_primary_selection_source_v1_requests.lto_priv+24> (gdb) bt #0 wl_client_connection_data (fd=<optimized out>, mask=<optimized out>, data=0x5e5ad315a060) at ../wayland-1.23.0/src/wayland-server.c:409 #1 0x000070fce7c7f0a2 in wl_event_loop_dispatch (loop=0x5e5ad213aea0, timeout=<optimized out>) at ../wayland-1.23.0/src/event-loop.c:1105 #2 0x000070fce9a767fa in KWin::Display::dispatchEvents (this=<optimized out>) at /usr/src/debug/kwin/kwin-6.1.4/src/wayland/display.cpp:121 #3 0x000070fce6fa16f7 in QtPrivate::QSlotObjectBase::call (this=<optimized out>, r=<optimized out>, a=<optimized out>, this=<optimized out>, r=<optimized out>, a=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobjectdefs_impl.h:469 #4 doActivate<false> (sender=<optimized out>, signal_index=<optimized out>, argv=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:4086 #5 0x000070fce6faa850 in QSocketNotifier::activated (this=0x5e5ad2fef0b0, _t1=..., _t2=<optimized out>, _t3=...) at /usr/src/debug/qt6-base/build/src/corelib/Core_autogen/include/moc_qsocketnotifier.cpp:195 #6 QSocketNotifier::event (this=0x5e5ad2fef0b0, e=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qsocketnotifier.cpp:327 #7 0x000070fce80fc51c in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x5e5ad2fef0b0, e=0x7ffd58556eb0) at /usr/src/debug/qt6-base/qtbase/src/widgets/kernel/qapplication.cpp:3287 #8 0x000070fce6f44d28 in QCoreApplication::notifyInternal2 (receiver=0x5e5ad2fef0b0, event=0x7ffd58556eb0) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qcoreapplication.cpp:1142 #9 0x000070fce70c5b60 in QCoreApplication::sendEvent (receiver=<optimized out>, event=0x7ffd58556eb0) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qcoreapplication.cpp:1583 #10 QEventDispatcherUNIXPrivate::activateSocketNotifiers (this=this@entry=0x5e5ad20c26a0) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventdispatcher_unix.cpp:251 #11 0x000070fce70c6676 in QEventDispatcherUNIX::processEvents (this=<optimized out>, flags=..., flags@entry=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventdispatcher_unix.cpp:467 #12 0x000070fce79f9693 in QUnixEventDispatcherQPA::processEvents (this=<optimized out>, flags=...) at /usr/src/debug/qt6-base/qtbase/src/gui/platform/unix/qunixeventdispatcher.cpp:27 #13 0x000070fce6f4f01e in QEventLoop::processEvents (this=0x7ffd58557090, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventloop.cpp:100 #14 QEventLoop::exec (this=0x7ffd58557090, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventloop.cpp:182 #15 0x000070fce6f4934d in QCoreApplication::exec () at /usr/src/debug/qt6-base/qtbase/src/corelib/global/qflags.h:74 #16 0x000070fce80f83ba in QApplication::exec () at /usr/src/debug/qt6-base/qtbase/src/widgets/kernel/qapplication.cpp:2555 #17 0x00005e5ac5684035 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/kwin/kwin-6.1.4/src/main_wayland.cpp:639
The issue with kwin_11 occurs after connecting a second monitor: when entering sleep mode, the kwin_11 process utilizes around 90% of the CPU, and this happens constantly. If you terminate this process, it will restart as soon as the second monitor attempts to disconnect and reconnect. As a result, xOrg doesn't function properly, and Wayland is still underdeveloped, leaving us with the current situation.
This still happens on 6.2.0. Version info: * OS: openSUSE Tumbleweed (20241007) * KDE Plasma Version: 6.2.0 (package: 6.2.0-1.1) * KWin: 6.2.0-1.1 * KDE Frameworks Version: 6.6.0 * Qt Version: 6.7.3 * Kernel Version: 6.11.2-1-default (64bit) @Kevin Krammer: as this also seems to happen on Wayland (as per comments of Vasily Khoruzhick), might it be useful to adjust the title to reflect this? (as AFAIK X11 gets low(er) priority)
I experience the same behavior running Plasma 6.2.0 on Fedora 40 in a qemu VM with virtio or QXL GPU. Just opening a System monitor or Firefox makes kwin_wayland load almost all CPU cores. No such problem when running on bare metal with NVIDIA GT1030 GPU with proprietary driver v.560.36.03. Plasma 6.0 works fine both in VM and on bare metal.
I'm also still having this issue on my Laptop and Desktop. Laptop running Arch Linux + KDE Plasma 6.2.2 on Intel i5 8th gen and iGPU without external monitor. Desktop running Arch Linux + KDE Plasma 6.2.2 on AMD Ryzen 5 3600 + AMD RX 5700. Killing kwin_x11 and restarting it solves the issue temporarily.
Same CPU load issue when screen is locked. Debian testing (Plasma 6.2.3, framework 6.6.0, Qt 6.7.2, kernel 6.11.10, X11, AMD 7840U with iGPU). Disabling compositing (W/A found here: https://unix.stackexchange.com/questions/782688/kde-lockscreen-kscreenlocker-greet-high-cpu-usage) helped in my case, the CPU load is then negligible and no crazy fan noise. But I'm not sure it solves the root issue, it may just make it less CPU expensive. The following things seem to have an impact: 1) external screen on or off; 2) screen power saving when locked; 3) compositor on or off. At first, I had two screens with compositor on. Then systematically, when locking the screen the following happens: - power saving flip-flop: the screens go into power saving (turned off), then quickly turn back on. This cycle repeats; - the CPU load increases, the fan gets loud. Turning off the external screen doesn't help in this case, same issue with just the internal one. Turning the compositor off as recommended in the previous link helps with the CPU load. But the power state flip-flop still happens. Then turning the external screen fixes the flip-flop too. With both only laptop screen and compositor off, the internal screen goes into low power and remains there. No load, no fan noise.
One more test: in my case switching to Wayland makes both issues disappear. No more high CPU load, and the screen remain in low-power (no constant flip-flopping). For others it was not the case, so there may be different issues with the same result, high CPU load with screen(s) locked.
For me the issue went away eventually, possibly by upgrading some packages. For reference, I'm now on Plasma 6.2.4, Qt 6.8.0 and Xorg 21.1.14. It might be worth confirming if other people are still having the issue on those versions, or only on lower version numbers (in which case upgrading might fix the problem).
Problem still persists for me on 6.2.4/Neon 24.04/X11.
It has been a couple of weeks since I don't find this issue anymore. Latest Arch packages, 3 monitors (2 connected to iGPU 9700x and 1 to 4060ti), X11
The issue is still here on my laptop with Arch Linux and the latest packages, right now, this is: Operating System: Arch Linux KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 Kernel Version: 6.12.4-arch1-1 (64-bit) Graphics Platform: X11 Processors: 16 × 12th Gen Intel® Core™ i7-1270P Memory: 31.1 GiB of RAM Graphics Processor: Mesa Intel® Iris® Xe Graphics Manufacturer: LENOVO Xorg: 21.1.14
Still an issue here as well: * OS: openSUSE Tumbleweed (20241215) * KDE Plasma Version: 6.2.4 (package: 6.2.4-1.2) * KWin: 6.2.4-2.1 * KDE Frameworks Version: 6.9.0 * Qt Version: 6.8.1 * X11: 21.1.14-3.1 * Kernel Version: 6.11.8-1.1 (64bit)
The issue is still here on my laptop with Fedora 41 and the latest packages, right now, this is: Operating System: Fedora Linux 41 (KDE Plasma) x86_64 KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 Kernel Version: 6.12.6-200.fc41.x86_64 (64-bit) Graphics Platform: X11 Processors: AMD Ryzen 5 5500U with Radeon Graphics (12) @ 2.100GHz Memory: 16 GiB of RAM Graphics Processor: AMD ATI 03:00.0 Lucienne Manufacturer: DELL
This is still a problem for me with: KDE Neon 6.2/24.04/X11 Plasma: 6.2.4 Frameworks: 6.9.0 Qt: 6.8.1 Kernel: 6.9.3-76060903-generic (64-bit) Graphics: Mesa Intel® Graphics, Intel Corporation Raptor Lake-S UHD Graphics (rev 04) I see similar issues to Maks Verver in that other KDE processes go to 3-8% CPU such as all Akonadi processes, KMail, kded6, Konversation, etc. All these processes sit at 0% CPU when screen isn't locked. This happens with the internal display (laptop) or external display over HDMI. For the record, the external display is an LG 32UG650K
Same issue here. KDE Framworks 6.9.0 Qt 6.8.1 Kernel 6.12.8-1-default AMD Ryzen 7 PRO 6850U with Radeon Graphics openSUSE Tubleweed as of today
I have the same issue with the fan going crazy as soon as I lock the screen on my framework 16 (AMD Ryzen 7040 Series). Operating System: Arch Linux KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 Kernel Version: 6.12.8-arch1-1 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 9 7940HS w/ Radeon 780M Graphics Memory: 30,7 GiB of RAM Graphics Processor: AMD Radeon 780M Manufacturer: Framework Product Name: Laptop 16 (AMD Ryzen 7040 Series) System Version: AJ Disabling the composition also fix the issue.
FWIW, disabling the compositor makes the issue go away here. For now that's a workaround I can live with.
Disabling the compositor doesn't go away for me (Manjaro, 8 × AMD Ryzen 7 4700U with Radeon Graphics, kwin-6.2.4-2). Can we raise the severity of this bug? It's having some actual impact on my hardware. If I leave the laptop I find it warm with the fan hard at work when locked. I know that can be inferred from "high CPU load", but a regression like that (without a workaround) is quite severe for the affected users IMO. I guess we're not that many, given the response rate here, but still.
(In reply to pditchev from comment #62) > Can we raise the severity of this bug? Agreed that for a laptop this is worse. > without a workaround Workaround that seems to work reliably for most people is to restart kwin_x11 once per session. I do this with $ kill $(pidof kwin_x11) There is likely also a systemctl to do this "nicely"
Thanks, I tried the workaround when it was first posted but the effect didn't seem to work every time or for the whole session. But it may've been my mistake, currently it seems to be working. Here's my updated "Fix KDE bugs" script that I keep in the side panel: `killall plasmashell && killall kwin_x11 && (kwin_x11 --replace &) && (plasmashell &)`
The root cause is likely the same as in bug 489230
(In reply to Kevin Krammer from comment #63) > (In reply to pditchev from comment #62) > > > Can we raise the severity of this bug? > > Agreed that for a laptop this is worse. > > > without a workaround > > Workaround that seems to work reliably for most people is to restart > kwin_x11 once per session. > > I do this with > > $ kill $(pidof kwin_x11) > > There is likely also a systemctl to do this "nicely" There was a user unit `plasma-kwin_x11.service` provided by kwin $ systemctl cat --user plasma-kwin_x11.service # /usr/lib/systemd/user/plasma-kwin_x11.service [Unit] Description=KDE Window Manager After=plasma-kcminit.service PartOf=graphical-session.target [Service] ExecStart=/usr/bin/kwin_x11 --replace BusName=org.kde.KWin Slice=session.slice Restart=on-failure
(In reply to JimMoen from comment #66) > (In reply to Kevin Krammer from comment #63) > > (In reply to pditchev from comment #62) > > > > > Can we raise the severity of this bug? > > > > Agreed that for a laptop this is worse. > > > > > without a workaround > > > > Workaround that seems to work reliably for most people is to restart > > kwin_x11 once per session. > > > > I do this with > > > > $ kill $(pidof kwin_x11) > > > > There is likely also a systemctl to do this "nicely" > > There was a user unit `plasma-kwin_x11.service` provided by kwin Right, restarting the unit via systemctl would probably be nicer than killing the process and waiting for systemd to restart it :) Probably something like systemctl --user restart plasma-kwin_x11.service
Still happening with plasma 6.3 Updated my fedora 41 using sudo dnf upgrade --refresh --advisory=FEDORA-2025-c1fc288a4c OS: Fedora Linux 41 (KDE Plasma) x86_64 Host: Inspiron 15 3525 1.12.0 Kernel: 6.12.11-200.fc41.x86_64 Uptime: 5 mins Packages: 2727 (rpm), 17 (flatpak) Shell: bash 5.2.32 Resolution: 1920x1080, 1920x1080 DE: Plasma 6.3.0 WM: KWin Theme: Breeze [GTK2/3] Icons: breeze-dark [GTK2/3] Terminal: konsole CPU: AMD Ryzen 5 5500U with Radeon Graphics (12) @ 2.100GHz GPU: AMD ATI 03:00.0 Lucienne Memory: 6085MiB / 15324MiB
Having the same issue. (Manjaro Linux, updated today, KDE Plasma 6.2.5, KDE framework 6.10.0, Qt 6.8.2, X11, kernel 6.12.12-2-manjaro, Framework Laptop 16 AMD Ryzen 9 7940HS w/ Radeon 780M)
(In reply to strank from comment #69) > Having the same issue. > > (Manjaro Linux, updated today, KDE Plasma 6.2.5, KDE framework 6.10.0, Qt > 6.8.2, X11, kernel 6.12.12-2-manjaro, Framework Laptop 16 AMD Ryzen 9 7940HS > w/ Radeon 780M) and can confirm that > systemctl --user restart plasma-kwin_x11.service once is a viable workaround. As is switching to a different tty with Ctrl-Alt-F1 while the screen is locked.
It may be a long shot, but is anyone else having keyboard issues at the same time? I'm having keys not react or trigger several times in some instances. Most likely it's a coincidence, but still.
Not keyboard, but sometimes when the screen layout changes it seems like the mouse doesn't work properly; trying to click on menus and menu items doesn't work properly. Moving the window to a different screen and back seems to fix it. The `kwin --replace` trick doesn't always fix that. So I'm tempted to say different problem...
(In reply to Marcelo Vanzin from comment #72) > Not keyboard, but sometimes when the screen layout changes it seems like the > mouse doesn't work properly; trying to click on menus and menu items doesn't > work properly. Moving the window to a different screen and back seems to fix > it. I have found that the mouse events seem to go to a different application that is on the same screen but on a different activity. I.e. when I move the mouse over a window in this "unresponsive" state I can see the cursor change form when the "other window" has special elements like input fields (input cursor) or things that can be moved/resized or clicked. For me ALT-Tab (even when there is only one window) works as well to bring the mouse to the currently displayed windows. I can also click the window's entry in the task bar. Not related to this bug though. One of us should create a new one :)
(In reply to pditchev from comment #71) > It may be a long shot, but is anyone else having keyboard issues at the same > time? I'm having keys not react or trigger several times in some instances. > Most likely it's a coincidence, but still. Actually, I do have a similar problem. When using Fedora 41 KDE spin in a KVM VM (virt-manager) with a SPICE display, something strange happens. Right after boot, everything works fine. Then, after a few times I switch in and out of full-screen mode, key presses in KDE apps start to register funny: when in full-screen mode, after pressing a key (in a Konsole for example) it is not rendered. If I press another key, now both symbols are rendered. If I then switch VM out of full-screen mode, then all key presses are handled just fine. Going back to full-screen mode, the same problem appears. What's interesting, typing within Firefox window works fine all the time, even in a full-screen mode, so it doesn't look like a KVM/SPICE/virt-manager problem to me.
Adding the x11-only keyword
I can confirm that the bug is still present in Plasma 6.3.1
I have the same issue. 2 weeks ago, I freshly installed Tuxedo OS on my Laptop XMG FUSION 15 and the same problem was there from the beginning. When locked -> high CPU, loud fan noise I am using X11 with compositor on and one external monitor over HDMI. Turning off compositor does make a difference when locking the laptop -> no high CPU usage, no loud fans. I can't say much about the flip flop of energy saving states. It should be further investigated. But then shortcuts like "Overview" or "Present all open windows" does not work anymore (when compositor off), which completely destroys my process of working. Is there another way to see all open windows in one view? Output of top when locked > PID USER PRI NI VIRT RES SHR S CPU%▽MEM% TIME+ Command > 11677 comput 20 0 1344M 221M 161M R 61.2 1.4 1:55.63 /usr/bin/kwin_x11 --replace > 11405 root 20 0 24.9G 334M 141M S 37.1 2.1 2:22.16 /usr/lib/xorg/Xorg -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_SOHFlf -noreset -displayfd 18 > 11699 comput 20 0 1344M 221M 161M S 12.7 1.4 0:24.01 /usr/bin/kwin_x11 --replace > 11674 comput 20 0 429M 121M 104M S 5.2 0.8 0:07.86 /usr/bin/ksmserver > 16253 comput 20 0 13444 6744 3672 R 3.9 0.0 0:00.40 htop kinfo: Operating System: TUXEDO OS KDE Plasma Version: 6.3.2 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.11.0-109018-tuxedo (64-bit) Graphics Platform: X11 Processors: 12 × Intel® Core™ i7-9750H CPU @ 2.60GHz Memory: 15.3 GiB of RAM Graphics Processor 1: NVIDIA GeForce GTX 1660 Ti Graphics Processor 2: Intel® UHD Graphics 630
I've also been hit by this just recently. Until a few weeks ago, my system has been using ~10W when locked, but then suddenly went up to ~30W and also using noticeable more energy during active sessions. Due to me using Activities quite heavily for separating work and relying on Window positions being remembered when starting a session (too many to rearrange each time, some Activities rarely used but needed to be ready more or less immediately) I am still stuck with X11. The workaround by restarting the kwin_x11 session seems to bring things down again: Before the restart: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2190 ancoron 20 0 2455276 332072 207072 R 55.8 0.5 237:11.75 kwin_x11 1327 root 20 0 1852308 311340 214628 R 55.1 0.5 234:34.89 Xorg 4167 ancoron 20 0 12.8g 1.5g 899652 S 32.5 2.5 212:11.38 firefox 2187 ancoron 20 0 1277916 109744 90072 S 20.6 0.2 69:13.05 ksmserver 408329 ancoron 20 0 2551588 374300 251044 R 12.9 0.6 0:05.73 kscreenlocker_g 2231 ancoron 20 0 9659056 923244 286388 S 7.3 1.5 47:44.18 plasmashell 2528 ancoron 20 0 1725804 184116 105676 S 7.3 0.3 25:33.37 konsole 2482 ancoron 20 0 4887388 252068 135864 S 7.0 0.4 56:06.71 mozillavpn 2543 ancoron 20 0 2481168 529312 142440 S 6.6 0.9 36:03.31 dolphin 2538 ancoron 20 0 1656656 153904 100448 S 6.3 0.2 21:29.53 konsole 2539 ancoron 20 0 3230860 412736 250708 S 6.3 0.7 25:13.41 dolphin 2678 ancoron 20 0 4154704 435680 131948 S 6.3 0.7 35:09.29 kate 2541 ancoron 20 0 2134452 147880 102200 S 6.0 0.2 21:20.03 dolphin 2574 ancoron 20 0 1872240 201720 123780 S 6.0 0.3 20:12.27 kate 2058 ancoron 20 0 590128 55104 46460 S 5.6 0.1 19:40.83 kactivitymanage After restart: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4167 ancoron 20 0 12.7g 1.4g 880080 S 1.3 2.4 212:19.76 firefox 208660 ancoron 20 0 2868792 406272 205868 S 1.3 0.7 6:10.32 Isolated Web Co 396466 ancoron 20 0 3371708 636424 321000 S 1.3 1.0 0:49.65 thunderbird 2360 ancoron 20 0 549504 43372 35528 S 1.0 0.1 25:17.61 ksystemstats 2482 ancoron 20 0 4887408 253476 135864 S 1.0 0.4 56:08.27 mozillavpn 2569 ancoron 20 0 3148944 186412 108760 S 1.0 0.3 19:41.54 kate 323264 ancoron 20 0 3091408 570516 236376 S 1.0 0.9 4:45.75 Isolated Web Co 1327 root 20 0 1840568 311432 214720 S 0.7 0.5 234:41.10 Xorg 2528 ancoron 20 0 1727140 185012 105676 S 0.7 0.3 25:34.97 konsole 4278 ancoron 20 0 27.8g 928912 177692 S 0.7 1.5 75:02.53 WebExtensions 18 root -2 0 0 0 0 I 0.3 0.0 3:12.54 rcu_preempt 87 root rt 0 0 0 0 S 0.3 0.0 1:30.73 migration/11 1268 root 20 0 2389328 56792 39140 S 0.3 0.1 3:19.20 containerd 2015 ancoron 20 0 8596 3944 3648 D 0.3 0.0 4:39.95 LCDd 2231 ancoron 20 0 9691848 927388 286664 S 0.3 1.5 47:46.94 plasmashell So I would actually call this a regression, since the system behavior was totally energy-friendly to my system before. Hardware: - Platform: ASRock X300 - CPU: AMD Ryzen 7 5700G - RAM: 64 GIB - Disk: Seagate Firecuda 530 (2TB)