KDE Reduces CPU Usage On Wayland When Moving The Pointer & Other Fixes

[aufkrawall]

GNOME recently completed moving mouse cursor-movement onto its own dedicated thread.

Probably this one:

https://invent.kde.org/plasma/kwin/-/commit/87444f6ce395ed87f3042fcf43f08eaeb2171401

With 6.0-rc1, HW cursor on AMD (VRR off) seems to be free of stutter/lag with both either 100% CPU or GPU load.

[user1]

Nice to see that they've started giving some attention to colord-kde since a year ago or so. Previously it was frozen on the same version for a few years and didn't even work properly in some cases.

On another note, I don't understand what this means:

- Support for setting a custom mouse pointer speed, similar to the touchpad option.

Isn't it already possible in Plasma 5?

[hf_139]

There is really no excuse anymore to use deprecated GNOME.

[hyperchaotic]

How can they call KDE "modern" if there is a busy wait going on?! ...

I fail to see how a bug has anything to do with whether it is "modern". Bugs happen in any software and I can easily forgive such bugs in unreleased software.

[jeisom]

I'm the one that opened the bug, though others have felt the issue as well. So far of all people that mentioned their distro, it was pure Arch, so with Qt6.7 which is not targeted by KDE for now. That could be the reason, or not, I have not looked at the fix yet, nor if it actually is a fix.
I don't know what you mean by HW/SW cursor but I'm happy to try.

I feel it is not even appropriate to report bugs upstream on Arch linux and if I was an upstream developer I’d close bug reports from Arch Linux because of the QT6.7 being used..

[bug77]

I feel it is not even appropriate to report bugs upstream on Arch linux and if I was an upstream developer I’d close bug reports from Arch Linux because of the QT6.7 being used..

It's actually Qt6.7 beta 1 atm.
But why not report, it can still be an issue in the KDE framework. Or if it's really in Qt, KDE devs tend to contribute there, too.

[jeisom]

It's actually Qt6.7 beta 1 atm.
But why not report, it can still be an issue in the KDE framework. Or if it's really in Qt, KDE devs tend to contribute there, too.

Their focus is on Plasma 6.0 with QT6.6. Yes they are contributing to QT6, but how does that help them get Plasma 6.0 with QT6.6 out the door with people reporting bugs regarding the currently nonexistent Plasma 6.1 with QT6.7. If I send in a report with QT6.7beta in use I can’t tell if that is a QT6.7beta issue or a Plasma Beta/RC issue. It would be at this point just noise for 6.0.

[bug77]

Their focus is on Plasma 6.0 with QT6.6. Yes they are contributing to QT6, but how does that help them get Plasma 6.0 with QT6.6 out the door with people reporting bugs regarding the currently nonexistent Plasma 6.1 with QT6.7. If I send in a report with QT6.7beta in use I can’t tell if that is a QT6.7beta issue or a Plasma Beta/RC issue. It would be at this point just noise for 6.0.

Of course you can. If it's reproducible or it includes a backtrace, you can tell. And then you can decide whether you want to do anything about it now or leave it for later.

[varikonniemi]

I'm the one that opened the bug, though others have felt the issue as well. So far of all people that mentioned their distro, it was pure Arch, so with Qt6.7 which is not targeted by KDE for now. That could be the reason, or not, I have not looked at the fix yet, nor if it actually is a fix.
I don't know what you mean by HW/SW cursor but I'm happy to try.

I only found this comment, not the actual command:

KWin uses hardware cursor planes automatically if they're available. You have to use an environment variable to force it to not use hardware cursors.
The explanation of your cursor lag probably lies elsewhere.

[aufkrawall]

I only found this comment, not the actual command:

It's KWIN_FORCE_SW_CURSOR=1. Using it as a workaround for an amdgpu HW cursor VRR bug, and it (finally) works splendidly with KWin 6.
Though let's hope AMD gets their act together so it won't be needed long for that particular use case...