Feature requests for hal battery backend.

Ryan Lortie desrt at desrt.ca
Sat Jul 30 00:05:40 PDT 2005


Le jeudi 28 juillet 2005 à 19:41 +0100, Richard Hughes a écrit :

> mWh seems standard.
[...]
> Sounds good to me,

I'm going to reply to this email since I'm not on the list and didn't
receive the others (but I've read through the web archive).  The reason
that mWh must be known is in order to support laptops that have
dual-battery configurations where the batteries are different (perhaps
you have one high-capacity battery and one normal).  As a result of
this, gnome-applets will never use the 'percent' field to determine the
amount of battery charge.  If you used 'percent' and took a simple
average and one battery was larger capacity than the other then you
would end up giving the user false information:

Simple example:  2 batteries.  One is 10mWh and one is 20mWh "high
capacity".

The 20mWh battery is empty.  The 10mWh is full.

average( 0%, 100% ) = 50% when in reality, the laptop as a whole is at
33% total charge.

In order to do the calculation correctly, battstat-applet needs to know
the full and remaining charge capacities of all batteries.  The
calculation is then:

Sum( Current charges ) / Sum( Full Capacities )

== (0 + 10) / (20 + 10)
== 10 / 30
== 33%

Expanding on this, there are actually laptops in existence that can take
two batteries with different voltage levels (for example, one main
battery and one add-on battery).  If ACPI reports in mAh for each
battery, then you need to take voltage into account on a
battery-by-battery basis (multiplying by its current and total charge
capacity to get watts) in order to do the overall charge calculation
correctly.  This also means that you need to parse the 'units' string in
HAL to determine what mode of calculation you're going to perform.  This
rapidly decays into the material that nightmares are made out of.  Using
HAL should be easier than this.

See more information here:
http://bugzilla.gnome.org/show_bug.cgi?id=309944

So basically, my request is for a single unit that is representative of
the actual ability of the battery to keep the laptop running for a
certain period of time (like Joules or mWh for example).  This is the
only thing the end-user cares about and is the only thing I really care
about as an application developer.

(on the topic of improved "remaining time" reading)
> I think this shouldn't be in HAL as it gets very complicated very
> quickly. It's also not device specific.
> 
> gnome-power-manager just takes all the devices with capability battery,
> and checks for battery.type="primary", averaging out the data - which
> seems to work well.

I don't understand what you mean by this.  I haven't actually seen this
in action since I don't have a laptop to test it on (please correct me
if I'm wrong!), but as far as I can tell from reading the source, if
only one battery is discharging, then the other battery shows an unknown
time remaining.

> > This has the added advantage that if one battery is discharging while
> > the other is just sitting there then the time remaining on the currently
> > discharging battery will be equal to its actual time remaining and the
> > time remaining on the battery that's not currently being used will be an
> > estimate of how long that battery will last once it starts being used.
> 
> g-p-m does this.

I think HAL should do this to remove duplication of effort among
application programs.  No need to have g-p-m and battstat and everyone
else do something if it can reasonably and easily be pushed into a
central location.  Fewer bugs, less maintenance.  Plus, it makes the HAL
more attractive to application developers, to boot.

To formalise my request:  I want the "remaining time" field to be more
application friendly.  My previous email discussed the underlying
implementation, but when it comes down to it, this is the interface that
I would like to see as a user of HAL:

I think the purpose of the "remaining time" should be to tell you for
how long that battery could power your system under current load.

In the event that it is currently in use: this is how long it will last.

In the event that it is not in use: this is how long it would last if
you started using it at the current consumption rate.

In the event that two batteries are in use at the same time then the
time remaining tells you how long each battery would last if you were to
switch to using it alone.

In all cases, the sum of the two numbers if how long your laptop will
last overall.  This makes it extremely easy for applications to give the
user "this is how long you have" since the application then just has the
sum the numbers up.  It also gives a reasonable and consistent meaning
to the field for any given battery in all possible cases.

Hope this email cleared up the justification for some of my requests.
Additional feedback is definitely appreciated.

Cheers.
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal



More information about the Hal mailing list