[Pm-utils] Removal of pm/power.d/sched-powersave

Victor Lowther victor.lowther at gmail.com
Wed Jun 2 13:51:59 PDT 2010

On Jun 2, 2010, at 1:54 PM, Chase Douglas  
<chase.douglas at canonical.com> wrote:

> On Sat, 2010-05-29 at 10:40 -0500, Victor Lowther wrote:
>> On Thu, 2010-05-27 at 15:30 -0400, Chase Douglas wrote:
>>> I've been working on powersave policies in Ubuntu, where we've  
>>> created a
>>> package with a bunch of scripts. You can find some scripts I've been
>>> working on for Maverick at:
>>> http://bazaar.launchpad.net/~chasedouglas/ubuntu/maverick/pm-utils-powersave-policy/updates/files/head:/power.d/
>> Take a look at
>> http://cgit.freedesktop.org/pm-utils/log/?h=powersave-hooks
>> I toyed around with adding more powersave scripts to pm-utils back in
>> 2008, but there was a general lack of interest at the time.  If  
>> Ubuntu
>> is looking at adding more default powersaving scripts, it is  
>> probaably
>> time to resurrect things.
>> If y'all want to work on merging your powersave scripts with pm- 
>> utils,
>> we should be able to work something out. :)
> Sounds good to me. What do I need to do to get some of these scripts
> merged?

Give me a URL I can clone your tree into with git, or spam the list  
with patches.

>>> What I noticed is that the scheduling policies conflict with the
>>> sched-powersave policy in pm-utils. I would like to propose that the
>>> policy be removed from pm-utils, since it seems like it's on an  
>>> island.
>>> It makes more sense to me to split the policy from the  
>>> implementation.
>> Well, if the policy was in general more complicated than "save as  
>> much
>> battery life as we can while still beig useful" it might make sense  
>> to
>> split it out.  The only knobs I would offer by default would be ones
>> that would either always run with powersaving enabled or disabled  
>> while
>> ignoring powersave state changes -- if people want to tweak how
>> individual powersave hooks work, pm-utils makes it very easy for  
>> them to
>> drop in a hook that overrides the ones we ship by default.
> How a user overrides a hook and how a distro overrides a hook is
> different. The former is well defined, but the latter is not.

I had another patchset that made that well-defined, but I think I  
nuked it a couple years ago. Rewriting it should be a trivial affair.

> Mostly I'm just looking for some sort of agreement on how to handle
> distro vs upstream pm hooks. If we want to merge some hooks upstream,
> and have the distros manually shove specific hooks they don't want  
> into
> somewhere else like /usr/share/doc/pm-utils/upstream-hooks/ when they
> package it up, then that's fine with me. I'm open to any reasonable  
> way
> to reconcile this issue :).
> Thanks,
> -- Chase

More information about the Pm-utils mailing list