Adding PMU and ACPI into HAL

[David Zeuthen]

On Mon, 2005-01-10 at 18:50 +0000, Richard Hughes wrote:
> On Mon, 10 Jan 2005 11:41:41 -0500, David Zeuthen wrote:
> 
> > Not necessarily using the info.bus property - yes, hal-device-manager
> > right
> > now complains if it's not set but we might fix that later. The reason I
> > don't
> > want the info.bus = acpi is that ACPI isn't really a bus.
> 
> I thought you might say that.
> 
> What about info.bus = 'logical'
> 

Maybe, I'm thinking of ditching info.bus for non-physical devices (in
this case one can consider ACPI and PMU non-physical and rather logical
device since those interfaces represent properties on the low-level
system firmware).
 
> > Anyway, I think we agree. Could it simply look like this:
> > 
> >  info.bus = 'unknown' # for good measure until h-d-m is fixed
> >  info.udi = '/org/freedesktop/Hal/devices/acpi_proc_acpi_button_lid'
> >  info.capabilities = 'acpi_button system system.button'
> >  acpi_button.linux.path = '/proc/acpi/button/lid'
> >  system.button.type = lid
> >  system.button.has_state = TRUE
> >  system.button.state.value = FALSE
> 
> Good for me.
> 
> Where's acpi_button.linux.path come from? Surely this would be needed for
> all acpi objects.
> What about acpi.linux.path?
> 

I think it makes sense to make a distinction between acpi_button and
acpi_battery since the add-ons and eventually exported interfaces should
live in different binaries.

> >> 2. A device file (e.g. battery_device.c) is used to populate the HAL tree
> >> with a battery object. 
> > 
> > You want to have the Linux ACPI bits in hald/linux/acpi.c and make
> > osspec.c
> > call some functions to read off the data.
> 
> Sure I'll start reading lots of code... :-)
> 

Cool, this should be easy to port over to the new backend I'm working
on.
 
> >> 3. An addon is launched for the duration of the battery to update the
> >> battery charge level. (when the addon code hits CVS...)
> >> 
> > 
> > Right - we'll have a device information match the acpi_battery and merge
> > the properties with the paths for the addon.. 
> > 
> > In general the do's and dont's for hald is this: You should only read
> > files
> > in /sys and /proc from the hald process and never open a device file.
> 
> Okay, as I planned.
> 
> > Things
> > that require the device file for hardware detection needs to be
> > contained
> > in a single binary that hald launches (not necessarily an addon). I've
> > got
> > this for input devices in my local tree that I will commit soon (sorry,
> 
> Can you expand on this more? Do you mean for PMU? I know nothing about
> this, so I guess it's more relevant for Sjoerd to provide a /dev/pmu ->
> HAL interface using a external binary. But I know nothing of pmu other
> than it is supposed to be a character device!
> ACPI should need no such thing, or am I mis-understanding you?
> 

ACPI shouldn't need this, no. For example, the new backend I'm working
on invokes a binary called probe-input that opens the device and 
determines whether the input device got relative axes, absolute axes
and the keys that keyboards normally got. Just as a proof of concept.

There will be similar binaries for storage, printers and so forth.

> > I keep saying this..)
> 
> No worries, I'm not even close to needing it yet
>
> > 
> > I think the former idea is the way to go.
> 
> I'm glad you said that. :-)
> 

Cheers,
David


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