new powermanager and battery
sebas at kde.org
Fri Sep 1 08:43:07 BST 2006
Thanks for your feedback, here are some comments. Maybe Ellen has some
> On 8/30/06, Sebastian Kügler <sebas at kde.org> 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
> 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.
http://www.kde.org | http://vizZzion.org | 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
Size: 483 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20060901/c97a97e5/attachment.pgp
More information about the kubuntu-devel