only polling in HAL acpi code?

[David Zeuthen]

Hi,

(I'm Cc'ing the hal mailing list)

On Sun, 2005-07-10 at 11:56 +0000, Davyd Madeley wrote:
> Heya both,
> 
> It would seem to me that HAL's ACPI implementation is only polling, and
> not listening to the events passed to it by the kernel (and then relayed
> by ACPId). 

Not true, we actually do attempt to connect to both /proc/acpi/event
or /var/run/acpid.socket (in that order). Otherwise, we wouldn't be able
to catch e.g. lid and button events (see hald/linux2/addons/addon-acpi.c
for details). This works fine on my system; let me know if there are
bugs.

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.

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

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.

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

    David


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