The New KDE Power Management System – fresh from Madrid
Hello from Madrid, where the last day of Solid sprint has just taken off (well, at least for me).
Yesterday, while you were in your beds, an insane commit hit trunk, bringing to KDE 4.6 the new generation of KDE’s Power Management System, formerly known as PowerDevil.
New name, new features, less code!
PowerDevil has been written quite some years ago, and my not so extensive experience at the time brought to some design flaws which were making the daemon less and less maintainable every release. Hence the need to rework the daemon’s core itself to provide a better and more stable concept. This has lead to the creation of KDE Power Management System. We chose this generic name for making the service more discoverable to the user, but the old PowerDevil name is still kept as in the C++ namespace name in the source code, and in the library files. So KDE Power Management System == PowerDevil.
A completely modular design…
One of the main issues we were facing was that we kept adding features on features, but yet PowerDevil’s code paths were rather complex and extremely modular – breaking something was very easy indeed. PowerDevil’s design is now based on Actions. Actions are a set of plugins which can perform a single power management task: suspending the session, controlling brightness, etc. So right now PowerDevil’s core is just a mere “controller” system, which takes care of triggering actions when needed. The size of the core is less than 1/10th of the previous core, you can tell it’s much more maintainable now.
…which you can obviously extend
If you were guessing, the answer is yes: you can write your own action plugins for PowerDevil and bring your very own power management features to your desktop. This means that, for example, hardware vendors can ship plugins for PowerDevil which are able to trigger power management features in their hardware, or advanced users with C++ knowledge can really make power management as they see fit. Of course the actions available in PowerDevil in KDE 4.5 have been ported to the new structure already.
And a new Config UI
Screenshots are worth a thousand words:
Nicer, isn’t it? It will get some further UI love from Sebastian in the next days to make it really shine, but what is really outstanding is that nothing is hardcoded: all the widgets you see come straight from the actions’ plugins. So yes: if you’re extending powerdevil through plugins, the configuration will actually look exactly like all the others. And you noticed it is now possible to disable actions: so to all the users who requested not to change brightness when switching plugins: here’s to you!
No more Solid::Control
Solid::Control is getting deprecated, so now PowerDevil has its own backends, which are a stripped version of Solid::Control ones, and no longer depends on Solid::Control::PowerManager, which will be hopefully removed for 4.6. An UPower backend is coming and will make its way into 4.6.
Real inhibition features
Ever got pissed off because notifications are cluttering your screen while you’re watching a movie, or your PC is suspending while doing updates, or your screen turns off while you’re in front of the PC? PowerDevil features a brand new Policy Agent, which will allow to have proper inhibition. We are still working on having this feature done right, but I am confident we will bring it to the table for 4.6.
The bad things
Unfortunately (as you can imagine), old PowerDevil profiles are no longer compatible with the new KDE Power Management system, so if you had something fancy you’ll probably need to create your profiles again (or try hacking up a conversion patch). By the way, more sensible defaults will be provided for 4.6, so you should be actually fine without changing profiles at all.
All cool, but does it work?
Trunk already features the new KDE Power Management System, but there are some feature regressions as not everything has been implemented yet, but I can say 80-90% of what’s needed is in. Today we’re going to make the applet play nice with the daemon, and if you want to test all of this goodness, I’d really advise you to wait until tomorrow.
Those are the main things, but many many more small ones have been done/fixed, to improve your desktop usage and not getting in your way. Hopefully I got you interested, so look forward to a vastly improved power management experience in 4.6!
A Quiet Place 
Great job! Looking forward to having that in production.
Can I haz my unit tests though? 😉
I hope the screenshot does not display the default: disabling compositing after a time delay does not make sense at all. In fact for an idle system compositing should be less power consumptive than without compositing. Also remember that disabling compositing means removing features.
I would propuse to completely remove the disable compositing feature from PowerDevil at all or to come up with a solution which allows to disable the costly effects (blur, wobbly, cube). But just assuming that effects require more power is probably just wrong.
@Martin: Well, you could write a nice plugin for disabling costly effects 🙂
What I always wanted to ask is: how does the current PowerDevil and now the new system behave when multiple users are logged in? Especially if both users have conflicting profiles. Is only one instance’s profile enforced or will they get in each others way?
Aren’t separate users logged in on separate X sessions?
Wonderful ! no more silly brightness adjustment !
@Martin: No, I still need to define the defaults. I guess this topic is up for discussion, and we need to have a talk about it so I’m sure I can do the right thing. Btw if you think disabling effects is bad, I’ll remove the action.
@Jan: Both the new one and the old one use ConsoleKit to prevent inactive sessions from modifying powermanagement settings. So the active user’s profiles are applied, whereas all of the other users’ automatic profiles actions are rejected by PowerDevil.
Great news actually I was thinking about KDE powersaving and there are two things that could be done
First , quite simple is ability to manipulate powermanagerment settings on wifi/gfx cards wotking on foss drivers. It’s all done via sysfs, so PM cone should just detect presence of some files in sysfs, echo proper values and provide some gui.
Second thing is turning off compositing, mentioned by Martin.
There are two things to consider, how to make desktop power efficient and how not break desktop workflow in the process.
I believe for now for each profile there should be a list of kwin/compiz plugins plugins to deactivate. It should provide some sensible defaults. I tkhink it shouldn’t touch any accessibility things and present windows/desktop grid effects to preserve desktop functionality.
Ability to tweak thios list should be available in separate tab or under some “advanced” button, so it won’t scare non-tech savvy users.
In the future pm code could provide an option to lower quality or suspend oxygen animation and disable additional kwin animations for pop-up windows, task manager etc…
But I guess it rmight be a bit complicated task.
Great work! I didn’t quite like the old system (lots of options) and I’m happy to see this change 😀 While putting it quite undiplomatic and bluntly, I think Matthew Garrett had good points at the GCDS. (except for removing all options)
One sensible default I would like is “always suspend when closing the lid”. Sometimes I close the lid before pulling the plug, and visa versa. This previously (or currently?) results in either a suspended system, or a boiled laptop in my bag.
The problem with this default is that there’s still a large number of laptops out in the wild that won’t wake up again, and in that case we’re likely destroying data. Some machine won’t even suspend or hibernate correctly (on my machine, both HAL and upower report hibernate to be available, while I don’t even have a swap partition), that would also give us fried laptops for those people that assume that the default settings actually work.
We probably should be conservative here. On the other hand, the new UI is less complex, so it’s easier to find these settings for those with machines that work as advertised.
great but what about cpu (and gpu) policy?? this is most power saving things
CPU and GPU power management is done by the kernel, so we don’t need to take care of that or disclose it in the UI.
but I can change cpufreq-set -g governor_name in terminal, it would be nice to have this in gui working together with powerdevil, (gpu is harder but xf86-video-ati have very nice power saving support, I don’t know about nv and intel)
Regarding the gpu powersaving, propritary drivers for NVidia and Radeons manage powersaving options on their own. I don’t know how it is in ofss intel driver. Radeon pm options are managed from sys-fs level. At this point there’s no userspace bits.Nouveau just recently got some initial work on pm, but I guess it’ll end up in something similar to radeon driver.
It would be great if those options were exposed somwhere in KDE.
It shouldn’t be that difficult to look for some files in sys-fs and echo some preset values into those files.
So I’m not able anymore to force a certain cpu governor for a profile? In quite locations I force my cpu to powersave mode which keeps the fan quite. This is really easy and convenient with current PowerDevil. It would be really annoying if I had to resort to fiddling with the command line again! And no, I’m not keen on writing a plugin myself 😉
I read some time ago about the removal of CPU scaling in PowerDevil due to the discovery of it not actually improving power saving at all, and it’s my own fault for not commenting at the time. However, since the whole system is now being redesigned I should add my own support to the above concerns about this.
The previous discussion suggested that it was not within the scope of PowerDevil to allow somebody to modify the CPU frequency, and that this could be done externally or by calling a script, but I believe there is a use-case that is being overlooked and/or abandoned; that of the user like me who prefers to throttle the CPU and/or brightness and other settings in order to reduce fan noise and laptop heat, but still have the ability to easily change this on-the-fly when watching movies, doing presentations or other CPU-intensive tasks. Indeed, I believe KDE3 even had an ‘Acoustic’ setting in its power options for this purpose.
The argument that it doesn’t achieve any actual power saving due to more time being taken to complete tasks is evidently qualified, and one might even fairly decide that CPU adjustment should fall under the scope of another system setting, but I don’t see any other place in the GUI of KDE that currently provides this and if it isn’t regarded as a power-related setting, where would one expect to find it?
If you believe this can be provided as plug-in functionality that’s a valid suggestion, but I hope this use-case won’t be sidelined completely. Note that this is from the perspective of an ‘average computer user’ who wouldn’t be adept at scripting or the command-line.
@gumb & all the others: I believe there was a misunderstanding on why this feature has been removed. The point is not that we don’t want to provide this feature or the feature itself is outside the scope of PowerDevil, but that the CPU governor feature is nowadays handled by the kernel.
The “ondemand” governor should be able to fit every possible use case, and kernel developers advised us against changing the governor itself. So this is not like “we do not want you to change the governor”, but more like “you don’t need to change the CPU governor”.
Obviously somebody will code a plugin for this soon, but I won’t merge it upstream and I still advise you against using anything which is not “ondemand”.
The reply might be a bit late, but still…
@drfav: This is is probably all correct what you say. Still, as @gumb and myself wrote, there is the need to specify the cpu policy manually. Simply as I fail to see how the kernel should know, that I want my fan to be quiet in a certain situation. So I think this possibility should be part of the core powerdevil and not a 3rd party plugin the user has to install from somewhere or even self compile.
… and honestly, I don’t trust the smartness of the kernel…
this is linux for crying out loud! I don’t need some steve blowjobs who will tell me what and when i should do, if I want to throttle cpu down I just do it
e.g. I use conservative governor rather then ondemand, and there is milion different cpu policys to milion differen tasks and I want to have control which and when and how to use
PS killer feature would be voltage control, undervolting can save much of a battery 😉
Nice work. but what about options “when power/sleep button pressed”? It’s removed?
yes and no, One thing the kernel cant handle, is to change governer when you plug in the power for instance. Which is exactly a feature i would miss and there for i would be forced to have laptop-mode-tools to take care of that.
yes and no, One thing the kernel cant handle, is to change governer when you plug in the power for instance. Which is exactly a feature i would miss and there for i would be forced to have laptop-mode-tools to take care of that.
@TZ: Of course not, I was just too lazy to implement it yesterday 😀
@I-want-feature-X: As I wrote in the blog post, we are just shipping by default sensible features which are not controversial or dependent on specific hardware. Still, you are now able to extend PowerDevil with plugins and have them integrated, but *as part of the KDE SC* only the basic features will be shipped. You are encouraged to extend PowerDevil as you please, a tutorial for doing that will come soon.
Not sure about the name… KDE PMS ? Sounds like software that will misbehave during a few days every month, or take the blame for any and all odd behavior.
(sorry, bad joke, couldn’t help it)
You know, the concept of Triggers, Actions and Profiles could be generalised to a desktop level, not just for Power Management, your triggers could be anything like network connections or geolocation or plugging in a peripheral, and Actions could be things like switching proxy settings or Plasma Activities or anything really.
“The “ondemand” governor should be able to fit every possible use case”
This is not true. When using a system for real-time multi-media, ondemand causes significant delay as to produce xruns in jackd, for instance. The solution is to set CPU governor to performance in these scenarios where the system has real-time, low-latency demands on it.
This is a very good point. Although, if you are using such real-time appliances, you should also be using a patched kernel (-rt) which should include proper fixes to ondemand for making this happen.
After two days, I managed to obtain with kde 4.6 the same functionalities, about cpu management, I had by default with kde 4.4… thanks a lot! Really!