hal and battery status

[Nathaniel McCallum]

On Mon, 2004-07-05 at 23:42 +0200, David Zeuthen wrote:
> On Sun, 2004-07-04 at 23:31 -0400, Nathaniel McCallum wrote:
> > Well, just this last week I disected the acpid and acpi kernel code.
> > So, while I have it fresh in my mind, how can I help?
> > 
> 
> That would be nice - I'm not sure myself how best to do this, ACPI seems
> utterly complex and I haven't even looked at how Apple or other
> architectures handles this
> 
> I guess hashing out some kind of design first would be a good start?  I
> mean we want to make a portable design; here are some thoughts
> 
>  o Should we have a separate HalDevice for e.g. power buttons,
>    lid buttons, battery bays? My answer to that is probably yes.
> 
>  o We should add HalDevice objects for CPU's as well.
> 
>  o Fans and thermal zones seem to be less important, I mean the
>    kernel or firmware enforces policy here, right?, so only the effects
>    are visible, e.g. the kernel emits a "processor is overheating"
>    signal at the appropriate time and we should proxy this in HAL and
>    emit a DeviceCondition at the appropriate time.
> 
>    Now, the desktop can enforce policy by lowering the CPU frequency
>    or something in response to this.
> 
>  o What about stuff like disabling a media bay? My old Dell Inspiron
>    7500 got such a thing and this works on Windows so I can replace
>    my DVD/LS120 combo with a CD-RW/floppy combo. I think this should
>    be handled by existing power management in the kernel, when that
>    works that is, e.g. at some point we can export the Suspend() or
>    Standby() method on a HalDevice.
> 
> We need to keep the scope in mind, we always need to keep the scope in
> mind :-) So, the sole reason for adding such functionality to HAL is to
> be able to easily write policy agents, e.g. provide all the needed
> information  to make a policy decision in an easily accessible place
> that abstracts the underlying system, e.g. HAL. 
> 
> Thus, sticking to 
> 
>  o Power, Standby and Lid etc. buttons
>  o Battery bays
>  o CPU
> 
> with suitable generic properties might be a good choice? Now, granted,
> I'm curious what other peoples take on this is :-)

Well, I'm not very knowledgeable about apm or pmud (apples power
management).  However, we are generally dealing with several types of
data:
	1. Hardware attributes (non-changing, ie. battery size)
	2. State attributes (changing, ie. current battery charge)
	3. Events

All this stuff is available in /proc/acpi/... I have no idea what will
be available in sysfs in the future, if ever.

Regarding the splitting up of devices (power button, lid, etc).  I don't
think there is any info for several of those devices (other than
events).  ie. for the types of data listed above, power buttons, lids,
etc have only events.  So I'm not sure how exactly we would profile it. 
What about profiling acpi as the device? (and apm and pmud as seperate
devices).  Other than that, I like your division:  Power, standby and
lid etc buttons, battery bays, and cpu.

I'm really not familiar with how hal works internally, but I can learn.

Nathaniel


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