Bug 182940 - detailed battery information display
Summary: detailed battery information display
Status: RESOLVED FIXED
Alias: None
Product: kinfocenter
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR wishlist
Target Milestone: ---
Assignee: David Hubner
URL:
Keywords:
: 82489 182757 192336 324201 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-02-03 01:26 UTC by Daniele Russo
Modified: 2022-09-27 20:42 UTC (History)
16 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.25


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniele Russo 2009-02-03 01:26:24 UTC
Version:            (using KDE 4.2.0)
OS:                Linux
Installed from:    Ubuntu Packages

I think it could be very useful to have detailed infos on battery.In gnome (Ubuntu) the battery applet shows the number code of the battery,the original capacity when the battery was new and the actual one,so you can know how old is your battery and when it’s time to buy a newer one.This feature,as reported on some sites ( http://www.tomsguide.com/us/Windows-seven-Netbook,review-1164-5.html ) will be included also in Windows 7 and has been quite advertised:
"Some details might even make it into friendlier diagnostics. One option shows not just the current capacity of your battery, but also what its designed capacity is and how much of a charge it accepted the last time it charged it fully—so you can tell when your battery is losing so much capacity that you need to replace it. Stemen explains, “batteries degrade over time and we didn’t have a good way up until now to look at a system and say ‘how degraded is my battery’?"

Dario Freddi also told me this informations are already available in Solid,so why don't we show them??? :) Than you very much

Daniele
Comment 1 Lamarque V. Souza 2009-03-07 20:25:14 UTC
The applet should also show the remaining time, that is the most wanted featured of any battery monitor, why battery plasmoid does not have it?
Comment 2 Daniele Russo 2009-04-29 12:14:49 UTC
there's also an Idea posted on brainstorm forum if you accept some suggestions http://forum.kde.org/show-battery-info-t-42879.html
Comment 3 Aaron J. Seigo 2009-05-01 05:01:49 UTC
@Daniele: good idea; i don't think it makes much sense in the main popup window (how often do you need that information compared to the rest of the data in there, which is already pretty voluminous?) but perhaps as a link in it, e.g. "Show battery health.." that pops up a window or displays additional content.

@Lamarque:
> why battery plasmoid does not have it?

because those numbers are complete crap 99% of the time. remaining % is a much less misleading number.
Comment 4 Lamarque V. Souza 2009-05-01 15:46:49 UTC
@Aaron 
> because those numbers are complete crap 99% of the time. remaining % is a much less misleading number.

I do not agree with that. Anybody who uses a notebook wants to know how much time the battery could last. The biggest problem is how to calculate the remaining time accurately, just not showing it is not a solution. I have worked with ClassmatePC before and had problems with the remaining time being unaccurate when the battery is discharging fast, when the battery was discharing slowly the tim was accurate. By that time I had found the problem was the hal daemon that makes little effort to calculate the battery discharge rate when it is not available from the battery controller (believe me, that happens quite offten). In ClassmatePC case I have also found the problem is not the battery controller but the BIOS that does not show this information in /proc/acpi/battery/BAT1/state. When I hacked the BIOS's DSDT to how this information the reamining time was much more accurate and reliable.

The remaining % does not give the information we want (how much time we still have?). 1% could mean 10 minutes or 2 minutes depending on how fast the battery is discharging. Just because is goes down steadly does not mean it is really useful. Another example, my cell phone: if it shows 80% now and I make a call some seconds later is shows 70%, if I stop talking some seconds latter it shows 78%. If the battery system is unreliable than showing anything from it will also be unrealiable, including the %, but that is not KDE's concerns, so show it anyway or at least give to the users the option to show it or not, hinding it from users will not help. In the hal daeamon's case they could improve how they calculate the battery discharge rate. That would solve the "crap remaining time" for several people where the BIOS is not providing the needed information to calculate the remaining time.

I think the plasmoid should let the user choose what information s/he wants to be shown, you could even let the remaining time unchecked, but I believe most people will not agree with that and some bug entries will show up here to make it checked by default.
Comment 5 Vincent Petry 2009-05-11 16:14:43 UTC
I agree with  Lamarque Vieira Souza. The remaining time showed by kpowersave in KDE 3 was fine for me. It doesn't have to be 100% accurate though, just give a rough idea how much time is left.
Comment 6 Vincent Petry 2009-05-11 16:16:18 UTC
*** This bug has been confirmed by popular vote. ***
Comment 7 Aaron J. Seigo 2009-05-11 21:26:08 UTC
> Anybody who uses a notebook wants to know how much
> time the battery could last. 

that's obviously not what the discussion is about. i'd like pink ponies in my front lawn, but i doubt that will happen either.

> The biggest problem is how to calculate the remaining time accurately,

yes, which means knowing what the future power draw will be. if i let my laptop sit idle, that 10% will last a good while. if i start compiling or watching video or viewing a heavy flash website it's going to last a lot less time. if i stop doing those things, it'll last a while longer too.

so a "how long you have left" is really just "how long you have left if you and the computer keep doing exactly what they are doing". 

so it is very common to see such measurements jump all over the place over the course of usage "10 minutes", "40 minutes", "25 minutes", etc.. i agree it's useful if you use the computer in a very consistent pattern because then the calculation will actually work; for anyone else it is pretty much useless and even misleading.

"If the battery system is unreliable than showing anything from it will
also be unrealiable,"

that's a completely different issue that is not even relevant to this discussion, for the very reasons you note.
Comment 8 Lamarque V. Souza 2009-05-11 22:05:43 UTC
(In reply to comment #7)
> that's obviously not what the discussion is about. i'd like pink ponies in my
> front lawn, but i doubt that will happen either.

It obviously is or this bug entry would have not even been opened.
 
> > The biggest problem is how to calculate the remaining time accurately,
> 
> yes, which means knowing what the future power draw will be.

No, this is an estimation, not a exact calculation. Nobody knows about the future, but we know about the past and the present, so use what we already know to estimate the future (estimate, not forsee).

> if i let my laptop
> sit idle, that 10% will last a good while. if i start compiling or watching
> video or viewing a heavy flash website it's going to last a lot less time. if i
> stop doing those things, it'll last a while longer too.
> 
> so a "how long you have left" is really just "how long you have left if you and
> the computer keep doing exactly what they are doing". 
> 
> so it is very common to see such measurements jump all over the place over the
> course of usage "10 minutes", "40 minutes", "25 minutes", etc.. i agree it's
> useful if you use the computer in a very consistent pattern because then the
> calculation will actually work; for anyone else it is pretty much useless and
> even misleading.


 
> "If the battery system is unreliable than showing anything from it will
> also be unrealiable,"
> 
> that's a completely different issue that is not even relevant to this
> discussion, for the very reasons you note.
Comment 9 Angel Blue01 2009-05-11 22:12:28 UTC
I'd like an estimate on the time remaining, based on current usage. I realize that its going to change if I do something else, but if for example I have just a browser open and all I plan on doing is Web browsing, the factors are going to stay pretty constant so it can give me a reasable estimate of how long I have left on battery life.
Time is a lot more useful to me than percentage. If I have a break of several hours between activities but my battery won't last that long, I'd better think of other things to do :-)
Comment 10 Lamarque V. Souza 2009-05-11 22:19:40 UTC
Sorry, I hitted the commit button for accident. The point is I do not see any
reason for not showing those information. If someone knows how to read it (I
know) it is usefull. Besides, there is not bug entry in KDE's bugzilla
complaining about battery remaining time being wrong, but there is two other
bug entries asking for showing the reamaing time instead of percentage:

https://bugs.kde.org/show_bug.cgi?id=192336
https://bugs.kde.org/show_bug.cgi?id=18660
Comment 11 Aaron J. Seigo 2009-05-11 22:20:21 UTC
> It obviously is or this bug entry would have not even been opened.

*sigh* what i meant was that nobody is arguing that some people want this feature.

that doesn't make it realistically possible to do properly.

> No, this is an estimation, not a exact calculation.

an estimation must at least have relationship to reality. i have yet to see a battery time estimate that actually achieves that. feel free to provide a working algorithm.

> but if for example I have just
> a browser open and all I plan on doing is Web browsing

even that isn't true; when i read planetkde my power usage is very low, but when i'm watching videos on youtube it's not.

> If I have a break of several
> hours between activities but my battery won't last that long

and how does the system know you are taking a break of several hours? how does it know what the computer will be doing during those several hours?

this is all hoping for pigs to fly.
Comment 12 Lamarque V. Souza 2009-05-11 22:28:03 UTC
> > No, this is an estimation, not a exact calculation.
> 
> an estimation must at least have relationship to reality. i have yet to see a
> battery time estimate that actually achieves that. feel free to provide a
> working algorithm.

It has relationship with reality... with the past reality. The only perfect calculation would be if know about the future, since that is not possible we do the best we can using the past discharging rate. It is pretty obvious that the result will not be exact, that is why we call it estimation. Besides, most battery controllers already provides the instant discharing rate, which is pretty good for this purpose. If you want a better algorithm will have to create a time machine first.
Comment 13 Angel Blue01 2009-05-11 22:37:07 UTC
My old laptop had Windows XP, and Windows' predictions of battery life were pretty accurate, or at least accurate enough for me to decide by what time to turn it off ("Windows says 30 minutes remaining, right now its noon, so I'd better turn it off by 12:20") and make other plans for the remaining time in my break ("...and my break goes until 1:00 PM so let's see what reading material is around me for 12:20."). That shows its possible to have an estimate that at least roughly coresponds to reality, of course I don't know how Windows got that figure, only that it was good enough.
Comment 14 Aaron J. Seigo 2009-05-11 22:54:04 UTC
"The only perfect calculation would be if know about the future, since that is not possible we do the best we can using the past discharging rate."

which is the entire problem: this is a future prediction based on the past as if the future is the same as the recent past. this is simply _not the case_. it's made even worse by dynamic cpu frequency scaling and other such on-demand power saving technologies.

"If you want a better algorithm will have to create a time machine first."

exactly my point. thank you.

@Angel Blue01: sure, i've used battery timers in kde3 and elsewhere that were good enough as long as my usage patterns were consistent.

see, this is where there is a huge disconnect going on here:

we have a couple of people whose usage patterns are consistent or who really don't care about it being inaccurate trying to make a policy decision for everyone else as well. "it works for me" doesn't justify introducing a broken feature for everyone else.

that is the end of this part of the discussion afaic.


what _would_ make sense to me, and the only reason this item hasn't just been summarily closed by me yet, is one or all of the following:

* a min/max time calculation based on the range of discharge seen
* time since last charge (though this gets tricky with partial chargings)

but a simple, and usually innacurate, "how much longer you have" reding isn't something i'm interested in seeing.
Comment 15 Lamarque V. Souza 2009-05-11 23:26:34 UTC
> exactly my point. thank you.

You are welcome. So can we, KDE users, have this feature in the next release?
 
> we have a couple of people whose usage patterns are consistent or who really
> don't care about it being inaccurate trying to make a policy decision for
> everyone else as well. "it works for me" doesn't justify introducing a broken
> feature for everyone else.

What I am seeing is a KDE developer making a decison for everyone else based in his own dislike about battery time estimation. Give us the choice to use it or not, you do not need to like it to do this.
 
> what _would_ make sense to me, and the only reason this item hasn't just been
> summarily closed by me yet, is one or all of the following:
> 
> * a min/max time calculation based on the range of discharge seen

It seems you have never tried to estimate battery's remaining time. The min/max change will be so big (10 minutes or even half a hour depending on the sample rate) that it will have no use. We want the average estimation not the min/man and using the battery controller's discharge rate information is the best approach to do it because it will drain less battery power. Doing so much calculation to get the min/max will drain more battery power and make the CPU waking up so often that it will hurt more than help.

> but a simple, and usually innacurate, "how much longer you have" reding isn't
> something i'm interested in seeing.

Maybe you are not, but most people are. Most OS have this feature, even Linux has this feature, even KDE 3.5 has this feature, why not KDE 4.x? Removing it from KDE 4.x is a regression from KDE users' perspective.
Comment 16 Vincent Petry 2009-05-12 01:52:00 UTC
Yes, if that was in KDE 3, why not also provide the remaining time estimation feature in KDE 4 ? In KDE 3 there was even an estimation about how much time is left until the battery is fully recharged.

Thanks.
Comment 17 Aaron J. Seigo 2009-05-12 02:05:06 UTC
> if that was in KDE 3

because this is not kde3. just by being in kde3 does not make it a good idea (or a bad idea, for that matter).

now, i've given you my reasons and i'm not going to be baited into an argument over it. i've stated what could be acceptable (accurate predictions, ranges, elapsed times ..) and i've stated what isn't (predicitions that are inaccurate by design, ones that i've personally lost data over, btw)

