The future of Power Management - together with Activities

[Dario Freddi]

On Sunday 02 October 2011 12:04:15 Andras Mantia wrote:
> On Saturday, October 01, 2011 23:13:06 Dario Freddi wrote:
> > > Is it? Certainly disabling desktop effects and 3D acceleration has
> > > an
> > > impact.
> > 
> > Sorry to disappoint you, but this action will be removed in 4.8.
> > Martin has explicitely stated that for how compositing in KDE works
> > now turning off compositing is actually going to harm your battery
> > instead of saving it - feel free to get in touch with him to expand
> > on this topic, which is not exactly relevant to this discussion.
> 
> 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.

> 
> > > And there are other things like when to suspend automatically (if
> > > do it at all), when to dim the display, etc.
> > 
> > I agree, but are you sure you need to configure these things
> > separately depending on where you are? If you are, say, working on a
> > train, you're very likely to never be idle, and to suspend the PC on
> > your own by closing the lid when not active to save the most power.
> > How can a different profile help you here?
> 
> 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.

> 
> > > So I think there are more settings then display brightness (that
> > > you usually can control anyway with an Fn shortcut on laptops).
> > 
> > Again, as I said before, I am pretty sure there are no settings except
> > brightness which require you to change to a different profile - in
> > fact, there is a reason why brightness handling works this way at the
> > moment.
> 
> You keep saying this, but sorry, I can just as well keep saying the
> opposite. :) Do you have some research showing this is true?

Well, pretty much the fact that I know what I am talking about, since I am 
maintaining this component since, like, 5 years, and the whole part of the 
mail you didn't quote where I am trying to tell you that everything not 
related to brightness is all about idle time. Mine is not an opinion, is a 
fact, and if you try to do what I suggested in the previous mail you'll find 
out you are misusing profiles.

> If this is
> true, why would we have power magement configurations at all?

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.

You have to realize your system is always trying to save as much power as 
possible, but this doesn't scale when you are working. Every time you touch 
the keyboard you wake up the CPU, every time you save/load a file you wake up 
your disk: there is no way you can hope to save power when actually using your 
PC except for lowering your brightness or killing hardware switches: how can 
you pretend lowering the idle timeout for the screen is going to help you?

At the same time, power management configuration is still useful: if I am 
going for a coffee, I care my screen blanks if I am low on battery, I don't 
care about it if I'm on AC power. This configuration mean makes sense as it 
puts the config over 2 levels: generic, aka dependent on the battery state, 
and activity-wise, where some settings are overridden because they clash with 
what I am doing.

> Just as
> with turning off wifi with a hardware button, brightness can be changed
> from the hardware (well, software,  but usually independent of the
> running OS).

Exactly what you need to do. But I explained previously that powerdevil is 
smart enough to REMEMBER your brightness choice. If you are working in the 
train and set the brightness to 15%, until you get a state change powerdevil 
will always restore the brightness to your manually set level. That is 
extremely helpful when saving power, and it's not requiring any profile.

> Certainly CPU wakeups, disk, perfipherials, etc. have an impact on
> battery life.

See above.

> 
> What should be configurable is another thing. In perfect life, indeed we
> should just have good defaults.

We have decent defaults - and you can change them. In 4.6+, defaults are 3 
profiles with 3 states and no additional plugins - so no change in defaults 
for this.

> 
> > Provided some good reasons, I will. But I think atm you are wasting
> > your time creating new profiles, while you could achieve the same by
> > tweaking your brightness. This kind of placebo-effect of switching to
> > a profile with a different name is something I was fearing from day
> > 1.
> 
> Isn't good enough reason what was said in this thread?

No. I think I answered all concerns, and I will state again that switching 
profiles they way you use them is just a mere placebo-effect which is just 
changing your brightness, and you still need to prove me wrong, even though I 
would advise you to simply realize it's true - you can try it yourself.

> I'm not the only
> one feeling it weird that configuring power management is tied to
> activities.

Read all caps below.

> And even if we have good defaults (that we should) for
> peformance/agressive power saving, then it is still weird that you
> cannot change the active setting without switching to a new activity.
> That is what people try to explain here.

It is not weird, it is sensible, because the general policy is to strive to 
save as much power as possible. Read above for consideration on how a policy 
daemon should act.

> And it is just as weird, if you CAN tweak the power management settings,
> but you cannot do that without creating a new activity. It was already
> asked here: is there a technical reason why you couldn't do that?

First of all, I am tired to say that but again: NOBODY IS TAKING AWAY THE 
POSSIBILITY OF EDITING POWER MANAGEMENT SETTINGS. Hope it's clear now it's all 
caps.

No technical reasons, and I would gladly skip that other mail asking me if my 
architecture doesn't allow that: it's pretty good and is working reliably 
until today, so it can do its job, thanks. Just as I could add 1500 useless 
options to the architecture because I can, I can remove one which is not 
useful and confusing (and this thread is the exact demostration: if I never 
added profiles, nobody would feel the urge to abuse them instead of doing the 
right thing from the start) and replace it with something better.

> 
> 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/6d41b92a/attachment.sig>
-------------- next part --------------
_______________________________________________
Plasma-devel mailing list
Plasma-devel at kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel