Design weakness in /proc/pmu ?!

It's difficult to find a suitable answer. The time remaining is obtained directly from the PMU on newer machines, we don't really have the proper algorithm to calculate it on these, what machine did you get those dumps from ? We may simply have a bug on older machine calculation causing that 0, in which case it has to be fixed.

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Hi,

Recently I played a lot with /proc/pmu to get reliable battery states.

In the current design each battery has a value time rem. calculated out of that battery's parameters. This calculations will fail if more than one battery is attached to the computer as the following snapshot of a wallstreet powerbook shows:

$ cat /proc/pmu/info
PMU driver version     : 2
PMU firmware version   : 0a
AC Power               : 0
Battery count          : 2

$ cat /proc/pmu/battery_0

flags : 00000001
charge : 2619
max_charge : 2639
current : 0
voltage : 16489
time rem. : 0

$ cat /proc/pmu/battery_1

flags : 00000001
charge : 261
max_charge : 2529
current : -1318
voltage : 14318
time rem. : 712

As you could see battery 0 is fully charged but the time remaining value is calculated as zero. If you now calculate the overall time remaining simply as sum of the time rem. of each battery you will get a wrong time and possibly bother the user with unnessecary warnings.

I suggest to move the time rem. value out of the /proc/battery_* files into the /proc/info file and store an overall time-remaining value there. Because the time until power off is a quality of the whole system mainly defined through the overall power consumption. It isn't a feature of a single battery.

What do you think?

Regards
Matthias

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Greetings Ben, Matthias, and others.

Each battery in the current code is handled seperately. Each battery has its own value for current. A battery not in use has a value of 0, which the time calculations handle by saying 0 time left, as if you're plugged in and not charging, this is what would be expected.

So its not really a bug, just an implemenetation decision that mirrors the hardware. But I'm all for Matthias' suggestion. The alternative is to do what I had the gkrellm pmu plugin do. (without letting it know how to redundantly find the time on its own just using ratios, but that assumes a linear function)

--
Joseph P. Garcia http://www.lycestra.com/ http://lidar.ssec.wisc.edu/
CS Undergraduate Student Employee - Systems Programmer
University of Wisconsin - Madison UW Lidar Group

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Exactly that is our problem. The dumps are from a PowerBook Wallstreet and sent to me because I did the calculation in pbbuttonsd as I have written and ran into this problem.

On newer machines do you get a single overall system value for the time remaining or one for each battery? Nevertheless it would be easy to calculate _one_ valid value and store it in /proc/pmu/info.

And if the algorithm to calculate the remaining time wasn't known the more it would be nessecary to have a reliable overall time because applications can't find it by themselves anymore in the future. Work-arounds weren't possible due to lack of information.

Yes and if the number of battery types increases every application will run into problems calulating missing values on there own. Only the kernel could do this and as Ben already correctly said: He would keep such a complicated piece of code in one single place.

The move would make the information in /proc/pmu more logical because all values stored in /proc/pmu/batery_* except the remaining time were all features of that battery and could stand for itself. The remaining time makes only sense if you know the current power consumption of the _whole_ computer too.

It would also be fantasic if the capacitance in mAh (mili Ampere hours)or maybe mWh (mili Watt hours) could be added to the battery files, but I'm not shure if you get this information from the PMU or could calculate it out of known parameters. And at the moment this value is only nice-to-have.

Best Regards
Matthias

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Not that easy if we want it really valid. Note that we could still use the other (older) PMU battery functions, maybe one of them returns some kind of cumulated time.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/