RFC: ACPI namespace

[David Zeuthen]

On Mon, 2005-01-10 at 18:33 +0000, Richard Hughes wrote:
> On Mon, 10 Jan 2005 11:32:44 -0500, David Zeuthen wrote:
> > 
> > Sorry for not responding earlier - my weekend turned out a bit different
> > that what I've expected.
>  
> Hope everything is all okay.
> 

Yeah, everything is honky dory :-)

> > My IBM Thinkpad T41 with a 2.6.10 kernel allows me to do this
> > 
> >  [root at daxter ibm]# echo on > /proc/acpi/ibm/light
> >  [root at daxter ibm]# echo off > /proc/acpi/ibm/light
> 
> Similar with my toshiba: /proc/acpi/toshiba/*
>
> > 
> > but I don't have any sensors :-/. We'll need a way to export
> > this functionality I guess..
> 
> Ick. ibm/toshiba/laptop specifics. Worry about it later :-)
> 

Cool, that's what we want to abstract so the interface is the
same.

> > Yes, I think it would be good with a step-wise approach and do things in
> > the something like the following order
> > 
> >  1. Buttons
> >  2. Batteries, AC_Adapters
> >  3. Processors
> >  4. Thermal Zones
> >  5. Video
> > 
> 
> Surely start with the easiest: ac_adaptor (one simple state)
>
> I for one would be happier starting with ac_adaptor as it is so easy - and
> we can build the generic acpi backend on this simple test case.
> 

Sounds good - the existing code should be a starting point, we can merge
that over to HEAD once I land my changes.

> > E.g., the lid on a laptop can be considered a button with state; it is 
> > pressed down when the lid is closed.
> > 
> 
> OK, added.
> 

Cool.

> >> -------------------------------------------
> >> Namespace:	system.processor
> >> Description:	Device objects with the capability system.processor represent
> all CPU's in the system. The following properties are available:
> >> -------------------------------------------
> >>  
> > Looks good, we can always add other properties here like 
> > system.processor.vendor_id and so on..
> 
> Agree yes, Any other ideas? The ones we've got now should be okay for
> starting with.
> 

I think we'll figure out what to add later on.

> > Looks good, I'm a bit reluctant to add this right away; also, I really
> > don't want HAL to go into the business of issuing DDC probes and stuff
> 
> Ick. I know. 
> 
> > like that... I think also that X.org might provide this information
> 
> You mean parse xorg.log? Or is there a better way?
> 

I think the direction X.org is taking is to at some point provide a
moded
(Mode Settings Daemon) that deals with the low-level hardware - we might
hook into that. I'm not sure it's a problem we initially just do LCD
brightness for the few select laptops that support it.

> > as it speaks to the video card. Initially, we may only provide this
> > information for select laptops, e.g. just look at what ACPI tells us.
> 
> I say get the acpi backend in, and see what other people think.
> 

Yeah.

> > Not sure this is useful to export; power management already happens
> > within the kernel for good reason: it's not sane to wait for userspace
> > to be swapped in and turn on a fan if the CPU is overeating :-)
> 
> Yes, I was thinking more for a MBM style taskbar applet that was arch
> neutral and didn't require any configuration. Not that high on my priority
> list I must admit.
> Do you want the new namespace document as a patch against hal-spec.xml?
> 

That would be cool - if you can do it against the doc/spec/hal-
spec.xml.in
in HEAD it would be great.

Thanks,
David


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