Plans for hal 0.5.x

[David Zeuthen]

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, 
    lid.

    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
     http://memebeam.org/toys/ToshibaAcpiDriver
     http://ibm-acpi.sourceforge.net/
    or whether that is necessary.

Cheers,
David

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