Feature requests for hal battery backend.

Richard Hughes hughsient at gmail.com
Mon Aug 1 13:58:25 PDT 2005


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 

What about 2 UPS's connected to my server? Okay, maybe not a likely
case.

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

David? It is a pretty critical path.

> The linked list serves to keep things nicely separated and reduces the
> computation load on updates.
> 
> > 
> >  -  +	int am_discharging = 0;
> >     +	int am_charging = 0;
> >     +	int total_rate = 0;
> > 
> >     should use gboolean here.
> Ah.  Had I know that glib was used by HAL I'd have used GSList instead
> of hacking up my own linked-list implementation.

Sure.

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

What about system.time_remaining on the Computer node?

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

Or this, David?

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

Possible in the existing infrastructure?

> I think the mWh patch should absolutely go through since there's no
> doubt that it's the right thing to do. 

In :-)

>  Maybe my ideas about the time
> remaining stuff could use a little more thinking through, though.

Sure. Seems like we've got enough ppl on this list who know power :-)

Richard.

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



More information about the Hal mailing list