The future of Power Management - together with Activities

[Dario Freddi]

On Monday 03 October 2011 06:38:29 Scott Kitterman wrote:
> On Sunday, October 02, 2011 06:44:41 PM Dario Freddi wrote:
> > I would like to draw your attention to the address of this list. It
> > has a nice -devel prefix. I don´t take part in discussions where I am
> > not knowledgeable about the topic. So far the answers I got are among
> > this category.
> > 
> >  - I have never used those features,but I am voicing random crap about
> > 
> > changing them
> > 
> >  - I have a strong opinion I will keep stating, and refuse to answer
> > 
> > your replies about my concerns or reading what you wrote previously
> > and keep going on my line.
> > 
> > Seriously, has anybody answered my statements about brightness
> > vs.everything else and creating profiles vs. creating activities?
> 
> I certainly think I have.
> 
> I've said I think the concept of activities (what you are doing) is
> generally orthogonal to when I want the system to do things different for
> power management (where I am), so trying to connect them will be
> confusing.  I don't feel like you've addressed that.

It might indeed have been unclear, so I'll try to dedicate this mail to this 
very topic.

Let me start by saying that of course you are not wrong by saying the concepts 
are orthogonal, but that would be true if activities were the only way to 
provide such a feature.

Let's now analyze the job of a _session_ power manager (I want to put the 
accent on session as it's the bit which makes the difference). Some people 
(like me) usually refer to it as a policy daemon: it just enforces a 
particular policy on some behaviors of the system. This policies are usually 
referring just to how the PC handles idle timeouts, as you can see from the 
configuration UI itself.

Before going on, I will also restate something I said in a previous mail but 
in a different context: when dealing with such parts of the system, we usually 
want to sacrifice corner cases if they might lead to a misuse.

Now, one of the strongest arguments I put in this thread is the fact that the 
only setting which is going to affect your PC is battery. Consider every 
possible use case for changing a profile should be changed manually. In this 
cases, we are likely just handling the idle time. Brightness is already smart 
enough to be transient and configurable regardless of each profile, even 
though you usually don't notice (which is good).

 - I am working and I need full power: there are no settings which can help 
you, and the fact that you are working are preventing any of the idle time-
based policies
 - I am working and I strive to save as much power: again, there's not much 
use in a different profile: you are working, so your idle time will never be 
enough.
 - I don't need some peripherals: this concept is orthogonal to power 
management just as activities are, if you think about it. First of all, if I 
had 3 peripherals which can be turned off, I would need 3!=6 separate profiles 
to cover all needs: I might want in fact to save as much power as possible, 
but I might need to have 1 or 2 of those active.
Besides, this approach simply doesn't scale: the profile is gonna be fitting 
*only* your hardware needs. You are not guaranteed you want the same policies 
to be applied when one of your peripherals is turned off: maybe you just want 
to turn bluetooth off because you feel like it but without going crazy on the 
powersave timeouts.
Instead, the right approach with these things is to disable them from their 
own applet. If you think how a user approaches this, it does it in exactly 
this way. They KNOW they have to go to the network manager to turn off the 
wifi card or to the bluetooth applet to disable bluetooth in order to do that 
(which I expressed in an unfortunate way in my previous comment about "geekish 
ways of acting"). So, even though such a thing might be present in a policy 
daemon, it's a use case so small we probably don't want to support, and which 
might lead to misuse.

I would like to start from point 3 to advocate the use of activities instead. 
First of all, the configuration for activities will not look exactly like the 
"profiles" one. It will, of course, give you the option to "create" a new 
profile for people who really want that, but mainly it will provide a 
"simplified" configuration which is able to override some behaviors: for 
example, "never suspend the PC", "always shutdown after an hour", etc...

What does this mean? For your current activity, you will always have the same 
needs: to take the most simple case, when watching a movie you will never want 
your screen to turn off, even if you're on crazy power saving mode (even 
though brightness might be useful). This means your activity will just 
override the settings YOU care about, and will leave the rest to the sane 
defaults, which are ALWAYS STRIVING TO SAVE AS MUCH POWER AS POSSIBLE, and I 
all caps'ed that because it's the whole point of the discussion.

But - and here it's important to notice - there are things which are never 
related to activities. Peripherals is the perfect example. But if you switch 
off a peripheral the proper way instead of switching to a different profile, 
you will get an even better effect. You will save power from that, still by 
using the right defaults for your state, and eventually some overrides for 
what you are currently doing. I guess you can see why this approach is more 
convenient. Of course, in the future we might think about adding a "switch off 
wifi" to the activity config, as when doing some things you don't need some 
peripherals - but it's not exactly relevant in analyzing your issue and your 
concern.

Maybe now it's also clearer why the main job of a policy daemon is to prevent 
power management. Our defaults are always striving to save each bit of energy 
if you are away from your PC, and you have to remember that! Our first aim is 
to save power. But at the same time, saving power comes at a price, and we're 
always trying to be smarter and smarter. I really believe with this approach, 
which I reckon might not be immediate to understand as I explained it, the 
means of control over your power manager will be more instead of less, and 
most of all better.

Hope this addresses your concern.

> 
> I apologize for being harsh earlier.  Cleary you didn't feel like what you
> were saying was being heard.  I didn't either.

Np, arguing is natural, but intelligent people always manage to solve that :)

> 
> Scott K

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

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/20111003/3af6f41c/attachment.sig>