new powermanager and battery

Sebastian Kügler sebas at
Fri Sep 1 08:43:07 BST 2006

Hi Hervé,

Thanks for your feedback, here are some comments. Maybe Ellen has some 
additional input.

> On 8/30/06, Sebastian Kügler <sebas at> wrote:
> > As you might have noticed, development of the new powermanagement tool is
> > going quite well.
> >
> > There are two issues, however, I'm currently running into:
> >
> > * I do not own a second battery for the Ultrabay of my notebook, so I
> > cannot implement support for this unfortunately. If someone wants to help
> > out, I can assist with the code. If someone wants to send me a battery
> > for the Ultrabay, that welcome of course, too. :-)
> >
> > * HAL supports two levels of 'batterypower is low', one's called
> >   battery.charge_level.warning, the other one is
> > battery.charge_level.low. From my measurements, the "warning" level is
> > reached when 10 minutes of battery life is left, "low" is reached when
> > the lights will go out in less than about half a minute. My configuration
> > would hibernate at low level, but it might not come that far due to
> > measurement skew, or die while hibernating. Therefore I'm pondering to
> > not use the HAL provided values here, but have the user set those values
> > up. There, we're running into another problem, of course. Using a
> > treshold value of N minutes can be inaccurate due to power consumption
> > changing over time. Using HAL's battery.charge_level.rate interpolates
> > that a bit. Using a treshold of N mWh is nice for geeks, but has little
> > value to those that are not arithmetic geniuses and know how much their
> > hardware drains now and in the next minutes.
> >
> > Thoughts?

On Thursday 31 August 2006 16:10, Hervé Fache wrote:
> FWIW I have two batteries in my 'old' laptop, so if I can help, I'll
> be happy to. Note that I do not necessarily have much time to do
> things, but I can try. I have some code knowledge, so if you intriduce
> me to your code, I can at least help debug and point to the problems
> if any.
> Ideally, the user (me) wants to know about 15 minutes from end of
> battery that it's dying, so she can hibernate now and still have a bit
> left later to restart and double check the meeting room number... 5
> minutes from the end, she probably wants a big warning saying she
> should hibernate NOW!
> About 1 minute from the game over, the computer could decide to
> hibernate not risk losing data, but maybe we could not force anything
> on the user in case she needs as much time as possible, in which case
> remounting the filesystems 'sync' might be a better option (I am
> thinking of a researcher collecting data for example: the more the
> better).
> Hoping that helps more than confuses the matter,

It certainly helps a bit about getting to know what a user (!=me) would want. 
Here's my take: I want to know 15 minutes from battery is empty.

Currently, I've implemented two levels: BATTERY_WARNING (set to 8%) and 
BATTERY_CRITICAL (set to 4%). BATTERY_WARNING shows a passive popup, 
notifying of a battery running low, BATTERY_CRITICAL shows a popup and 
suspends (that one is configurable) immediately. Thinking of that, maybe a 
timeout and the option to cancel it would be nice, but then I'm using 
suspend2 and I can cancel while suspending anyway.

One of the problems using minutes as a unit is that it depends on the battery 
and usage scenario. Here's an example: I'm idling for some time now thus 
using hardly any battery power, the battery is running out and I only have 
one minute left so the hibernate kicks in. Hibernate uses the disk and more 
processor power (it might even be compressing the image) and all of a sudden, 
I use 3 times as much energy than while idling. The minute left is 
effectively only 20 seconds anymore and hibernate might die in the process 
running out of power.

My conclusion would be that we should use percent as a unit and make the 
numbers configurable for varying battery capacities -- 10 minutes might be 8% 
based on a 2h battery, it might be 5% based on a 4h battery. Worn-out 
batteries might be another use case.
In the UI (tooltip), we would then need to display both, percent remaining and 
minutes remaining based on current rate.
sebas | |  GPG Key ID: 9119 0EF9 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Accident, n.:	A condition in which presence of mind is good, but absence of 
body is better.  - Foolish Dictionary

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 483 bytes
Desc: not available
Url : 

More information about the kubuntu-devel mailing list