acpi updates

[David Zeuthen]

On Tue, 2005-02-01 at 17:44 +0100, Sjoerd Simons wrote:
> Makes perfect sense :) thanks! 
> 

Good :-). 

I was thinking about how we want to update things. 

Earlier I mentioned we want the method Reprobe() on the org.
freedesktop.Hal.Device interface; it simulates removing the
device object (or an entire tree) and adding it again. 
Which is useful if you installed new device information
files. This one I want to add since future UI will need
it; e.g. dealing with the "Unknown Device Detected" use 
case that involves installing new device information files.

Perhaps it would also make sense to add the method Rescan()
on the org.freedesktop.Hal.Device interface? This would
effectively poll the underlying devices for changes and
update the properties on the device object accordingly.

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. 

Here's a more concrete example: for ACPI batteries, the
addon would listen to /proc/acpi/event (or whatever) and
just update the battery.charge_level.current when the
battery is charging/discharging. 

But when the battery is removed, or added, the addon would
invoke Rescan() and the existing code clears/sets all the
battery.* properties except for battery.is_present which
would be set to FALSE/TRUE. PMU would do something similar
I suppose.

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. 

Makes sense?

David


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