options come at a cost in terms of code, maintenance and user interface and we have a policy in plasma of trying not to implement things we know can only be done half-properly.

i don't think there's anything more to be offered on this topic at this point (the last two comments were rehashes mixed at times with borderline flamebait), so let's leave it here for now.
Comment 18 Lamarque V. Souza 2009-05-12 02:53:47 UTC
Frustrating... the only thing I can think about this is frustrating...
Comment 19 Aaron J. Seigo 2009-05-12 03:01:34 UTC
*** Bug 192336 has been marked as a duplicate of this bug. ***
Comment 20 Médéric Boquien 2009-05-14 02:47:42 UTC
Apparently the remaining time information has already been added as an option for 4.3 so i think it is rather pointless to talk about whether or not this feature should be added now. :)
Comment 21 Sebastian Kügler 2009-06-12 13:13:08 UTC
*** Bug 182757 has been marked as a duplicate of this bug. ***
Comment 22 esigra 2009-11-04 21:48:22 UTC
After Gentoo just pulled KDE3 away from me due to it being abandoned upstream, I have just moved on to KDE 4.3.1 and am dealing with the regressions. I was going to report the regression that the battery monitor does no longer show an estimate of the remaining battery time. I used that feature a lot in good old KDE3 and miss it now. (There are several much worse regressions though.) I am aware that it is an estimate based on how I use the system right now, but when I plan to use it similarly, the estimate is really useful. But then I found the regression already reported and discussed here.
Comment 23 simply_bugz 2010-01-23 06:13:48 UTC
Ever since I moved from gnome I got frustrated by this. No info about my battery and no time estimate. I've even upgraded KDE4.4 RC1 and I see no sign of these features. I only experienced that now suspend on lid close and power cable and battery presence detection is broken.

