[PATCH v2] Re: Battery class driver.

[David Woodhouse]

On Wed, 2006-10-25 at 11:54 +0200, Shem Multinymous wrote:
> What about current and power? These change very quickly.

I don't think we'd want to generate events for those, except perhaps if
they exceed certain thresholds.

> BTW, your patch doesn't address the instantaneous vs. average readout
> issue in the Smart Battery Data Specification and ThinkPads. Nor a
> number of other issues I brought up earlier.

True; it's a work-in-progress, and was actually sent just as I was
boarding a plane. I shall attempt to go back through the messages I've
received and address anything else that's pending.

If you can summarise the bits I've missed in the meantime that would be 
wonderfully useful -- especially if you could do so in 'diff -u' form :)

> > one of the things I plan is to remove 'charge_units' and provide both
> > 'design_charge' and 'design_energy' (also {energy,charge}_last,
> > _*_thresh etc.) to cover the mWh vs. mAh cases.
> 
> You can't do this conversion, since the voltage is not constant.
> Typically the voltage drops when the charge goes down, so you'll be
> grossly overestimating the available energy it. And the effect varies
> with battery chemistry and condition.

Absolutely. I don't want to do the conversion -- I want to present the
raw data. I was just a question of whether I provide 'capacity' and
'units' properties, or whether I provide 'capacity_mWh' and
'capacity_mAh' properties (only one of which, presumably, would be
available for any given battery). Likewise for the rates, thresholds,
etc.

> > I'd rather show it as a hex value 'flags' than
> > split it up. But I still think that the current 'present,charging,low'
> > is best.
> 
> Then please make space-separated rather than comma-separated. That's
> easier to parse in shell and C.

Ok. Committed to git://git.infradead.org/battery-2.6.git

-- 
dwmw2