RFC: ACPI namespace

[Sjoerd Simons]

On Sat, Jan 08, 2005 at 02:18:13PM +0000, Richard Hughes wrote:
> >> Key: acpi.processor.can_throttle (int) Mandatory: No
> >> Description: Whether the processor supports throttling to decrease it's
> >> own clock speed.
> > This should be boolean from the naming. And i guess a
> > processor.{minimum,maximum}_speed would be nice (type int, mhz). Afaik
> > all processors that can throttle can provide this information, so making
> > it mandator iff processor.can_throttle == true would be okay i guess.
> 
> Again, my error on the bool.
> 
> I wanted to leave the throttling specifics until later, because it varies
> wildly between models of laptops. AFAIK some laptops can only set
> pre-defined frequencies (like 800MHz, 400MHz, 200MHz) and others can scale
> pretty much as they like. Tell me if I'm wrong.

Your right. I would need to checkout if i can get that info, but if the kernel
knows it it should be possible :).. It would be nice if we could represent both
cases in hal..

> I wanted to get the core bits of the power management into HAL, and then
> we can refine the policies into something more specific. I played with the
> idea of using a percentage scale, and then for the scaling backend to
> automatically choose the nearest frequency from the available list. But,
> ideas are welcome :-)

I would try to leave the intelligence out of hal and just force the
applications to specify an available frequency (or something like the next high
freq.).. I can image that when programming a cpu freq manager, you want to just
switch to a higher or lower frequency most of the time. Needing to play with
percent indicators to see what happens looks cumbersome.. 

> 
> > As a general comment just don't prefix everything with acpi :) On a
> > powerpc you can get basically same info for most stuff.
> > 
> > 
> Okay
> 
> > What i'm missing are sensors. For example my powerbook has 2 light
> > sensors and 2 temperature sensors. Can ACPI provide this kind of stuff
> 
> What's a light sensor? What's it for? Sorry if I'm being dense...

Being dense is good :).. On my laptop there are light sensors on both sides
of the keyboard. A little deamon uses the information for these to
automagically adapt the lcd brightness and the keyboard light to the ambient
light :)  (Thus when the lightlevel goes down the lcd brightness is turned down
and when dark enough the keyboard light is turned on)
> 
> For temperature, you're right, ACPI can display it:
> /proc/acpi/thermal_zone/THRM/temperature
> 
> (I only get one temperature reading, "CPU" on my laptop so I put it in the
> system.processor namespace. I also get a case temperature reading on my
> desktop, but where would it best go? system.temperature?

My powerbook has two, one for the GPU and one for the CPU. Other machine might
have other termal zones. 

In my view, fan speed, temperature and light readers all fall under sensors. I
guess it could be nice to have one object per sensor, with keys like
sensor.location (cpu/gpu/left of keyboard etc), sensor.type
(light/fanspeed/temperature etc) and maybe sensor.device which can optionally
bind it to a certain device.
  
> I've added a sample to the new system.processor namespace (look down),
> please comment on what you think.

Looks okay.. imho
  
> > or is that always lmsensors domain ? Also for laptops having the
> > brightness level of the lcd would be nice (Nothing to do with acpi, but
> > still)
> 
> WIP :-) the LCD stuff has been my #1 priority for a long time... 
> 
> 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...

> I've added the display_device namespace. What other properties do display
> devices need?

  Sjoerd
-- 
During the voyage of life, remember to keep an eye out for a fair wind; batten
down during a storm; hail all passing ships; and fly your colors proudly.
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal