Comment 101 for bug 629258

Thanks for your repo upload, and your comments, Brian! I checked your suggestion, but the only (compiled) changes from my patch are to 'upowerd' which is included in the upower .deb that I posted, rather than the library .debs.

The runtime-estimation code in the patch is only activated if the reported current is identically 0, which is what is reported on my laptop. This is the same condition as was supposed to be activated by the existing estimation code in upower, but it wasn't because the condition was not properly implemented (which is a good thing, because the estimation code was broken and could not have worked anyway).

It could be that angus's machine reports a non-zero current, but one that is still nonsensical (e.g. a negative value) - in this case, the patch code won't be triggered, but gpm still won't be able to show a sensible runtime estimate. However, I need to see the output from either gnome-power-statistics, or (even better) a debug version of upower to work out if this is the case.

It might even be that his upower/battery combination doesn't give a sensible measurement of current charge state, in which case the runtime-estimation code can't work anyway.

Nonetheless, we've had two +ve reports, and only 1 report of failure, so far, which means that hopefully the bug will be fixed for most people, if not all.

Re: the fluctuating estimates, it might be worth playing with the upower-supply refresh interval, or the number of historical charge measurements that are averaged over when computing the rate, to improve this if people are finding the estimates problematic. However, I do find that laptop runtime indicators do tend to fluctuate anyway, esp. when the conditions of the system are changing (e.g. shortly after a reboot), and we are always going to have to put up with a slightly tardy and unreliable estimate when we are using estimates derived from a series of charge measurements, rather than a semi-accurate electrical current measurement.

thanks, andy