[PATCH] reduce useless changes on APM battery.remaining_time

[Danny Kukawka]

On Friday 05 May 2006 18:17, Richard Hughes wrote:
> On Fri, 2006-05-05 at 17:29 +0200, Danny Kukawka wrote:
> > If there is a application using hal and listen to the change (of the
> > property)
> > ever two seconds, followed by do something via dbus (e.g. ask hal or
> > powersaved for some information) this can result in a high load of
> > dbus (see
> > e.g. https://bugzilla.novell.com/show_bug.cgi?id=157905).
>
> I get:
>
> You are not authorized to access bug #157905. To see this bug, you must
> first log in to an account with the appropriate permissions.

Okay, you need a account and the related permissions. I remove the link from 
the code and changelog before commit.

> Could you post a few more details pls, thanks.

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.

If you e.g. listen with KPowersave (or a other tool) via e.g. powersave or 
directly for this key (if the machine run on battery), you get every 2 
seconds a 'signal' from HAL about changed value of battery.remaining_time. If 
you in this case e.g. check several keys from HAL or e.g. via powersave 
(battery information) you get always (tested on serveral machines) a process 
load between 5 and 25 % for the dbus daemon process. 

This is maybe also a problem in DBUS or the dbus-qt bindings, but in fact we 
don't need to change this key every 2 seconds if the value jumps with each 
change forward/backward. This is IMO only confusing programms using this 
information.

Danny