[ltp] Re: Generic battery interface

[linux-thinkpad@linux-thinkpad.org]

--==_Exmh_1154307514_2988P
Content-Type: text/plain; charset=us-ascii

On Sun, 30 Jul 2006 14:48:07 +0300, Shem Multinymous said:
> On 7/30/06, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> > If the program says '100ms' because it knows it will need to do a GUI update
> > then, and you block it for 5 seconds because that's when the next value
> > update happens, the user is stuck looking at their gkrellm or whatever not
> > doing anything at all for 4.9 seconds....

> Please read my detailed proposal, posted (and resivsed) later.

OK, if you meant this one (that hadn't shown up here before I hit 'send'):

On Sun, 30 Jul 2006 13:14:10 +0300, Shem Multinymous said:
> Actually my solution was "any update but no sooner than N msecs". So
> you might be getting a readout that's N-1 msecs old, which was
> meanwhile cached by the driver. If you care about that, you need to
> use interleave those polls with msleep()s; see my recent detailed
> post. You'll still doing at most one msleep() per fetched readout,
> regardless of how frequently the driver provides them.

That has slightly different semantics indeed, and avoids the issue I
was commenting about.  A gkrellm-ish program can query every 100ms and
get a cached value 49 times out of 50 for a value that's hardware-updated
every 5 seconds, and all will be well (of course, there's room for some
added optimization, but I suspect trying to add that will end up more
expensive than just re-reading the same cached value, unless the kernel has
a good way to pass back a good hint of when the next update will be...)

--==_Exmh_1154307514_2988P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFEzVW6cC3lWbTT17ARAsCEAKClFzQFGLORbD/7Kf+zx65ekej/VACdFtst
UQgPDm8bdpHwYRiAxim+1sY=
=J8Ki
-----END PGP SIGNATURE-----

--==_Exmh_1154307514_2988P--