In gnome I tested it and the time remaining reported by the applet was good beyond my believe. It said 1h10min left and in 70min my computer decided to suspend. At the time I was doing practice exam questions from pdfs on the screen. Can't remember the exact charge percentage.
While I could keep track using gnome power applet I learned the following,
The percentage tells me that: 
80% to 100% - close to fully charged - means 6 to 4 hours 
50% +/- 10% - about half way through 3 hours
15% - looks like it is running out but probably I can squeez out an hour or so
I understand that remaining time depends on the usage. On my netbook the power consumption can be from less than 6 Watts to over 12 Watts - a factor of two.

You can't keep arguing whether it is a good idea or not. It is obvious that good estimate is not always possible for various reasons. But please take a look at gnome-power-manager: it displays details reported by the battery driver and it stores its own statistics producing good estimates.

It is possible to log battery usage and created estimates of the real capacity, dependence of discharge time on the discharge rate, discharge time vs remaining capacity (might not be linear) and estimate accuracy of the measurements and so forth. The data reliability could increase as more data is collected.

The time remaining is important to me because it allows me plan ahead and decide whether I need to find a mains socket or I can make it if I dim the display a little. 

Today I notice that my battery % went down very quickly and I thought I forgot to charge the battery but it turns out that KDE didn't change the profile when i disconnected the cable, so fsb was If I had a time estimate on the panel and noticed that the time remaining is a bit low for the full battery and would have selected powersave mode. AND I PROBABLY WOULD HAVE WON AT LEAST AN EXTRA HOUR

