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

["Stu Hood" <stuhood gmail com>]

> Cheers for the offer, I might need a few people
> to "run this from 100% to 0% and to 100%" 5 times :-)

What fun! My battery capacity has already dropped a half hour from messing around trying to get logs, so hit me with your best shot.

> Yes, but HAL can't store data state between reboots - this is really a
> design decision, I'm not sure it's a hard and fast decision. This is
> something we should discuss on the HAL list.

Gladly... I'll take a look at their archives and then ask.

> Yes, this is exactly what the kernel is soon to provide. Search for
> "[PATCH v2] Re: Battery class driver" in google and you'll see what I
> mean.
Oooh, that was just being discussed recently... very exciting! I'll take a look at that this weekend while I'm out of town.

Thanks, and good luck with your exams.

Stu Hood

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

On Fri, 2006-11-03 at 09:42 -0500, Stu Hood wrote:
> 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.

Sure, I need to spend a long time on this, but exams and coursework have
priority at the moment. Cheers for the offer, I might need a few people
to "run this from 100% to 0% and to 100%" 5 times :-)

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

Yes, but HAL can't store data state between reboots - this is really a
design decision, I'm not sure it's a hard and fast decision. This is
something we should discuss on the HAL list.

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

Yes, this is exactly what the kernel is soon to provide. Search for
"[PATCH v2] Re: Battery class driver" in google and you'll see what I
mean.

> Thanks for taking me seriously heh.

Dude, this is serious. Compared with half the mails I get
"gnome-power-manager won't work with KDE" this is great :-)

Richard.