only polling in HAL acpi code?

[Davyd Madeley]

Quoting David Zeuthen <davidz at redhat.com>:

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

Ok. I do see this now.

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

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

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

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

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.

--d

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