Feature requests for hal battery backend.

[David Zeuthen]

On Mon, 2005-08-01 at 16:26 -0400, Ryan Lortie wrote:
> I think this should only apply to ACPI since the other 'primary' battery
> backends don't have proper multiple-battery support and with everything
> else (including UPSes) it's not possible to determine what multiple
> batteries mean.  Also, by putting it in ACPI it serves to keep the
> calculation separate from the other battery devices in the system.

I we introduce a property battery.remaining_time, in it should be
available regardless the system is ACPI, PMU etc. based. We just need to
stress in the docs that it's an estimate.

> I am worried about the performance overhead of scanning the entire HAL
> device database by capability and then doing a check for type "primary"
> times the number of all battery devices in the system on every single
> ACPI event/poll.  No IPC, but an awful lot of computation.

Well, the overhead is quite low plus there's still a lot of optimization
that can be done (if we wanted we could easily do find_by_capability in
O(1)) - so far no one really complained about the performance of hal =)

> I'm actually starting to wonder if this patch is appropriate at all.  It
> would make it a lot easier for HAL clients to report accurate time
> remaining information to the user, but it's not really a nice fit as
> it's currently written (the hackish nature of my patch is a bit of an
> indication of this).

I'm still curious how this is easier than the client adding up the
numbers itself are. Maybe I don't get it, but it was a huge thread =)

> What might be nice is some overall "time remaining" property on the core
> computer device or a virtual composite battery device for all primary
> batteries in the entire system (this composite device could also report
> overall percentage).
> 
> Something like:
> 
>   Computer
>    |
>    +- Batteries
>    |   |
>    |   +- Battery Bay 1
>    |   +- Battery Bay 2
>    |
>    +- AC Adaptor
>     etc...

This is basically what we got today.

> And the parent "Batteries" would contain sane composite information
> about all "primary" battery devices (and be flagged as such).  The
> correct place to put the combined time remaining information would then
> be in this new virtual device.

Just put it on the root computer object as Richard and Danny proposes.

> I think the mWh patch should absolutely go through since there's no
> doubt that it's the right thing to do.  Maybe my ideas about the time
> remaining stuff could use a little more thinking through, though.

Already committed.

Cheers,
David


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