RFC: ACPI namespace

[Richard Hughes]

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.

> 
> 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 :-)

>> >   
>> >> Has any work been done in the past on HAL to support probing of
>> >> monitors/LCDs?
>> > 
>> > Don't think so.. And this is almost rocket science. For laptops displays
 it's
>> > reasonable simple to get brightness (at least on my powerbook), but for 
the
>> > other properties...
>> 
>> Same here, except I have to use the toshiba specific extensions in
>> /proc/acpi/toshiba - which complicates the schema a bit.
>> 
>> Shall we work on getting namespace acpi/pmu into HAL before we tackle
>> the LCD's? 
>> 
> 
> 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.

>> Thanks, Richard
>> 
>> -------------------------------------------
>> Namespace:	system.button
>> Description:	Device objects with the capability system.button represent all
the devices capable of providing a state to the system. The following property
is available:
>> -------------------------------------------
>> 
>> Key:		system.button.type (string)
>> Mandatory:	Yes
>> Values:
>>  lid_switch: 	The switch on a laptop that senses whether the lid is
 open or closed. 
>>  power: 	The main power button on the computer
>>  sleep: 	The sleep button on a computer capable of putting the computer 
into a suspend state.
>> 
> 
> We also want:
> 
>  system.button.has_state (bool)
>  Mandatory: Yes
>  Description: True if the button maintains state, e.g. can toggled
> on/off
>  
>  system.button.state.value (bool)
>  Mandatory: When system.button.has_state is TRUE
>  Description: State of the button, TRUE if it is pressed down.
> 
> 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.

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

> 
>> -------------------------------------------
>> Namespace:	system.display_device
>> Description:	Device objects with the capability display_device represent 
all display devices in the system. The following properties are available:
>> -------------------------------------------
> 
> 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?

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

> 
>> -------------------------------------------
>> Namespace:	system.sensors
>> Description:	Device objects with the capability system.sensors represent 
all light and temperature sensors in the system. The following properties 
are available:
>> -------------------------------------------
>> 
>> 
>> Key:		system.sensor.device (????)
>> Mandatory:	No
>> Description:	HAL device reference

I meant device as in HAL UDI, not /dev/cpu. Sjoerd (I think) thought it
was a good idea to link back to the processor object.

>> 
> 
> 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?

Thanks, Richard




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