Plans for hal 0.5.x
david at fubar.dk
Mon Dec 13 14:48:47 PST 2004
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,
> 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.
Also, the design must be flexible enough for PMU to map onto it; Sjoerd?
hal mailing list
hal at lists.freedesktop.org
More information about the Hal