Screensavers are a relict of the last century. They were required to prevent serious hardware damage on CRT screens. This is even implied by the name: a screensaver saves the screen from damage. Now we live in the second decade of the 21st century and the world has changed. I can’t remember when I last saw a CRT computer screen, they have been completely replaced by LCD screens. LCD screens on the other hand don’t show the danger of burn-ins. They don’t need to be “saved”. Nevertheless we still have screensavers.
Nowadays screen savers are used to indicate that the screen has been locked. It is a way to animate the screenlocker. But is that wise at all? Especially in the current time it is extremly important to save power. This means if a screen is locked the screen should turn itself off, the CPU should go into the lowest power state, the compositor should stop repainting the screen, the GPU should go into the lowest power state and so on and so on. But is that possible if a screen saver is active?
The screensaver implementation in the X11 world is rather dated: XScreenSavers
were first published in 1992. To be honest: most screensavers even look like being from the last century. Now if a screensaver is active, the CPU has to calculate the animation which implies that it cannot be in idle state. The compositor needs to update the screen which means the compositing engine cannot turn itself off. This implies again that the GPU cannot turn itself in the sleep mode and can cause really heavy load if the compositor needs to constantly do full repaints. Last but not least if the system DPMS
is misconfigured the screen will not turn off.
In summary a system will waste power in a situation where it does not need to use any power. It is even possible that (depending on the used screensaver) the system needs more power in the idle state than under usage. Given the world we live in, I want to do something about it. We need to stop wasting power.
The waste of power is not the only disadvantage of the current screen locker system. Several of the existing screensavers have issues as they pre-date the current infrastructure with compositors by years. We have seen that parts of the screen can be leaked which means there can be privacy issues. Even worse is the situation with OpenGL screensavers. They sometimes use ARGB windows and don’t clear the screen (this used to work fine in the pre-compositing era), all areas not repainted by the screensaver are leaked. In case you have a buggy driver it is even likely that either the screensaver or the compositor will not survive that both are used. According to our bug reports this is a common problem. Now driver bugs should be fixed but reality shows: it is not happening.
For the future there is only one obvious solution: the screen locker has to be moved into the compositor. The compositor can ensure that the screen is blanked correctly and not leaking information. If the locker is part of the compositor, it can ensure that the compositing re-paint loop is stopped as long as nothing has to be shown. Only if the unlock dialog is shown the compositor needs to enable repainting and can ensure that everything else except the dialog is blanked. Another small advantage of having the screen locker in the compositor is that we can finally do a nice fade in/out when locking/unlocking the screen.
Removing the screen saver is nothing which will happen for 4.7 as it requires coordinated development. Even if we move screen locking into the compositor we need to ensure that the old architecture is still in place in case KWin is not used or compositing turned off. There is also the Plasmoids on screen locker implementation which is a valid use case and needs to be ported to any new infrastructure. This can become tricky, but I am positive that we will be able to support it. Altogether this is something I want to have for 4.8 and it is something I want to discuss at Tokamak and will make sense to be included in Plasma Active
as we there have the control over the compositor which is used and saving as much power as possible is very important for the targeted devices.
Powered by Blogilo