Plasmashell and kwin_wayland use lots of CPU if no window is open

Here’s a screenshot of the CPU-load wildly varying (around 0% to around 25%):

The numbers in the screenshot:
Nr. 1 and 2:
Here, plasmashell makes about 100% load and kwin_wayland almost 50% (so, both together are saturating 1.5 CPU-cores).

Nr. 3 and 4:
Here, I have opened some window (e.g. that of Spectacle) … even pulling down yakuake is enough to make the CPU-load magically disappear.

My setup didn’t change:
Intel(R) Core™ i7-6700K CPU @ 4.00GHz
NVIDIA GeForce GTX 1060 6GB
Manjaro KDE (been rollin’ for years)

The recent big Stable-update didn’t cause this, btw (at least, I didn’t notice it, then).

But, I’ve ran another update, today (only a few packages were updated … I don’t exactly remember which ones) and it’s been like this, ever since.

Did I miss something, or is something broken, at the moment?

The issue with the high CPU-load seems to have been resolved.

I got some other strange things happening now, though.

Just a minute ago, I was using brave in fullscreen-mode (watching an embedded video from a local TV-station’s online media-offering). I had another brave-tab opened in the background.

When I left fullscreen-mode, the window-frames of brave were glitching.
First, I wanted to grab the window and force it to resize, by pushing it against the left edge of the screen (so, it’d be resized to fill the left side of the screen).

Then, I noticed the top-frame of the window was glitching (also the buttons on the frames and the scrollbars) and were displayed weirdly.

The buttons (minimize/maximize/close) of the top-frame of the window were glitching as well, because clicking them did nothing.

So, I had to click on the brave-icon in kde’s window-list-bar on the bottom of the screen, in order to minimize brave … and then maximize brave again.

Only after minimizing and restoring the brave-window, the glitches disappeared and the window’s buttons were accessible as expected again.

Still, what I described in my initial post has been resolved, in the meantime, I’m happy about that.

how was it resolved?


I’ll correct my statement:
I thought, it had been resolved.

The problem is not there, directly after a reboot.
But, somehow after using the system for a while, the problem reappears.
At least, it just happened, before I opened the browser-window to write this reply (if at least one window is open, the load is back to almost 0% … same as in my initial post).

I still have no clue, what causes it.
I’m guessing, not every Nvidia+KDE+Wayland-issue has been resolved, yet (only a wild guess … I have no clue if that’s actually true)?

Baloo ?

check with

balooctl6 status 
1 Like
$ balooctl6 status
Baloo ist zurzeit deaktiviert. Zum Aktivieren führen Sie bitte „balooctl enable“ aus

(It’s German and says, baloo is deactivated and i could activate it, if I wanted to).

I remember, that I did deactivate baloo on purpose at some point waaaay back … and if I remember correctly, it had to do with some high CPU load, back in the day, too. But, that was ages ago (I’ve kept this install rolling for a few years, at this point).

I have no clue, what the problem is, but I’m now pretty sure, klipper has something to do with it (“klipper” as in KDE’s clipboard-history, which has an icon in the systray).

I’ve done this 3 times, now … and it worked the same, every time:

  1. I tried to empty the clipboard by clicking the systray icon … klipper-history opens … then clicking on the clear-button (the left-most one among the symbols in the top-right corner).
  2. It didn’t work 100% (last entry was still in there … it should’ve been deleted, too).
  3. Tried to delete that entry (red trashcan icon next to it) … didn’t work.
  4. Tried to edit that entry and erase it’s contents, but that didn’t work as I had intended.
  5. I ended up with the initial item and an additional empty one in the klipper-history.
  6. Clicking that same button, as I described in step 1 (this time, it actually works … seemingly, because the last entry is just an empty string … I have no way to prove it, though).
  7. The CPU-load drastically decreases (from about 25% to actual idle-loads) … so, this is a workaround to my problem.

If anyone knows how to actually fix this issue (once and for all time), I’d happily try to apply your advice :slight_smile: