ACPI/PMU procfs HAL test program. Version 002.

[Danny Kukawka]

On Monday 24 January 2005 13:58, Richard Hughes wrote:
> Danny Kukawka <danny.kukawka <at> web.de> writes:
> > On Monday 24 January 2005 11:30, Paul Ionescu wrote:
>
> I do believe that HAL should be the main polling daemon, so to speak.

o.k.

> Polling is generally bad, but I don't think we have any other choices, do
> 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 remainig 	
	  percent +/-, maybe other interval --> unknown)

2.) poll /proc/acpi/battery/BAT0/state 
Problem:
	- systemload if you poll too often.

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, they would be getting them all from HAL in the future, e.g.
> PowerManager, powersave or any other "do something if this" type daemon.

O.K, I prefer this also.

> You don't want specifics in these high level interfaces, for instance,
> PowerManager should be able to call Restart() or SetLCDBrightness() without
> worrying whether the macine is PMU/APM/ACPI.
> This will make sure all the specific (and common) code is in HAL, and that
> the public methods are all common, and well defined.
>
> > Is there a way to say HAL something like: "send me a message if a
> > (defined) value changed"?
>
> Yes, a DBus event. I'm not sure, but I think it would be pretty trivial to
> register a dbus listener, and just sent out an event to the listener:
> /bla_bla/ac_adaptor.present FALSE

> when the property is changed, rather than to have to query HAL every few
> 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.

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]
	processor.states [C1,C2,C3]
	processor.state.active [C1,C2,C3]
	processor.state.current [C1,C2,C3]
	processor.throttling [yes/no]
	processor.limit [yes/no]
	processor.power_management [yes/no]
	processor.bus_mastering_control [yes/no]

Maybe: (must be calculated)
	battery.charge.remainig.time                    
        battery.charge.remainig.percent
        battery.discharge.remainig.time
        battery.discharge.remainig.percent

Other?

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