[PATCH] reduce useless changes on APM battery.remaining_time

Richard Hughes hughsient at gmail.com
Sun May 7 01:52:52 PDT 2006


On Sat, 2006-05-06 at 12:07 +0200, Danny Kukawka wrote:
> 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.

With apm you don't get rate (unless you compute it manually), so we have
to trust this value.

> 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. 

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 avoids having to do lots of non-required lookups every time a key
changes.

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.

> 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.

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

I would rather this patch not be applied.

Richard.




More information about the hal mailing list