Feature requests for hal battery backend.

[Danny Kukawka]

On Sunday 31 July 2005 00:48, Richard Hughes wrote:
> No, for 99% of users (mWh) the value is the same. For mAh users the
> value will more accurate as it takes into account the voltage.
>
> Without a patch like this you could not use battery.charge_level.current
> and battery.charge_level.last_full to calculate correctly the remaining
> time (for mAh systems) - the maths doesn't work. For mWh systems, the
> calculation is valid, and battery.charge_level.current =
> battery.reporting.current so nothing would appear different.
>
> From an application API point of view nothing changes, just the
> battery.charge_level.current and battery.time_remaining keys are more
> mathematically correct now, and should give textbook answers.
>
> > I would prefer to add new keys for normalised values/units, so everyone
> > is free to use the _new_ keys if he likes.
>
> Disagree, if an application want the ACPI raw values (i.e. what ACPI
> provides) it can look at the battery.reporting.current key.
>
> If it wants proper, sanitised readings (i.e. that make sense), it can
> use the battery.charge_level.current like before.
>
> > > This way we do not have to add 3 extra keys to every battery object.
> >
> > Hmm ... I'm confused what is the big difference between to add 4
> > normalised and 5 reporting keys and the opposite way ?
>
> This way we keep compatibility (API) the same and we fix the mAh
> inaccuracy experienced by some users.
>
> We still present the same API as we used to, but converting mAh into
> mWh, basically.
>
> Is that explanation okay?

Hmm ...  but in this case you must also normalise all other mAh/mWh related 
keys e.g. battery.charge_level.warning. Or not?

Cheers,

Danny
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal