acpi updates

[David Zeuthen]

On Tue, 2005-02-01 at 18:47 +0000, Richard Hughes wrote:
> > Surely, most device objects would just throw an exception
> > since it doesn't make sense for them, but it would be useful
> > for "big state changes" like when a battery is removed. 
> 
> Hmm... I see where you are going, but un-plugging the ac_adaptor is going
> to cause mass rescan and lots of hard-disk and processor... No?
> 

That depends on what the ACPI socket tells us; if it just
tells us "something changed, but I don't know what" we need
to rescan everything, if it says something more specific
such as "this file in /proc/acpi changed", "BAT0 charge
current is now 38432", "BAT0 is now present" we can pinpoint
what objects to modify / invoke the Rescan() method on. 

> > Without a feature like this we would need to duplicate
> > code in both the daemon/probing and the addon listening
> > to /dev/pmu or /proc/acpi/event or whatever. 
> 
> I figured we could link into acpi.c from the addon...

No, that code uses the internal hald API to avoid the IPC
roundtrips. Addons/probers right now talk to hald through
the system bus [1], but I'm going to make hald listen on a
private socket as well (I'm already doing that for the 
regression tests I've just added) to reduce this to one
IPC roundtrip, e.g. hald-probe-input/hald-acpi-addon <->
hald.

Cheers,
David

[1] : e.g. hald-probe-input <-> dbus-daemon <-> hald


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