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

[Richard Hughes <hughsient gmail com>]

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.