Plans for hal 0.5.x

[David Zeuthen]

On Mon, 2004-12-13 at 17:41 -0500, David Zeuthen wrote:
> 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.
> 

Also, the design must be flexible enough for PMU to map onto it; Sjoerd?

Cheers,
David


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