2006-08-02 07:18:38

by Jean Delvare

[permalink] [raw]
Subject: Re: Generic battery interface

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.

--
Jean Delvare


2006-08-02 07:46:36

by Marek Wawrzyczny

[permalink] [raw]
Subject: Re: Generic battery interface

On Wednesday 02 August 2006 17:18, 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.

Yes, the user may want to know the battery state all the time, but will not
notice the difference between the system reporting battery changes every 100
microseconds or every 10 seconds, unless the hardware eats its battery
sources for breakfast?

The system cares though, very much so in fact:

If the battery becomes critical the system should either shut down or suspend
to disk (if this is supported).
This obviously would be triggered by some sort of daemon (powersaved comes to
mind).
Ideally the suspend to disk or shutdown event triggers another event that
allows any desktop to save it's state or possibly unmount shares that could
otherwise be corrupted.

This scenario is quite different to an application reading the battery level.


Marek Wawrzyczny

2006-08-03 11:25:50

by Thomas Renninger

[permalink] [raw]
Subject: Re: Generic battery interface

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

2006-08-03 16:33:43

by Pavel Machek

[permalink] [raw]
Subject: Re: Generic battery interface

Hi!

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

Well, this works okay for normal machines, but... there are strange
machines around.

If you have 10 hours of battery life (zaurus sl-5500) and hardcode
warning to 10% of battery remainin... well you'll warn with 1 hour to
go.

Okay, this probably is not an issue on most notebooks today...

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html