Feature requests for hal battery backend.

[Ryan Lortie]

Le samedi 30 juillet 2005 à 10:58 +0100, Richard Hughes a écrit :
> I was going to use the percent field for the tooltip/icon for each one,
> actually.
OK.  This type of thing is a good reason to use percent field (and we
may use it after all) :)

> Good point, we need to think about this case. One way we could abstract
> this better would to keep what we have and add:
> 
> battery.total.percentage
> 
> to each capability battery that it's averaged with.

I think the easiest thing to do here is just to do the calculation using
the normalised mWh figures for charge and full.

I should make it clear that I'm only interested in this information for
"primary" batteries (ie: laptop ones).  I agree that it doesn't make
sense for UPSes/mice/etc nor is it possible.  Also, it doesn't even make
sense as something that you would want.

> Ahhhhhhh! My head's about to explode. Also, a few batteries don't
> express the mAh charge, they *just* express voltage..
They don't express mAh or mWh at all?  How do you even handle these?

> > 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.  
> 
> Agree, but I think we have to get the interface just right here.

I think mWh is appropriate.  Perhaps we could have a separate set of
fields for it, though?  (ie: so that the original information is still
available if you want it, but on primary batteries, there are 4
additional fields using normalised units to facilitate accurate
calculations).

> What about battery csr mice? You couldn't express that in mWh, or UPS's
> for that matter.

As above -- only interested in this feature for primary batteries.

> What would a patch look like that converted mA (or other units) into
> mWh? I think mWh is the defacto std unit.

I'm not completely sure on this one.  Just looking at the units:

watts = volts * amps

But that doesn't tell the whole story.  This, generally is only true for
completely resistive loads (which a laptop is not).  It's a reasonable
approximation, though, even for a laptop.

Even still, you have to ask yourself "what voltage?".  It's probably not
the design voltage of the battery that you want to multiply by, but
rather, the current operating voltage.  But even the voltage is a moving
target (since it may decrease with time).  As the voltage decreases then
the amp draw rate on the battery will probably increase to keep
approximately the same number of watts flowing.  I say "may" and
"probably" here because I don't know how every laptop ever built will
work (and herein lies the problem).

This means that we don't have a totally linear scale, since the "amps
left" *may* fall more rapidly toward the end.  There is really nothing
that we can do about this, though, without knowing how low the voltage
will go or if the effect even occurs at all on any given laptop.  I also
don't think that we should do anything about this since using the
current voltage is probably close enough.  I think that just in using
your laptop you're likely to change the power consumption rate by more
than the change in voltage will affect it.

So I guess, basically:

current charge (mWh) = current charge (mAh) * current voltage (V)

Or at least, that's the best we can (or should) do.

We'd also have to do the same normalisation for the "design" and
"last_full" capacities and the "rate".

For the current rate it's very clear that we could simply multiply by
the current voltage.

For the design and last_full capacities, I think it might also make
sense to multiply by the current voltage of the battery rather than the
design voltage.  Reasoning is as follows:  after a lot of use, the
battery might not charge completely up to its design voltage.  This
means that design voltage is not appropriate to use to determine the
normalised last_full measurement.  Then, since, the other 3 units are
already calculated by multiplying by current voltage, it would make
sense just for consistency reasons to use it to calculate the normalised
design capacity.

This is all very hand-waving logic and I don't really strongly believe
it.  I'm too tired to really think about what is the most appropriate
thing to do right now so I'm definitely open to suggestion on these two.

I think I hate ACPI sometimes (most of the time / whenever I think about
it / etc) :)


> > (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.
> 
> Yes, because thats all the data ACPI gives it. When the laptop battery
> is fully charged there is no "rate" information, and we don't know how
> much current the laptop is taking.

Yes we do.  Even if a battery is fully charged, we can look at the rate
information from the other batteries.  As stated in the algorithm in my
original email, the total power draw rate of the entire laptop is equal
to the sum of the draw rates across all the batteries.

Of course, if you're on AC power then all bets are off (and certainly, I
wouldn't expect any "time remaining" calculation in this case anyway).

> > > > 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.
> 
> I agree.
> 
> > 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.
> 
> Yup.
> 
> > In the event that it is currently in use: this is how long it will last.
> 
> Yup.
> 
> > 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.
> 
> Won't work - see above (no current information)

See above - we have current information if we look beyond just the
battery that we are presently dealing with.

> > 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.
> 
> That's what we provide already, isn't it?
> When we do the time remaining we are just using the formula:
> 
> this_battery.chargeLevel / this_battery.chargeRate

>From reading the code, we take the chargelevel of each battery and
divide it by its own rate.

        hal_device_property_set_int (d, "battery.remaining_time",
                                     util_compute_time_remaining (
                                             d->udi,
                                             hal_device_property_get_int (d, "battery.charge_level.rate"),
                                             hal_device_property_get_int (d, "battery.charge_level.current"),
                                             hal_device_property_get_int (d, "battery.charge_level.last_full"),
                                             hal_device_property_get_bool (d, "battery.rechargeable.is_discharging"),
                                             hal_device_property_get_bool (d, "battery.rechargeable.is_charging")));

I believe the majority case for systems with multiple batteries is that
one battery will discharge before the other (even if this isn't the
majority case, it's something that we need to be able to deal with)  In
this case, the "rate" of the battery not in use will be 0 and the
remaining time for it will be unknown.

Under the proposed change, all remaining time calculations will be done
using the total draw rate of the entire laptop.  This will give
meaningful remaining time values even for batteries that are not
presently in use.

It will change the semantics for the case where the batteries discharge
at the same time, but I think it will be a change for the better.

Again, as with the request above, this is only something that makes
sense for primary batteries.  You probably wouldn't want to factor the
discharge rate of your wireless mouse battery into the "overall system
draw rate" number.

> > 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.
> 
> Isn't this what happens now?

Based on my reading of the code leading me to believe that a battery
not-currently-in-use will have an unknown remaining time: I don't think
so.

Also, in the case of batteries discharging at the same time, I think the
system "time remaining" will be more of a weighted average of both of
the batteries "time remaining" (taking lots of factors into account on
the weighting such as each battery's capacity, if you started
discharging them at the same time, etc).

However, again, I don't have a laptop to test it on :)

Again, I want to restate that if the laptop is plugged in (ie: no
batteries are discharging) then all bets are off as to "remaining time".
The only time I care about knowing the "remaining time" of a battery
that's not in use is when another battery is in use and the system will
eventually fallover to using the battery that was not in use.

Thanks for the discussion and please excuse any obvious mistakes that
I've made.  I need to get some more sleep :)

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