ACPI/PMU procfs HAL test program. Version 002.

[Richard Hughes]

Danny Kukawka <danny.kukawka <at> web.de> writes:
> 
> On Monday 24 January 2005 11:30, Paul Ionescu wrote:
> >
> > I think we can at least use this to pool at hald startup to populate the
> > database, and for further updates we maybe think more about them.

Yes, David said that the values should be read at startup, even if there is no
polling or addon code activated.
 
> O.k. Maybe one way for further updates could be to update the battery related 
> values (and poll  /proc/acpi/battery/BAT0/state) only, if somebody ask for 
> the actuall values. Maybe the best way to reduce systemload.

I do believe that HAL should be the main polling daemon, so to speak. Polling is
generally bad, but I don't think we have any other choices, do we? acpid(?)
 
> > But IMHO powersave should listen for info from hald and not viceversa.
> 
> I understand your intention. In this case we should implement this as said 
> above, but I'm not shure about it.  I would avoid, that several programs try 
> to get battery information from proc. 

Yes, they would be getting them all from HAL in the future, e.g. PowerManager,
powersave or any other "do something if this" type daemon. 
You don't want specifics in these high level interfaces, for instance,
PowerManager should be able to call Restart() or SetLCDBrightness() without
worrying whether the macine is PMU/APM/ACPI.
This will make sure all the specific (and common) code is in HAL, and that the
public methods are all common, and well defined.

> Is there a way to say HAL something like: "send me a message if a (defined) 
> value changed"?

Yes, a DBus event. I'm not sure, but I think it would be pretty trivial to
register a dbus listener, and just sent out an event to the listener:
/bla_bla/ac_adaptor.present FALSE

when the property is changed, rather than to have to query HAL every few seconds.

> I will think about it and speak with the maintainer of powersave in the next 
> days.

Tell him to come and talk to this list, and we can talk about what's planned for
HAL, and what else he would like to see.

Richard.



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