ACPI/PMU procfs HAL test program. Version 002.
Danny Kukawka
danny.kukawka at web.de
Mon Jan 24 09:35:21 PST 2005
On Monday 24 January 2005 15:42, Richard Hughes wrote:
> 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?
Yes, I think. I saw different where /proc/acpi/battery/BAT0/state
(or /proc/acpi/battery/BAT0/info) was polled during you watch video with
mplayer and the video jerk a second. It's different from machine to machine,
depending on the BIOS.
> 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?
No, not right. First: what is if you remove or exchange the battery?
Second: not in RAM, see Sjoerd's mail.
> > 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)
It's o.k. Maybe we need for battery (if we use ACPI battery events):
- system.getinfo_from.acpi_events = BOOL
- system.getinfo_from.poll = BOOL
> > 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.
O.k., I saw.
Danny
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal
More information about the Hal
mailing list