only polling in HAL acpi code?

[David Zeuthen]

On Tue, 2005-07-12 at 07:59 +0800, Davyd Madeley wrote:
> > We also poll for battery changes mostly because ACPI/SMBIOS in the
> > actual system is broken and the kernel doesn't do anything to work
> > around this. People reported problems with polling too fast because of
> > crappy BIOS'es in some systems. So we only poll every 30 seconds as
> > well. That only breaks a few set of boxes that wouldn't work with
> > battstat-applet anyway. Often such users are encouraged to update the
> > BIOS.
> 
> Polling for batteries does seem like a sane option, ACPI really is a 
> collection
> of broken pieces of crap. Indeed, a lot of the things you mentioned here were
> previously noted in battstat.

Right. We only poll every 30 secs though so it has little or no impact
(we poll from inside the hal daemon which is almost certainly not paged
out since apps access it all the time). The difference between polling
and not, is the fact that with polling things works on very closely to
100% of all ACPI systems. It's a practical consideration, really. 

Btw, even on busted systems (that require polling battery levels), the
button and ac_adapter events normally work well. 

Oh, another thing: there is a gotcha that we need to invoke Rescan()
from the resume handler of the power management scripts (distro specific
unfortunately) to e.g. reread states for ac_adapter and buttons but this
is only because the kernel is busted, I think.  We have tools for this
in the hal tarball (hal-find-by-property and dbus-send), I just haven't
put in the Fedora pm-suspend script just yet.

(Btw, battstat suffers from this too in the very typical usecase:
suspend while plugged in, plug out and leave the office, come back home
and resume and battstat shows that the laptop is plugged in.)

> >> Using the asynchronous causes things like the battery
> >> charging indication (in say, battstat) to be highly responsive, rather
> >> then waiting some time before it receives an update. If you want to
> >> check this out, try the new battstat in GNOME 2.11, which will use
> >> libhal if found.
> >
> > Interesting. It's worth noting, though, that the normal use case isn't
> > that the user stares at his battery meter all the time so updates every
> > e.g. 30 seconds should work well, don't you think?
> 
> For updates on battery power, it doesn't make a lot of difference. 
> Where it does
> make a difference is when a user inserts or removes a battery, or when an AC
> adapter is plugged or unplugged. These are events that people (or at least me)
> look at the meter to check if I am actually on AC power.

Certainly. We do handle these events as appropriate. Polling is only a
secondary measure.

> > However, we should process asynchronous signals if the ACPI code in the
> > kernel sends them, sure. If this doesn't work today, it's a bug.
> 
> Seems you are listening to the ac_adapter and battery events and meant to be
> doing a device rescan. In fact, now that I've found this piece of code, I
> notice the commit message:
>       * hald/linux2/addons/addon-acpi.c (main): Whilst using CVS, I've
> 	found that ACPI ac_adapter events are not triggering a rescan of
> 	the ac_adapter object.
> 	Patch from Richard Hughes <hughsient at gmail.com>
> 
> Which might be the exact bug I'm noticing (I notice it's not in a released
> version yet). Out of interest, how far away is the next release?

Ah, OK, that one. Release 0.5.3 is out very soon; sometime this week.

> >> You should also be aware that the remaining time calculations you are
> >> doing are going to fail on some dual battery systems it seems, where
> >> only one battery has a discharge rate listed. GNOME Bugzilla
> >> (http://bugzilla.gnome.org/show_bug.cgi?id=309944) has a pretty good
> >> example of how messed up this can get on dual battery systems. Notice
> >> how all values are in mA rather then mW and that only one battery has a
> >> discharge rate, which is obviously meant to be applied to both of them.
> >> I'm not sure how you're going to deal with this in HAL.
> >
> > So, basically we treat each battery as a separate unit and e.g.
> > battstat-applet-2 should add up time remaining. It sounds like a useful
> > convention to use the discharge rate of the first battery if it's
> > missing for the second (patches are welcome). The right place to fix
> > this, however, is of course in the kernel.
> 
> I think the kernel is nominally correct, in that it's reporting what 
> ACPI tells
> it, which is one battery is discharging at a known rate, and the other is not.
> The problem is that this makes the time_remaining property pretty useless from
> an ACPI point of view. 

Well, HAL should be smart (since the kernel isn't) and just use the
discharge rate of the other battery or something else that is clever
(see below), no? I think it should as it still makes sense to discuss
"time_remaining", e.g. sooner or later the battery will die.

The key here is to put all the various work-arounds, vendor/
model-specific hacks, and clever code in one place: HAL.

> The interesting thing here would be to know how APM is
> returning the remaining time on dual battery systems (I seem to recall you can
> still get separate battery state with APM).

Nope, the data you get back from APM is for the entire system. IIRC,
this is one of the things ACPI "fixed", and, btw, it is often mentioned
as one of the benefits of moving from APM to ACPI (that and also that S3
works on only 80% of all models :-).

> Otherwise, it is no major hassle to move the time calculations back into
> battstat (we already have the code to do this). It would be nice to 
> simply have
> this information in HAL though. I'm not 100% sure how to handle it. Some
> batteries may report discharge rates for each battery, again there is no
> consistency in ACPI.

It would seem sane to me that each battery have a separate (likely
different) discharge rate since the batteries have different physical
characteristics (mainly because of difference in age and thus effective
capacity). ICBW though, that entirely depends on how the batteries are
hooked up to the system; I don't know if there is a standard for this
though - just speculating.

Ideally, battstat shouldn't care about discharge rates and stuff like
that; all it should do is add N numbers signifying time left (one for
each battery) and show the total as nice graphics :-)

Another point is that we may be able to do more accurate computations of
time remaining than the 1th order linear approximation used. In fact, we
could probably even do pretty well even if we didn't have the rate (by
employing knowledge of how the curve looks). Patches welcome for
that :-)

    David


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