Plans for hal 0.5.x

[David Zeuthen]

On Mon, 2004-12-13 at 23:42 +0000, Sergey Udaltsov wrote:
> Hi David
> 
> Generally, your answers are ok for me - just a couple of issues...
> 
> >  1. Each battery bay should have it's own separate device object of
> >     capability 'battery_bay'. The hal daemon creates these objects
> OK, so it is hald which creates battery_bays. Sounds non really
> elegant - but I don't see another way myself...
> 

Well, yeah, some day the kernel might give us hotplug events when a new
battery bay is attached. The architecture today is basically that hald
creates device objects for various kinds of devices; what I want to move
towards is splitting all the polling/device poking into separate
processes.

> >     given the presence of /proc/acpi/battery/BAT0, BAT1 and so forth.
> >     An add-on monitors the battery status; there is a bool property
> >     battery_bay.battery_present and only if this is TRUE the device
> >     object has the capability 'battery' and the battery.* properties
> >     as defined elsewhere.
> Fair enough. This sounds perfectly ok to me. When you fork for 0.5 -
> I'll try to see what's involved in the implementation.
> 

Cool.

> >  2. A hal device object for the AC adaptor. Simply with capability
> >     power_source, boolean property power_source.enabled
> Do you really think it is necessary? If all enabled battery_bays (with
> .battery_present = TRUE) have .is_charging=TRUE - it means we are on
> AC, doesn't it?
> 

Good point.

Cheers,
David


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