The future of Power Management - together with Activities

[Dario Freddi]

On Sunday 02 October 2011 20: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 think so. Every other system does a similar thing: there is no use in 
saving battery when you're on AC, when you are on battery these components are 
turned off. I don't think this should be configurable at all, and to a certain 
mean it is: you can always re-enable the service in the system tray with a 
single click. The user doesn't need to do anything at all here and can simply 
trust his system to do the right thing.

> 
> > > 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.

No offense meant, but this one made me laugh. If you don't know what it takes 
to save power, you should trust me when I say some things are not going to 
help you. And if I am taking this decision is because, as I said multiple 
times before, changing profile manually is not going to help you save power, 
except from the brightness setting, which is already behaving in a smart 
enough way. Maybe I should have started from the obvious assumption that if I 
had to make a compromise between making a pretty UI and saving battery, I 
would have chosen the latter with no hesitation, and if I am going towards 
this direction is because it's going to improve things, and not make them 
worse.

> 
> > 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.

And that's how it should be, and why you should trust your defaults. But if 
you see how power management is handled all around and what's the purpose of 
every setting, you'll realize pretty soon the purpose is mainly to avoid 
getting in the way of the user. After all, if it was about saving power to the 
extreme, I would always turn off the screen after 10 seconds of idling, no? :)

The point is always about finding a balance between avoiding to waste power 
and avoiding getting in the way of the user - and that's the reason why 
dimming behaves the way it does, why brightness behaves the way it does, and 
pretty much everything else.

> 
> 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

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- 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/24eae693/attachment.sig>