Whatever some people say it doesn't mean they are wrong BUT is not user friendly to make people go into /proc/acpi and make calculations by hand or use other software such as powertop, while one could get the info is a human readable form in a couple of clicks on the panel.

AT THE VERY LEAST:
Assuming a system that reports correct info about the capacity and discharge rate (most modern systems) it is possible to estimate how long it will last at CURRENT USAGE and smooth out fluctuations with floating average, so that that quick operations like opening a window wont scary the user with sudden jump in numbers.

I would really appreciate if that issue would touch the heart of a developer because I love the KDE desktop but I feel like I have to go back gnome which has proven to me being a bit boring but more reliable and useful environment.
Comment 24 Tristan Miller 2010-08-23 01:01:24 UTC
Note that this bug report is about displaying the difference between the battery's current full capacity and the battery's original full capacity.  Those arguing about whether the applet should display the time remaining for the current charge should see Bug 204545.
Comment 25 Lamarque V. Souza 2011-02-06 00:45:22 UTC
*** Bug 82489 has been marked as a duplicate of this bug. ***
Comment 26 Viranch Mehta 2012-06-07 15:22:36 UTC
The detailed information about the battery hardware should go into KInfocenter. Reassigning bug to kinfocenter.
Comment 27 Christoph Feck 2013-12-29 19:09:22 UTC
*** Bug 324201 has been marked as a duplicate of this bug. ***
Comment 28 Mathieu Jobin 2021-01-10 11:23:53 UTC
we have this information now (Plasma 5.19)

I just wish we could copy/paste it