On Mon, Feb 27, 2006 at 06:54:50PM +0300, Valeriy E. Ushakov wrote:
> On Mon, Feb 27, 2006 at 16:46:05 +0100, Peter Postma wrote:
> 
> > > In apm code you need to or in the charging status.  I.e.
> > > 
> > >     if (j720pwr_get_charge_status(ctx) == 0)
> > >         state |= APM_BATT_FLAG_CHARGING;
> > >               ^^
> > 
> > Yes, but then the apmdev code will never show it... see the
> > if-else-if's in apmdev.c around line 902, maybe we should fix that?
> > (to check for the charge flag first?)
> 
> Well, hpcapm claims to be APM v1.2.  APM v1.2 should set the flags.
> 
> What other code does is irrelevant.  If what that other code does is
> wrong - that other code should be fixed (it's not that easy b/c our
> apm api doesn't support APM 1.2 it seems).  My point is, don't write
> code that "depends" on bugs elsewhere, if you code is right, only the
> bug needs to be fixed, if your code tries to be "helpful", the bug
> *and* your code needs to be fixed.
> 

Ok. But I wasn't sure if hpcapm was wrong so I tried to work around it.
Thanks for pointing this out.

> > > Oh, and why don't report actual percentage instead of doing in 10%
> > > steps?  (c.f. j6x0pwr)
> > > 
> > 
> > With a formule? That's how it's done in the current code, but it
> > doesn't work very well. You can see this in the battery_table, the
> > difference between 100 and 80 percent is only 10, but the difference
> > between 40 and 20 percent is 70.  I've got the values from checking
> > when the status changes in winCE and then quickly boot to netbsd and
> > check the value there.
> 
> For 680 I thought that reporting %age is more useful than reportin in
> 10% steps, even if it's non-linear.  May be we can do linear
> interpolation if we want the values to better reflect time remaing vs
> charge remaing?
> 

That might be a nice solution, I'll see what I can do.

-- 
Peter Postma