Re: [gpm] Batteries and Abstraction: What Belongs in HAL?

[Richard Hughes <hughsient gmail com>]

On Fri, 2006-11-03 at 01:10 -0500, Stu Hood wrote:
> While looking through gpm bugs, I noticed Richard's comment on bug
> #345954, where he mentions that he is working on more intelligent
> battery status code. Its a few months old, so my first question is
> whether or not it is still being worked on. Secondly, if the battery
> status code might be about to undergo a major change: what parts of
> the gpm code could and should be moved into HAL?

Yes and no. I've read lots of papers on battery discharge calculations
and it all seems pretty doable. The only thing that kills the idea is
model precision, broken computers, debugging, and the fact that most
people do not go from 0% to 100% back to 0%. Ohh, and the need for a
discharge profile, but we could fix most of that. And that can't really
go lower down, as we need persistent storage and configuration.

It's not actually that hard to reduce the error down to sub-percent
(rather than +/-5% like most batteries give us) accuracy.

And the second part of your question is a difficult one.

> For instance, the only useful charge rate data currently being
> reported by HAL is in the " battery.charge_level.rate" key, which
> exposes a raw rate from the hardware.

Not quite raw, it's normalised into mWh by HAL and sanity checked.

>  But isn't this supposed to be the hardware _abstraction_ layer? We
> could certainly move some of the intelligence of our current code into
> HAL: such as a key for smoothed_rate (calculated with an exponential
> average, or with the heuristics code Richard is working on).

Hmm. Smoothing is only really useful when you calculate time remaining,
for which HAL is very broken for multi-battery laptops.

> It would make a lot more sense to have that key exposed to a desktop
> than it does to expose a raw number which comes straight from the
> hardware. Additionally, the remaining time calculations we currently
> do in gpm (and which will be done in the future by Richard's
> heuristics code) could take place in HAL, and be exposed as keys. 

Yes, this very sane, but we would really need the battery code in HAL to
be ripped apart and put back together something like GpmPower is
structured, i.e. with attached batteries relating to each other.

> Use Case: A new mobile device is being developed with a kernel
> supported by HAL, and the developers decide to use HAL to abstract
> their hardware. They are about to write code to keep track of the
> battery charge and do time calculations based on the rate reported by
> the battery, but luckily the HAL and gpm developers have already
> implemented this logic. The developers can jump straight to putting a
> native GUI on the provided data, without duplicating any effort. 

Sure, totally agree. This also fixes stuff like battstat-applet and the
kde powermanager that is being worked on.

> The root of this question is: how much of the code in src/gpm-power.c
> belongs in HAL? Should HAL stay lite and keep giving out raw numbers,
> or should it bulk up and get smarter?

Well, the honest fact is that:

1) the code in g-p-m is usually pretty modular.
2) the code in HAL is not well structured for multiple battery
calculations IMO due to the use of the yukky proc interface.
3) it's easier to handle problems in gnome-power-manager rather than HAL
as we can switch on options or tweak values in gconf.
4) it's easier to get people to test CVS gnome-power-manager rather than
CVS HAL.

But these are all lame excuses.

When HAL switches to the new battery class driver in the kernel I want
to really re-write the battery handling in HAL; you are right, we SHOULD
do this.

Richard.