RFC: ACPI namespace

Thu Jan 13 03:09:35 PST 2005

On Mon, Jan 10, 2005 at 11:32:44AM -0500, David Zeuthen wrote:
> 
> Hi,
> 
> Sorry for not responding earlier - my weekend turned out a bit different
> that what I've expected.
> 
> On Sat, 2005-01-08 at 15:58 +0000, Richard Hughes wrote:
> > On Sat, 08 Jan 2005 16:02:57 +0100, Sjoerd Simons wrote:
> > > 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..
> > > 
> > 
> > See Roberts' post on this...
> > 
> > > 
> > > 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.. 
> > 
> > Agree.
> > 
> > >> 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)
> > 
> 
> 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
> 
> but I don't have any sensors :-/. We'll need a way to export
> this functionality I guess..
> 
> > That's proper cool. My LCD bedroom clock has done this for YEARS, and I
> > wondered how long laptops would take to copy this idea.
> > Makes my Toshiba Satellite Pro A10 look quite shabby. :-)
> > 
> > > 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'm agreed, do you mean a plan such as this:
> > 
> > -------------------------------------------
> > system.sensors namespace:
> > -------------------------------------------
> > Device objects with the capability system.sensors represent all
> > light and temperature sensors in the system. The following properties are
> > available:
> > 
> > Key: 		system.sensor.type (string)
> > Mandatory: 	Yes
> > Values:
> >  light: 	Light sensor
> >  temperature: 	Temperature sensor
> > Description: 	The type of sensor device
> > 
> > Key: 		system.sensor.location (string)
> > Mandatory: 	Yes
> > Values:
> >  gpu: 		Measures GPU source
> >  cpu: 		Measures CPU source
> >  external: 	Measures external source
> >  other: 	Measuring other source
> > Description: 	The location of the sensor device
> > 
> > Key: 		system.sensor.device (????)
> > Mandatory: 	No
> > Description: 	HAL device reference
> > 
> > >   
> > >> 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
> 
> > Thanks, Richard
> > 
> > NEW PROPOSED NAMESPACES:
> > 
> > ###########################################
> > Namespace:	pmu
> > Description:	Device objects with the capability pmu represent devices currently accessed through the PMU bus /dev/pmu.
> > ###########################################
> > 
> > Key:		pmu.version (string)
> > Mandatory:	No
> > Description:	The in-kernel driver version providing PMU services.
> > 
> > ###########################################
> > Namespace:	acpi
> > Description:	Device objects with the capability acpi represent devices currently accessed through the ACPI bus and found in /proc/acpi.
> > ###########################################
> > 
> > Key:		acpi.version (string)
> > Mandatory:	No
> > Description:	The in-kernel driver version providing ACPI services. Usually of the form 20041210.
> > 
> > ###########################################
> > Namespace:	system
> > Description:	Device objects with the capability system represent all the system devices currently accessed through the ACPI and PMU bus.
> > ###########################################
> > 
> > -------------------------------------------
> > Namespace:	system.ac_adaptor
> > Description:	Device objects with the capability system.ac_adaptor represent all the devices capable of powering the system from AC power. The following property is available:
> > -------------------------------------------
> > 
> > Key:		system.ac_adaptor.enabled (bool)
> > Mandatory:	Yes
> > Description:	The state of the adaptor, i.e. whether it is providing power to the unit.
> > 
> 
> Sounds good.
> 
> > -------------------------------------------
> > 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.
> 
> > -------------------------------------------
> > Namespace:	system.processor
> > Description:	Device objects with the capability system.processor represent all CPU's in the system. The following properties are available:
> > -------------------------------------------
> > 
> > Key:		system.processor.number (int)
> > Mandatory:	Yes
> > Description:	The internal processor number in the system
> > 
> > Key:		system.processor.can_throttle (bool)
> > Mandatory:	No
> > Description:	Whether the processor supports throttling to decrease it's own clock speed.
> > 
> > Key:		system.processor.throttle_frequencies (string)
> > Mandatory:	No
> > Description:	A simple string showing the allowed frequencies and/or ranges of the frequency of the CPU. Values are in MHz.
> > Key:		Only valid if system.processor.can_throttle is TRUE
> > 
> > Key:		system.processor.maximum_speed (long)
> > Mandatory:	No
> > Description:	The speed of the processor in units of MHz
> > 
> > #Key:		system.processor.temperature (int)
> > #Mandatory:	No
> > #Description:	The temperature of the processor in degrees Celsius
> > 
> 
> Looks good, we can always add other properties here like 
> system.processor.vendor_id and so on..
> 
> > -------------------------------------------
> > Namespace:	system.display_device
> > Description:	Device objects with the capability display_device represent all display devices in the system. The following properties are available:
> > -------------------------------------------
> > 
> > Key:		system.display_device.type (string)
> > Mandatory:	Yes
> > Values:
> >  lcd: 		LCD panel
> >  crt: 		CRT tube
> >  tv_out: 	TV Out
> > Description:	The type of display device
> > 
> > Key:		system.display_device.lcd.brightness (int)
> > Mandatory:	No
> > Description:	The brightness of the LCD panel in percent
> > Key:		Only valid if system.display_device.type is lcd
> > 
> 
> 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
> like that... I think also that X.org might provide this information
> 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 just noted that there is an file called edid1 in the sysfs tree provided by
the radeonfb driver on my system, which we could probably use for this kind of
stuff. Dunno if it's there for other framebuffer drivers, but it would be an
interesting option i guess.

  Sjoerd
-- 
The Wright Bothers weren't the first to fly.  They were just the first
not to crash.
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal