Originally Posted by Estel (Post 1403560)

[...]

cssu's battery applet reports *absurd* values as battery max capacity, and for worse, it does so on purpose. It require some explaining, so bear with me:

Probably most of you are aware of the 3th pin of the battery, dubbed "BMI pin". There is a resistor between it and ground pin, which in theory, should provide information about "design capacity" of the battery - i.e. capacity battery should have, when new. It is *not* any form of measurement - it's just "hardcoded" by placing dumb resistor there, of set resistance value. Every value from reserved range is interpreted as some capacity.

The thing is, that no one - except Nokia - cares about that, and every 3rd party battery manufacturer in existence put there a random resistor of ~100kOhm value. Nor should they care, as it's dumbest way of giving *any* info about battery capacity - it doesn't compensate for battery aging, changes with temperature (as resistance changes), and overall, is completely and utterly useless. Heck, even Nokia doesn't seem to care much, as for batches of they upgraded BL-5J design, the sometimes correctly state ~1400 mAh, and sometimes, use same resistor as from older, 1300 mAh.
---

Now, back to battery applet - for some completely crazy reasons, Pali insisted on taking *this* info for applet's info about battery's max capacity. It is *worst* place to get that info - you could, as good, cat a /dev/urandom. Data used should be from bq27x0 chipset, and only from there.

At the same time, current capacity *is* pulled form bq27x00 (in case of someone, like me, using kernel-power and bme replacement), so it ends up in humorous, but completely crap'ish results. for example, currently, battery meter show that I have
...because current capacity is real (I'm using dual-scud battery), and max-capacity is taken from *** that resistor "hardcoded" value.
:)

[...]

Originally Posted by marmistrz (Post 1403652)

And as I guess, one cannot specify the source (bq27x00, bmi, or static override via config file - it would be a workaround)?

I expierienced this silly 1214/1170 mAh too.

Originally Posted by shadowjk (Post 1403672)

With stock bme, new applet seems to use last_full, not design capacity. I have a 10 cycles.old BL-5J, design capacity 1415, bq27200 calibrated capacity of 1515, and bme last_full of 1215.

We all knew the mAh values reported by bme are more or less made up. The applet seems to report different percentage values than bme. bme will happily report a percentage that arithmetically doesnt add up with reporting.current/last_full or /design... For compatibility with old applet, using the percentage value reported by bme would probably make more sense.

Originally Posted by pali (Post 1405817)

@Estel: there is already (for a long time) gconf key for specifing source of design capacity... By default it is from bq27200 and if battery is not calibrated it fallback to rx51_battery... If there is bug in that gconf key or somewhere else, you can report it. But I think that your problem has been already resolved by introducing gconf key for specifing source.

@merlin1991: Do you know, why are libqt4-meegographicssystem and libqt4-meegographicssystemhelper packages required in CSSU metapackage?

Originally Posted by pali (Post 1405817)

@Estel: there is already (for a long time) gconf key for specifing source of design capacity... By default it is from bq27200 and if battery is not calibrated it fallback to rx51_battery... If there is bug in that gconf key or somewhere else, you can report it. But I think that your problem has been already resolved by introducing gconf key for specifing source.