KDE Plasma 5.14's Lock Screen Will No Longer Eat Your CPU Resources On Old Hardware

With KDE Plasma 5 right now it turns out that if you have relied upon CPU-based software rendering, when hitting Plasma's lock-screen it would actually go CPU-wild -- as far as maxing out the CPU to 100% utilization, thereby consuming a lot of power and generating excess heat. That will be fixed for KDE Plasma 5.14.0.

Since May has been a bug report about the KScreenLocker greeter process going to 100% CPU usage and needing to wait 5~10 seconds after entering the user password before the screen would actually unlock. Several others also reported similar issues of this lock-screen managing to consume a lot of the CPU resources, including on ARM boards and older hardware.

But why is a simple lock-screen needing so many CPU resources? These systems were primarily falling back to the software-based LLVMpipe Gallium3D driver for running OpenGL on the CPU. That obviously is quite CPU intensive and only comes up for KDE when the GPU is too old to support OpenGL 2.1 or the GPU drivers not properly setup. But that was happening even if the user tried opting for software rendering via the Plasma settings.

It turns out KScreenLocker was missing the one line of code for picking up the compositor settings like forcing the Qt Quick back-end to use its non-GL software rendering back-end. With that in place and trying to bypass the OpenGL rendering back-end that would only be using LLVMpipe/Softpipe, the lock-screen behaves like one would expect on outdated hardware.

There was that fix and other usability improvements this week in KDE land. Plasma 5.14 is scheduled to debut in October.