Plans for hal 0.5.x
david at fubar.dk
Mon Dec 13 15:48:34 PST 2004
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
> > 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.
> > 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?
hal mailing list
hal at lists.freedesktop.org
More information about the Hal