ACPI/PMU procfs HAL test program. Version 002.

[Richard Hughes]

Danny Kukawka <danny.kukawka <at> web.de> writes:
> > Polling is generally bad, but I don't think we have any other choices, 
> > we? acpid(?)
> 
> There are two ways to get actually informations about battery states:
> 1.) wait for ACPI Battery Event 
> Problem: 
> 	- not supported by all machines, and no info if or if not
> 	- you can't say when a event is sent by the BIOS (maybe every 
> 	  percent +/-, maybe other interval --> unknown)

ACPI events are not great from the quick look that I've given them, although
they are good as they remove the polling for some events. Maybe a place for 
them somewhere for some objects.
 
> 2.) poll /proc/acpi/battery/BAT0/state 
> Problem:
> 	- systemload if you poll too often.

It it measurable? Is it a problem from a power consumption or 
proccessor load PoV?

I agree polling a battery every second for it's design capacity rating is a 
bad idea (only needs to be done at coldplug) but wouldn't the procfs entries 
be cached into RAM and thus lightning quick?
 
> I think we must implement both an make configurable what the user want to 
>  use. 
> IMHO for polling batterystate  60 sec interval is o.k.

Yes, configuration options are a good idea.

What about for each device:

system.refresh.enabled = BOOL
if TRUE
 system.refresh.interval = INT (seconds)
 
> Exactly what I had meant. I would only get a information if something on 
> battery (or ac-adapter, ....) is changed in powersave and kpowersave. 
> A DBus 
> event is okay for me.

Good :-)

> 
> Which information about acpi/apm/proc should hal still provide (if available) 
> (in a own namespace, maybe ACPI, not proc) ?
> 
> 	acpi.fan.*
> 	acpi.sleep [s0 - x]
> 	acpi.thermal_zone.*
> 	acpi.wakeup
> 	processor.id [integer]
> ...
>         battery.discharge.remainig.percent
> 

We've sortof already covered some of this:

http://cvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal- spec.html

Also if you run my program (procfs-hal) on any ACPI/PMU based machine, you'll
see the sort of thing we are working towards merging into HAL.

Richard.

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