Message: previous - next
Month: December 2011

Re: [trinity-devel] ideas for new power management system

From: "Timothy Pearson" <kb9vqf@...>
Date: Wed, 7 Dec 2011 13:19:36 -0600
> On 7 December 2011 10:57, Serghei Amelian <serghei@...> wrote:
>> Hello,
>> I need some opinions about features provided by Power Management System.
>> So far I implemented a battery monitor and backlight control. Now, I
>> want
>> to
>> debate about:
> 1) Governors. KPowersave come with governor controller, but a guy from
> #udev
>> irc channel adviced me that is actually is not necessary to implement it
>> in a
>> gui interface, because actually we don't want to change governors but we
>> need
>> to burn less energy.
>> Check this "good practices" guide:
> Again, a power manager needs to manage the power. There are probably
> situtations where people want to use powersave or use performance, either
> way the power manager should allow me to adjust my CPU state.
>> 2) DPMS and screensavers. In my opinion, DPMS control should be passed
>> to
>> screensaver, not to be controlled by power manager.
>> Why? I think that Power Manager should react only to events related to
>> power
>> supplies (like AC adapter plugged in, AC unplugged, battery low, etc) or
>> events like "lid closed", "power button pressed", etc.
> Right and these things need to load different profiles which are preset.
>> Shutting down the monitor when the user is away from keyboard is not
>> exactly
>> related to power management, seem natural to be a part of screensaver.
>> Opinions? Ideas?
> I think you have the wrong idea. "power management" refers to managing the
> power usage and controls things that change this. DPMS (aka power display
> for monitors) should belong here. Laptop Screens and Monitors both pull an
> enormous amount of power and it is up to the power manager to utilize this
> appropriately. Not to mention the power manager is required to set
> different profiles to control my screen settings.
> if the screensaver had to do this, then the screen saver would end up
> reimplementing the profiles and make it an enormous PITA.
> the reason HAL was great is because it allowed me to manage all of my
> power
> needs from a single library. I don't understand why this was bad. As long
> as the library or application is well written, there is no reason we
> shouldn't implement all the things we need. that means we need DPMS and
> freq settings and backlight and more. why? because they are all power
> related functions.

Calvin is correct.  All the features in kpowersave need to be available
from its replacement, or we will be stuck with HAL forever. ;-)

I use the ability to change the CPU governer all the time.  I like to
think I am smarter than the computer and know more precisely when I need
high speed and "snappiness" versus long battery life.