Re: Generic battery interface

[Thomas Renninger <trenn@suse.de>]

On Wed, 2006-08-02 at 09:18 +0200, Jean Delvare wrote:
> Hi Pavel,
> 
> > > frequently it can read from the chip. And no hardware monitoring chip I
> > > know of can tell when the monitored value has changed - you have to read
> > > the chip registers to know.
> > 
> > ACPI battery can tell when values change in significant way. (Like
> > battery becoming critical).
> 
> Ah, good to know. But is there a practical use for this? I'd suspect
> that the user wants to know the battery charge% all the time anyway,
> critical or not.

Some batteries throw an event for each consumed percent or at least
enough events to keep track of remaining power.
Some are only throwing an event when capacity warning/low is reached,
some aren't throwing any events.

It may be of use to reduce polling on some machines, but you will always
need a fall back. Determining whether the machine throws events
regularly is not really possible, so by default you will start to poll
the battery on all machines. Maybe in this case the normal (0x80)
battery events should be ignored to avoid double readings or the values
are cached in kernel as suggested, then it does not hurt.

One should also not rely on the warning/low capacity values.
I cannot say for sure whether all machines throw an event if these
limits are reached. We defined our own limits in userspace, this always
works. I'd go for not using the BIOS limits here at all and take user
defined capacity warning/low values (in percent) in hal or wherever.

IMO opinion the normal battery events (0x80) are not much of a use. They
probably should be forwarded, so that userspace could switch to irq
driven notification if this should ever work on more than 90% of the
machines, but default will be polling. More important are the status
events (0x81) if a battery is added/removed.

   Thomas