Re: [PATCH v2] Re: Battery class driver.

["Shem Multinymous" <multinymous@gmail.com>]

Hi David,

On 10/25/06, David Woodhouse <dwmw2@infradead.org> wrote:
> > > For sane hardware where we get an interrupt on such changes, that's fine
> > > -- but I'm wary of having to implement that by making the kernel poll
> > > for them; especially if/when there's nothing in userspace which cares.
> >
> > HAL and gnome-power-manager? There should only be a few changing values
> > on charging and discharging, and one every percentage point change isn't
> > a lot.

What about current and power? These change very quickly.

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.


> My point is that if HAL isn't running, we shouldn't bother to poll. If
> HAL _is_ running, then _it_ could poll, if the hardware isn't capable of
> generating events. But let's leave that on the TODO list for now.

Agreed.



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

So there's no choice, you must use a generic term + units (and I
suggest following the Smart Battery Data Specification's term
"capacity"). This also takes care of the inevitable hardware that
reports in other units, such as normalized percent.


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

 Shem
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/