Plans for hal 0.5.x

David Zeuthen david at
Mon Dec 13 14:41:03 PST 2004

On Mon, 2004-12-13 at 21:40 +0000, Sergey Udaltsov wrote:
> Hi
> Since I am waiting for the feedback on my first piece of code, I can
> think a bit forward... Here are some questions to discuss regarding to
> acpi.
> >  4) ACPI/PMU: Should be a job of reading off files in /proc or using
> >     /dev/pmu. Sergey already did the spec of what the properties should
> >     look like; we should just use that. Also add support for laptop-
> >     specific interfaces through hal framework ideas 3) and 4) above.
> Well, I am looking from somewhat "battery-obsessed' POV:) - so forgive
> me my narrow sight here:)
> While technically it is nearly trivial to get any info from ACPI
> (thanks to /proc/acpi) - we should first specify the behaviour of the
> ACPI-related nodes/capabilities/properties in the specs. Speaking of
> batteries: should the root node "Computer" get the "battery"
> capability - or should there be some "ACPI controller"/"ACPI
> subsystem". Alternatively (as we discussed earlier) - we could put
> some battery_unit(s) under the "Computer" node (or, again, unser "ACPI
> subsystem"?). Will all this stuff be managed by the addon - or in the
> hald itself? If former - which hardware, if present should trigger the
> addon invocation? Opinion, comments?

Good questions, all of them. Here are my ideas:

 1. Each battery bay should have it's own separate device object of
    capability 'battery_bay'. The hal daemon creates these objects
    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.

 2. A hal device object for the AC adaptor. Simply with capability
    power_source, boolean property power_source.enabled

 3. Buttons also have separate hal device objects. They have capability
    'button'. We define button.is_toggle which, if TRUE, means that the
    actual button is one that can be pressed down for long amount of
    times; like a lid switch. Also, then we export
    button.toggled.is_pressed which is TRUE, if and only if, the button
    is pressed down. 

    A property button.type, a string, says what kind of button we're
    talking about. I envision the following buttons: power, sleep, 

    When buttons are pressed they emit a DeviceCondition, e.g. a D-BUS
    signal on the hal device object.

 4. Not sure how to abstract the various ACPI extra bits for e.g.
    Toshiba laptops and now also IBM Thinkpads
    or whether that is necessary.


hal mailing list
hal at

More information about the Hal mailing list