The future of Power Management - together with Activities

[Martin Gräßlin]

On Sunday 02 October 2011 21:09:00 Andras Mantia wrote:
> On Sunday, October 02, 2011 14:45:58 Dario Freddi wrote:
> > > That was one example. Another example brought up is e.g switching of
> > > strigi or nepomuk indexing when switching to a power saving profile.
> > > These two are something that usually kick in when you are in idle
> > > mode, exactly when the battery power could be saved. Of course,
> > > with good default profiles this can be solved.
> > 
> > Absolutely not. Where did you read that, and most of all, how can
> > profiles help you here, since there is no way for configuring that?
> > If they are using Solid's way for determining if they can consume
> > resources (and they are), they turn off automagically when on
> > battery.
> 
> No way now, but why we shouldn't have such a configuration? This would 
> exactly improve power saving by letting the cpu more in idle mode.
> If we look at the big picture of KDE and think about integration, this 
> is exactly a case where it makes sense to control multiple pieces of the 
> software stack from one single place without user intervention. The user 
> asks to save power the the desktop will try to achieve this with all 
> possible means. I know this is not really about what your original mail 
> is about, but it is something that might belong into the power 
> management profiles.
I don't see a valid reason why you should make that configurable. When you are on battery solid has to tell Nepomuk & 
co to be silent. I really don't see why that should be complex at all.
> 
> > > What I said that I might manually need to switch to a different
> > > profile independent of what the battery power *currently* is and
> > > without switching my workflow/applications. Because I know in
> > > advance (before the software can find this out from the battery
> > > level dropping down) how much time I need the computer running.
> > 
> > But apparently you don't know what it takes to save power.
> 
> Do I have to really know? I just want to save power. And do that 
> whenever I want, not when the computer decides. Thats the whole point.
Do you really think that you are smarter than the Kernel? I also want to save power, but I trust the Kernel developers 
to understand more about it than I do and completely trust that they will do the best.

Now this is clearly not about the governor but about more "general" powersaving. All the time I have heard that turning 
off Desktop Effects will save power. Anyone who knows the code and who knows what is happening when you do 
turn compositing off, will tell you that turning compositing off is more expensive than all the power saving which you 
could get later on. But 3D is evil, right?

And that's now exactly the point: if you don't have any clue about what is happening your "I want to save power and 
not let the computer decide" might be much worse than what the computer would do. The software in question is 
always written by experts in their field and they care about power saving as much as you do. And they can do what 
is really the best and not just gueses.

Cheers
Martin
> 
> > I will quote myself from another mail: the main job for a policy
> > daemon is to PREVENT power management when the user is working, and
> > that's exactly the use case for activities: while you are doing
> > something, you don't want to be interrupted by extreme powersaving,
> > such as dimming the screen in 30 seconds.
> 
> Sincerely, the preventing part is news to me and probably to most users. 
> 
> Anyway, there is no point of arguing more, what I wanted to say, I did, 
> what you wanted to say, you did, you are the coder, draw the conclusion 
> from the thread and implement the feature.
> 
> Andras
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20111002/38703a88/attachment.sig>