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

["Stu Hood" <stuhood gmail com>]

Richard,

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.

Let me know if there is anything I can do to help with that.

And that can't really go lower down, as we need persistent storage and configuration.

 Wouldn't it be logical to have this in HAL then? Since it is running as root, it would be universal, and could store data "permanantly" instead of starting out stupid for each new user. Having HAL remember the last 32 or 64 batteries that had been used in the system wouldn't be that much of a burden, right? It could probably be a pretty minor data structure.

 

> 2) the code in HAL is not well structured for multiple battery
> calculations IMO due to the use of the yukky proc interface.
You're definitely right about HAL not using the best interface for
multi-battery configurations. But if it's possible, it really would be
utopian =) .


> 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.

Currently batteries are exposed as seperate devices, in the format "acpi_BAT#". Could we instead (or additionally) expose an aggregate "device" that acts like a 'kind' entry in the gpm-power kind cache?

Thanks for taking me seriously heh.

Stu Hood

On 11/3/06, Richard Hughes <hughsient gmail com > wrote:

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.