[PATCH] reduce useless changes on APM battery.remaining_time

[Danny Kukawka]

On Sunday 07 May 2006 10:52, Richard Hughes wrote:
> On Sat, 2006-05-06 at 12:07 +0200, Danny Kukawka wrote:
> > On Friday 05 May 2006 18:17, Richard Hughes wrote:
> > First it's useless to change the value every 2 seconds because the
> > returned value from poll /proc/apm is always changing (in the most cases
> > plus some minutes and with the next poll minus several minutes) and not
> > really trustable.
>
> With apm you don't get rate (unless you compute it manually), so we have
> to trust this value.

No, we can't trust this values if you poll this interface every 2 seconds, if 
you get with every poll a new value changing +/- serveral minutes. They are 
not trustable by design. This is the problem.

> Surely this is a bug in KPowersave? In g-p-m we cache the values
> per-device and then use those cached values to compute the per-system
> values.

This is no bug in KPowersave. I can this also produce with other tools, IMO. 

> This avoids having to do lots of non-required lookups every time a key
> changes.

This has nothing to do with this problem. If I need to check complete other 
information in othere dbus using services.

> This is no different on my laptop with ACPI -- when discharging I get a
> few keys changing every couple of seconds, which is great for me as it
> makes the data logging aspect of g-p-m feel really snappy and
> responsive.

But you get not every 2 seconds a changed value which is _not_ trustable and 
also not usefull because the value jumps with each change forward and 
backward. If you poll and change the value only every minute (or maybe every 
30 seconds) you get more trustable values and you can use them also for 
logging. Btw. you don't get this jumps with ACPI. 

> Erm, seems like it's only confusing KPowersave...

No, this is not only confusing KPowersave. See above.

> I would rather this patch not be applied.

But I would

Danny