Battery life estimation never comes around

Marking as invalid for the same reasons as your previous bug:
»The new battery menu (which you should have if you are running Ubuntu Lucid or later) does not have tooltips / mouse over text anymore. Instead it has a menu item directly showing »Laptop battery X hours X minutes left«.

It does not need to estimate anymore, so I’m going to mark this bug as invalid.«

If it occurs nonetheless, you should either update your system or report this upstream to GNOME: https://wiki.ubuntu.com/Bugs/Upstream/GNOME

Ah sorry, this bug _is_ in fact related to the GNOME battery menu. Then you should really report it upstream. :)

According to the URL of this bug:
https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/629258
this bug is already associated with 'gnome power manager'
How can it be so, when you say I have to 'report it upstreams' (for the bug to be properly reported, I assume)
Does it mean nothing that it is apparently already associated with gnome power manager?

I have exact same problem. Time didn't estimated in lucid, but at least i had battery charge percentage. Now I totally confused about remaining battery charge.

There is no mouseover in Maverick beta for this, however the "menu" item when clicking on the battery effectively remains at "estimating...". The battery icon, however, seems to be visually accurate, showing a battery that empties overtime. This is on an updated 10.10 beta i386 install.

FWIW, I can't reproduce this on g-p-m 2.31.92-0ubuntu1 or 2.32.0-0ubuntu1.

I have the same problem on a Compaq Presario CQ60-307EA (Laptop). Running Ubuntu 10.10 BETA with latest packages. A lot of HP & Compaq's seem to be affected by this bug.

Just upgraded my HP G62-144DX to 10.10 today, and am having the same problem. It seems that most of our computers are unable to estimate time. I don't mind this, I can do my own estimations just fine, but the developers seem to think our computers can do this calculation therefore defaulting it.

@Mathieu, what system(s) ?

I've now noticed that when the power is removed a notification is displayed with an accurate % value (but still no tim estimate).

I'd ask anyone adding comments here to mention their affected system(s), please don't add "me too"-only comments.

applied all updates, removed charger and still estimating, no percentage or time.
system is compaq c700.

Architecture: amd64
DistroRelease: Ubuntu 10.10
EcryptfsInUse: Yes
GConfNonDefault:
 /apps/gnome-power-manager/backlight/idle_dim_ac=true
 /apps/gnome-power-manager/lock/blank_screen=false
 /apps/gnome-power-manager/lock/use_screensaver_settings=false
 /apps/gnome-power-manager/notify/sleep_failed_uri=
GnomeSessionIdleInhibited: No
GnomeSessionInhibitors: None
GnomeSessionSuspendInhibited: No
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Alpha amd64 (20100923)
MachineType: Acer Aspire 5740
Package: gnome-power-manager 2.32.0-0ubuntu1
PackageArchitecture: amd64
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-22-generic root=UUID=9f6960f1-acb7-4b3b-b8fe-a50a2479f02f ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=fr_CA.UTF-8
 SHELL=/bin/zsh
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4
Tags: maverick
Uname: Linux 2.6.35-22-generic x86_64
UserGroups: adm admin cdrom dialout libvirtd lpadmin plugdev sambashare
dmi.bios.date: 11/26/2009
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: V1.09
dmi.board.name: Aspire 5740
dmi.board.vendor: Acer
dmi.board.version: Rev
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: Rev
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvrV1.09:bd11/26/2009:svnAcer:pnAspire5740:pvrRev:rvnAcer:rnAspire5740:rvrRev:cvnAcer:ct10:cvrRev:
dmi.product.name: Aspire 5740
dmi.product.version: Rev
dmi.sys.vendor: Acer

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Just ran apport-collect for my system, where I do get the estimation to show up.

Architecture: amd64
DistroRelease: Ubuntu 10.10
GConfNonDefault:
 /apps/gnome-power-manager/lock/blank_screen=false
 /apps/gnome-power-manager/lock/use_screensaver_settings=false
 /apps/gnome-power-manager/notify/sleep_failed_uri=
 /apps/gnome-power-manager/ui/icon_policy=charge
GnomeSessionIdleInhibited: No
GnomeSessionInhibitors: None
GnomeSessionSuspendInhibited: No
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release Candidate amd64 (20100928)
MachineType: Hewlett-Packard HP Pavilion tx1000 Notebook PC
Package: gnome-power-manager 2.32.0-0ubuntu1
PackageArchitecture: amd64
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-22-generic root=UUID=e4334e0c-5bd9-4dbe-bfaa-04c47cc8925c ro quiet splash
ProcEnviron:
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4
Tags: maverick
Uname: Linux 2.6.35-22-generic x86_64
UserGroups: adm cdrom dialout dip fax floppy fuse plugdev tape video
dmi.bios.date: 04/18/2008
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: F.20
dmi.board.name: 30BF
dmi.board.vendor: Quanta
dmi.board.version: 69.2E
dmi.chassis.type: 10
dmi.chassis.vendor: Quanta
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnHewlett-Packard:bvrF.20:bd04/18/2008:svnHewlett-Packard:pnHPPaviliontx1000NotebookPC:pvrRev1:rvnQuanta:rn30BF:rvr69.2E:cvnQuanta:ct10:cvrN/A:
dmi.product.name: HP Pavilion tx1000 Notebook PC
dmi.product.version: Rev 1
dmi.sys.vendor: Hewlett-Packard

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Just submitted my apport-collect info from another HP system.

I will open a new bug for a mini 9 system I have which is also affected.

I've filed bug #654761 about this issue on the Dell Mini 9.

Same issue, Dell Studio 1458: Bug #635472

I've confirmed this also happens on one of my colleagues System 76 system. I'll ask him to open a separate bug.

The following has been added to the Maverick release notes:
When running on battery, clicking on the battery icon permanently says "Battery life (estimating...)". This affects some HP, Compaq, Dell and System76 systems (629258).

The issue has arisen because the percentage charge remaining figure has been removed from the menu, and the remaining time displayed now is only a rough estimate based on the current charge of the battery and the unreliable discharge rate.

In your case, the discharge rate is very wrong (0.0072 W), and upower has a heuristic to detect when the hardware isn't working (which is triggered in your case). In this case, the only measurement possible is the percentage charge remaining, which we don't display anymore.

The numbers indicated by your hardware currently suggest you have 6368 hours of charge remaining, which is clearly wrong.

I think that suggests removing the percentage ought to be reconsidered.

Battery life estimation is inherently unreliable.

Scott, I totally agree, and I'm sure this was mentioned during the session we had at UDS for the power indicator

same problem with laptop hp dv3500, always estamating. also battery state incorrectly when booted without ac, it thinks its is on ac. when plugin in and out ac , the state is correctly detected

The little secret is that Laptop battery - Details still shows the 'percentage' of your battery, so you can have a better guesstimate than the little red bar that sits at red for 20mins or so.

Pity that the functionality has devolved since 10.04, though - it's getting harder and harder to use the Ubuntu-certified laptop with each release.

I can confirm this happens on the Efika MX Smartbook (armel) too with the kernel from Genesi's gitorious repository. Our battery is SBS compliant and publishes all the same power supply attributes as a standard ACPI SBS battery. There is a custom driver in play (efikasb-battery) however this doesn't seem to be the root cause; we occasionally get kernel messages that certain sysfs attributes could not be read, and battery life never estimates properly and the battery is always reported as red, and empty (0%) in the icon.

Considering SBS batteries have accurate lifetime count which is published in sysfs (pulled right from the charger) I would have expected that this be used to determine the battery life in the first instance before any clever averaging and determination of power usage is performed, and the battery life and capacity (also reported in sysfs..) be used directly since the LiIon/LiPoly charger is pretty smart (hence, smart battery..) - I can read sysfs fine and tell that I have 4h50 of battery life left give or take a minute or two (291 minutes) and the average drain time is around 280 minutes.

Quite why gnome-power-monitor doesn't seem to take notice of this data is puzzling..

Same with HP Pavilion dv6648se.

Having this since Maverick Beta 1.
Dell Mini 9.

I, too, am affected by this bug - and the computer is neither HP, Compaq, Dell or System76 but a custom build obtained from CyberPower. Further information can be provided if needed.

@Vin, can you please submit a new bug report about your system, then link to it from here ? Thank you.

same symptom for me on Compaq Presario CQ60-216EF
(2.6.35-22-generic #34-Ubuntu SMP Sun Oct 10 09:26:05 UTC 2010 x86_64 GNU/Linux)

same bug on clevo w832t 2.6.35-22-generic #34-Ubuntu with latest updates.

also affect me!
The indicator don't work but in the battery window I can se the energy level.

2.6.35-22-generic #34-Ubuntu SMP Sun Oct 10 09:26:05 UTC 2010 x86_64 GNU/Linux
Ubuntu with the letest update (I've enabled maverick-updates and maverick-proposed)

(A questions...why only with hardy I can see the estimated discharging time?)

I can confirm this for HP Pavilion DV71060-ep.
Plus: when the battery is plugged, instead of one option on the menu, I have one for the battery, and one for the dc line. That means that I've got one line saying "Estimating" all the time, and when I'm charging the battery, I have 2.
Indeed, I never had the computer displaying the right remaining time, only the %. Also on Windows.
Can also confirm that the battery info on the detailed window is correct, including the %.

also affect me on a netbook Archos 10

Same problem with me on Hp Mini 210 and Maverick. No fix released or working for now.

The same problem on my ASUS EEE PC900 running maverick UNE.

Same problem here in Toshiba A200-1A0

@Devil999 unless you have the exact same symptom as described in comment #6 you have a different bug.

I too have the same problem in Ubuntu 10.10...

Laptop battery (estimating...) ... The percentage is not being shown...

This bug affects me too on toshiba l500-254 with ubuntu 10.10.

Same problem to me. HP notebook DV9930us and ubuntu maverick 10.10 64 bits. but I still see the remaining charge % at menu item-->power statistics-->Details...Not very accurate...:-(

Can you please stop messing with the status and adding random tasks

I have an HP DV6298US laptop. The laptop battery life estimation is completely broken. It say it has only 18% life and dies down in less than 20 minutes. Under Windows the same works for more than 1 and a half hour. Battery charging, discharging, current every single statistic is plain WRONG! It is impossible that charge remains at 100% for 10 minutes even when I pull out the power chord! In the new kernel 2.6.35-22 this is even more broken. The moment I plug out the charger, the charge level drops to 58%. Until then it is at 100%.

Ask me for ANY settings you want. I think developing Ubuntu to work with laptops has always been a challenge for developers. I have had issues with it since the days of Feisty Fawn. It will be ages before this is fixed.

The first thing is that on Ubuntu's website itself we cannot afford to have versions of Ubuntu only for Desktops, Servers and Netbooks alone. We need separate focus on Notebooks/Laptops. The Desktop features DO NOT work on Laptops. It is high time the Ubuntu team realizes that Laptops have special needs.

Balaji, if Ubuntu is getting wrong readings from your battery, you need to open a new bug report for that. This bug report only covers the problem where a battery life estimation isn't provided to the user on systems where power consumption data isn't provided by the hardware. The power manager needs to be programmed to produce its own estimate of the rate of charge/discharge, through periodic sampling of the total charge level, when the hardware doesn't report charge/discharge directly.

Also, there may be some laptops that can report this information, but where the Linux kernel doesn't know how to retrieve it.

I have the same problem on HP dv6-1308ew. I think the main reason of this problem is something more low-level than OS - hardware or BIOS, because it is also broken on Windows.

On my previous laptop (Acer), I got time estimation working well on both Linux and Windows. When I switched to HP, it doesn't work on neither. Both Windows and Ubuntu showed percent left only (9.10 at the time I switched, and later versions).

Also interesting fact is, that on Acer I had working electric current meter (/sys/class/power_supply/BAT0/current_now), but on HP there is always -1000.

I'm not sure if it is duty of BIOS to report the remaining battery time, but if it is, I suppose this bios doesn't support it. The bios is InsydeH20 EFI or something like that. On Acer I had Phoenix.

I have the same issue in Meerkat (2.6.35-22-server, x86_64).

Confirming that it worked (i.e. did not have the issue) in Lucid. Same computer. Same hardware. Same architecture (x86_64). Only change done was a 'clean install' from Lucid to Meerkat with all updates and upgrades that it asked for.

Also confirming that this bug remains no matter how long the laptop is ON. 4 hrs - 6 hours, may be more (i.e. it does not go away in 10 min as some threads suggest). Also this remains the same whether it is a clean startup (from power-down) or a wakeup from a suspended state.

Guys, pls. don't mark this (or similar bugs) as invalid. That will be the biggest disservice to the loyal users of Ubuntu Linux. I understand and respect that some of you guys (developers & testers) might not be able to see/reproduce the problem. That's OK. But pls. don't disrespect fellow users and community members by saying/marking them as invalid. (I saw in some threads, that's why I persistently request).

Snapshot attached. Tell me anything more you need. I will provide to the best I can.
#uname -a -> Linux 2.6.35-22-server #35-Ubuntu SMP Sat Oct 16 22:02:33 UTC 2010 x86_64 GNU/Linux
gnome-power-manager version -> Version: 2.32.0-0ubuntu1

Hello

running a laptop sold by a south african company called Sahara, built with Intel hardware as per lspci, this system came with Ubuntu pre-loaded with 8.04:

00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.3 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
00:1f.6 Signal processing controller: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem (rev 03)
01:00.0 Network controller: Intel Corporation WiFi Link 5100
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)

This is the first time I have encountered this issue - whereby the icon, the left-click menu and the details do NOT seem to reflect the various charge states - for example, everything EXCEPT the charge history shows a battery discharging and at almost 0 % charge. HOWEVER the charge history is correct in showing a gradual increase in charge, from zero to 20% which is correct as the ac power supply is plugged in and has been for the last 30 minutes or so. Incidentally when left-clicking the battery icon I see that it is merely "estimating" and it will continue to do so ad infinitum. This only started happening around midweek last week.

I am running 10.10 32-bit Ubuntu with all updates. as of 24 10 10

Please indicate any information I can accquire to attempt to sove this issue.

Gray

Hello

Just to add to my above comment:

When I remove the ac power cable, for a split second, the battery icon shows fully charged (which should be about correct now) and then reverts to showing now charged (and drawn in red outline) as before.

Gray

Yes, it's right. This problem exists and many people (myself included) can confirm it.

But there are here a few descriptions of distinct problems.
I think that the problem that was reported here does NOT have anything to do with any physical incapacity to check the battery level.
The problem is that when one clicks in the gnome-power-manager icon the tool tip says simply "Laptop battery (estimating...)". But after clicking in "Laptop battery" a window appears with several information regarding the battery. There, it is possible to see the correct level of the battery.

So, I think that any problem where the gnome-power-manager is not able to check the battery level at all is not the same bug.
Please correct me if I'm wrong.

@João Gomes: you are absolutely right. ;) This is a bug about the forever estimating state of battery applet indicator. As far as I am concerned, even the icon represents the correct state of the battery charge (e. g. gets 'emptier' when battery discharges), only the text when I click on it does not show the level of charge and states "estimating" permanently.

João, I have the same situation you describe on my Dell Mini 9. So in my opinion, there are currently two issues:

* g-p-m has no estimates about the remaining battery *time*. This seems to be because of lacking ACPI information, if I understood it correctly. This could be solved by calculating these estimates in g-p-m, but this is probably not trivial.
* The second issue is how the battery indicator deals with this situation. Currently, it simply shows “estimating…” forever, but never comes around with estimated values. I think if it cannot get the remaining battery *time*, it should resort to displaying the battery *charge* (percentage). This is probably much easier to implement and would give at least any usable value, instead of the useless “estimating…”. And, if I recall correctly, this was the behavior in Lucid.

So if it is not possible to resolve the issue of getting the time estimates in the short term, I’d suggest to resort to the values that *are* available (as the charge percentage).

Hello

OK I tried something hardware related

I was considering a new install of Ubuntu, using the 64-bit edition, so booted off the live CD and noticed the same red outline of the battery indicator as on the hard drive install...

...sooo I turned off the laptop and pulled the battery out, then shoved it back in and restarted.

The power indicator now seems to behave normally ! The time to charged is now slowly getting less and the details are now showing correctly - I will monitor the situation for the next few days, but thus far the issue seems to have been solved, tho I don't know if the issue was caused by a simple bad connection with the battery / motherboard interface or if there is some other "switch" which has been reset ?

The laptop is just over a year old - the battery seems to still be a tight fit into it's compartment and there was definite solid click when I re-inserted it.

Is it is possible that a kernel update somehow flicked a "switch" to cause the issue ?

@Darius Kulikauskas: exactly! It happens the same with me. The icon gets emptier as the time goes by. Only the text is not able to show the percentage left.
But the gnome-power-manager has the correct information, because if I click on "Laptop battery" I can see the correct percentage in the window that is showed.

@Frederik Elwert: I don't know if this is correct but I think the recent versions of gnome-power-manager receives that information from upower.
Yes, I agree with you. If the gnome-power-manager already has the percentage left, it should be simple to show it.
But I don't know, I'm not an expert.

I also have Debian in the same machine and I don't have this problem. However, it is using gnome-power-manger 2.30, while ubuntu is using version 2.32.

I believe gnome-power-manager hasn't been able to provide a time estimate since the rewrite for upower if your battery does not supply a charge/discharge rate in /sys/class/power_supply/BAT*/current_now. My battery always shows a 0 there, so I suffer from this problem.

Before upower, it used to make a projection based on measurements of the charge level over time. That would take some work to re-implement.

The behavior of saying 'estimating' instead of supplying a percentage is specific to the indicator applet code (the notification area icon doesn't behave that way), and it's pretty easy to fix.

In fact, I just fixed it in this PPA: https://launchpad.net/~brian-rogers/+archive/power

Yes, you're right. I'll try your fix.
Thank you!!!

@Brian Rogers : I tried your solution and works perfectly, but don't not resolve all the problem... Because it solved the indicator applet, but still without estimate the time of discharge of the battery.

I had this problem too (Maverick on Acer TM380) and using the PPA from Brian Rogers made my battery percentage reappears. Thank you!

@Brian Rogers maybe its time to move your fix in upstream? ;)

@Brian : Your fix works perfectly on an HP Pavilion tx2000 and restores the previous behaviour seen in Lucid (percentage remaining) Thank you so much!

Brian, you are amazing!

I've been through some early and difficult linux installs, many flavors, a few savers.

Ubuntu has really been getting the hardware.

This is the deal changer for me and the growing amount of people I convince to leave ms while they clutch at it with insecurity.

This first piece of hardware that's not recognized is either the deal breaker or the many hour challenge for the tech.

Your power percentage is a sweet swirl of frosting on the cake. They will eat cake too ;-)

I added your repository to the sources in synaptic, reloaded, then marked install for the generic kernal header and update for the (replacement) gnome-power-manager from you and whalla!

A working percentage display when clicking on the battery icon.

P.S. This worked on a Sony Vaio VGN-N365E

also occurs on Thinkpad T500 (dist: maverick)

Bug #439783 since Karmic describes this problem. I still consider this bug as specific to Maverick though.

Also affects my System76 Pangolin (panp7). dmidecode attached.

How do I add PPA: https://launchpad.net/~brian-rogers/+archive/power ???

@Brian thank you for your contribution. Seeing the % left for charging or discharging is more useful, however it's not a fix for the bug reported here. It also highlight this bug was initially the indicator applet not knowing how to deal with the time values not being there, not sure where to assign this now.

I am attaching a screenshot taken after applying Brian's PPA update, still showing "time to full" and "time to empty" as 0.

Steps to apply @Brian's PPA update:
1) From a terminal window:
sudo add-apt-repository ppa:brian-rogers/power
sudo apt-get update
sudo apt-get upgrade
2) Reboot
3) Login normally, click on the battery icon

I know it is a maverick bug but it is working for lucid.

Running lucid with a kernel version:

Linux mai 2.6.35-02063505-generic #201009211107 SMP Tue Sep 21 11:09:35 UTC 2010 x86_64 GNU/Linux

Hey Guys

I don't know whether gpm continually showing "estimating" when upower is giving it null information is a *bug* or not, but the fundamental problem is a bug in upower, not a bug in gpm.

upower-0.9.5 incorrectly gives null battery runtime information when it can't get a electrical current reading from the hardware. There is code in upower-0.9.5 to guess the battery runtime information in the absence of a current reading, but that code is broken. Hence gpm is continually reporting "estimating", waiting for a upower runtime estimate that it will never receive.

I've patched the upower code, albeit in a fairly ugly way. I don't have time to neaten this up - somebody can fix it upstream if they choose, or perhaps neaten it up for an ubuntu-specific patch.

The patched upower code enables upower to estimate the battery runtime, in the absence of a current reading. It takes a few minutes for the battery charge state to move enough that an estimate can take place. On my HP Mini 210 netbook, with this version of upower, gpm now estimates the battery runtime and battery charge time, to within ballpark-correct periods.

Anyway, a .deb of the hacked upower can be found at:

https://sites.google.com/site/andyeyre/files/upower_0.9.5-4eyre1_i386.deb?attredirects=0&d=1

Tarball of source and diffs:

https://sites.google.com/site/andyeyre/files/upower_0.9.5-4eyre1-source.tgz?attredirects=0&d=1

Checksums:
bb27c7d58a4f6e69f48b331876de981b upower_0.9.5-4eyre1_i386.deb
3ade6e99b525f037ce5499a5dd58d1d6 upower_0.9.5-4eyre1-source.tgz

ps, I should note that the fundamental patchfile can be found in upower-0.9.5/debian/patches/998_meterfix_eyre.patch when that tarball is completely unpacked.

I tried Andy's patched upower, but I still can't see any battery time in gpm on my acer TM382, even after waiting some ten minutes or so.
Am I doing someting wrong, or missing something? Here's what I did:

1. remove current version of upower: sudo apt-get remove upower
2. install patched upower: sudo gdebi upower_0.9.5-4eyre1_i386.deb
3. reinstall packages dependant on upower that were uninstalled in step 1.: sudo apt-get install gdm gdm-guest-session gnome-power-manager gnome-session gnome-session-bin
4. reboot

Please let me know if I have to do something else. I would be happy to have this bug fixed.
Thank you

angus73: if you click on the battery icon, and then click on "estimating", gnome-power-statistics should load. Can you paste in here what you see on that first page please, when the battery is discharging, and has been so for 10-15mins or more.

ps. you don't need to remove the existing upower to install the patched version, it counts as a later version, so you can just upgrade to it directly. Saves messing about with the dependencies.

Andy, I see that compiling upower produces multiple deb packages, though you only attached one of them. Considering the report of it not working, perhaps the change actually winds up in the libupower package?

Regardless, for everyone's convenience I put your patch in my PPA. That way it's easier to install, and amd64 is provided. I also tested it, and it's working for me, though the estimate fluctuates quite a bit.

Anyone who wants to try it can add ppa:brian-rogers/power to their software sources if they haven't already, and then update their system.

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

Confirmed fix on an HP DV6-2170US. Added Brian Rogers' repo and the estimating is gone and an actual percentage is displayed. Also, the erroneous battery indications (red battery icon on a fully charged battery) have subsided. I'll continue to monitor and report back.

Thank you for your help. I attach the screenshot of gpm stats after 20minutes of battery descharging. I don't know exactly how to provide a "debug version of upower", but if you give me a hint I will try to do it.
Thank you
Angus

I downloaded the .deb of the upower patch and it works, even as far as displaying the time remaining on the battery status indicator. However, I have noticed since applying the upower patch a bug has cropped up, where by if my laptop has been on AC power for a while and is then unplugged, a warning message immediately pops up saying battery level is critically low and my laptop is about to hibernate, even though the battery level is 99% and has just started discharging.

After a few seconds my laptop then hibernates regardless if I plug in the AC adapter again.

I was previously using the patched gnome-power-manager from Brian, but the bug report has changed to being a problem with upower, so I have since gone back to the official gnome-power-manager package, do I still need the modified gnome-power-manager package installed too?

You don't need my gnome-power-manager package with the upower patch. All my package does is make the indicator menu show the battery percentage instead of 'unknown' when a time estimate isn't available. It can be combined with the patched upower without causing any problems, though. In fact, my PPA has the upower patch as well now, so you'll get both patches if you update from my PPA.

The advantage of having both is that for a short time after plugging in or unplugging, before there is an estimate, you'll at least see the charge percentage in the indicator menu.

That gnome-power-manager doesn't display a percentage in this case is a separate issue. Please discuss that one at bug #539912

Thanks for looking at this, Andy. I suggest you send your patch upstream, at http://bugs.freedesktop.org/show_bug.cgi?id=24329

I have this "Laptop battery (estimating..)" on battery left click.
Doesn't change -
Compaq Presario A900 (bios f.33)

whilst on battery
cat /sys/class/power_supply/BAT0/current_now
0
cat /proc/acpi/battery/BAT0/state
present: yes
capacity state: ok
charging state: discharging
present rate: 0 mW
remaining capacity: 3422 mWh
present voltage: 10800 mV

So same situation where no current rate is given.
But graphic bat OK and % reading in power stats details tab.
I haven't tried ppa:brian-rogers/power yet but thanks to Andy Eyre and Brian Rogers for the option.
As it is a client machine and non crucial bug I am reluctant to modify from vanilla much.

Just updated again from Brian's PPA but I still only see a percentage in the battery indicator.

Same issue in Compaq Mini CQ-10

Nice work guys... that PPA is working as expected!

Paul, I'm not sure I'm happy with this being a duplicate of bug #629257. That bug report is about indicator-power having a broken fallback. That upower isn't giving it the information is a separate issue to me. (In addition, this one has a nice patch that needs review :b)

I could be missing something, of course. May you please clarify why you merged these? :)

I have just come across this problem again with another machine (my previous post #107 was concerning a Compaq Presario A900 (bios f.33) )

This time it is with an HP Pavilion dv8000.
again whilst on battery:-
cat /sys/class/power_supply/BAT1/current_now
0
so no drain info available so this time I installed Andy Eyre's libupower-glib1 and upower from Brian Rogers hand ppa and the system now has working estimates of discharge and charge.

Thanks Andy and Brian.

My HP G62-121EE laptop has libupower-glib1 and upower installed but it shows
just "laptop battery (estimating)..." :-( But if I click the menu, the power
statistics shows correct values for the Energy, charge, battery capacity,
etc. Probably the developers could introduce a daemon which monitors the
battery charge during discharge, compare the value with battery capacity,
and compute the estimated time remaining from the 2nd minute, every minute
:-) This would be a machine/driver independent code and also be intelligent
enough to show correct statistics, even if the user changes his
power-management schemes.
An important note, though, is to have a timer ticking (restart the timer
after *suspend*-resume/ *sleep-*resume/ power-on) for the daemon itself,
instead of using system clock. This is necessary, else the computation would
be wrong if a user resumes the session after a sleep or hibernate. Worse
still, it would be inaccurate if the user has changed the battery after a
hibernate!

On Mon, Nov 29, 2010 at 10:33 PM, Philip Guyton
<email address hidden>wrote:

> I have just come across this problem again with another machine (my
> previous post #107 was concerning a Compaq Presario A900 (bios f.33) )
>
> This time it is with an HP Pavilion dv8000.
> again whilst on battery:-
> cat /sys/class/power_supply/BAT1/current_now
> 0
> so no drain info available so this time I installed Andy Eyre's
> libupower-glib1 and upower from Brian Rogers hand ppa and the system now has
> working estimates of discharge and charge.
>
> Thanks Andy and Brian.
>
> --
> Battery life estimation never comes around
> https://bugs.launchpad.net/bugs/629258
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
--Sriram
<sriramoman_at_gmail_dot_com>

I think one problem is that the kernel does not propagate the discharge information to the /sys architecture. If I look at /proc/acpi/battery/BAT0/state
I can read
present: yes
capacity state: ok
charging state: charging
present rate: 26018 mW
remaining capacity: 3800 mWh
present voltage: 10637 mV

But the rate is nowhere to be found in /sys/class/power_supply/BAT0/ and it would appear that the battery applet is looking there now.

This is a Thinkpad T41 I am using, by the way.

The sysfs equivalent of 'present rate' is current_now. Do you have a current_now file in /sys/class/power_supply/BAT0/ ? If so, does it contain an actual reading, or just always report zero?

I have a lenovo 3000 N200 running ubuntu 10.04 with kernel 2.6.35-02063504-generic.

/sys/class/power_supply/BAT1/current_now always contains 0

/proc/acpi/battery/BAT1/state contains:
present: yes
capacity state: ok
charging state: charged
present rate: 0 mA
remaining capacity: 5100 mAh
present voltage: 11100 mV

Does this mean the kernel doesn't get the right battery value?

I have no

/sys/class/power_supply/BAT1/current_now

/proc/acpi/battery/BAT0/state
present: yes
capacity state: ok
charging state: charged
present rate: 0 mW
remaining capacity: 53560 mWh
present voltage: 12566 mV

uname -a
Linux T61 2.6.37-9-generic #23-Ubuntu SMP Wed Dec 15 21:08:36 UTC 2010 x86_64 GNU/Linux

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu natty (development branch)
Release: 11.04
Codename: natty

For some people the battery is BAT0, and for others it's BAT1. I'm not sure why. Be sure to check both paths for a current_now file, because one of those paths won't even exist. As far as I know, current_now will always be there if the battery directory is there.

No, there is no current_now. Sorry, I should have mentioned that I am using natty currently and thus am in the wrong place to report the bug. Anyway, I get

ls /sys/class/power_supply/BAT0/
alarm energy_full_design power status uevent
cycle_count energy_now power_now subsystem voltage_min_design
device manufacturer present technology voltage_now
energy_full model_name serial_number type

So there is "power_now" and "energy_now", and "power_now" seems to carry the right values. If I take a look at the strings in /usr/lib/upower/upowerd however, it would rather appear that upowerd is instead looking for "charge_now".

So it would seem that we have a discrepancy between the kernel file name, and what upowerd is looking for.

I have no idea what the discrepancy (if any) in Maverick would be.

Looks like I am going to patch the upowerd binary as a first measure.

This bug affects also me. I am on Maverick and I have /sys/class/power_supply/BAT0/current_now. Its value is: -1000.

Brian: I am using the patched upower and friends from your PPA, and I have a regression: the estimated time is frequently calculated incorrectly, due to an incorrect calculation of the current. For example, in typing this comment, I watched as three notifications went by, all saying "laptop battery low" and reporting the battery at 5%, but in order, they reported estimated remaining times at 0:12, 0:06, and now 0:20. My power usage has not changed significantly during this period. I believe this is due to a sampling error, though I haven't looked at the patch so I can't say how often it really occurs or exactly how to fix it. In most cases it is fine though, so thank you for the work, but I think it needs further review and testing before it is merged into mainline. Furthermore, Intel's powertop gets the current correctly 100% of the time, maybe it is worth looking in to how they calculate it.

Also, I can say for certain that my device used to properly report current_now, in fact, I had scripts that used this value before and they worked perfectly. I wish I could say with certainty when this regression occurred, I expect it was due to a kernel update. I know it worked some time after I upgraded to maverick, but before I started using the 2.6.36 kernel from kernel-mainline (because that was supposed to fix the extra load balancing ticks, which it didn't really do, sadly). I don't expect that this is the issue though, since so many others see this bug that are probably not using the 36 kernel. I hope to do more investigation in the future.

Yeah, it's fairly inaccurate because upower samples the battery only every 30 seconds, and many batteries only report charge level in increments of a whole percent. So the estimator doesn't have precise data for the charge level when it takes a reading, and when it sees a change, all it knows is that that happened some time in the last 30 seconds.

With the version in my PPA, the estimates are projections from alternating readings of "the battery discharged 1% in 30 seconds" and "the battery discharged 1% in 60 seconds" or something similar to that. I've done some experiments on my laptop with code that enforces a minimum time interval and discharge amount before producing an estimate, and it helps, but the estimates still fluctuate a bit.

I'd like to at least have a moving average estimate of the current (and therefore time remaining) before submitting my patch. Or ideally, use all that nice charge and discharge profile data that upower collects.

Oh, and you probably did lose current_now because of 2.6.36. It comes directly from the kernel, so not many other components have a chance to make it go away. Battery hardware varies, so it's easy to have a battery bug only affect specific laptops. I'd recommend testing a mainline 2.6.35 kernel (to see if it's an Ubuntu patch that provides current_now), then bisecting to find the commit that made it go away. If/when you do find a bad commit, you should file a new bug.

My own battery has never reported current_now. Some batteries just don't report that data in a way that linux knows how to get it, and probably some aren't even capable of reporting that data.

Thanks everyone for your help.

The PPA fixed the issue on my HP DV9616CA.

Someone else confirmed this earlier.

I'm noticing this on my System76 Lemur Ultrathin.

Testing with this, I have some results to report:

On System76 PanP7, we're seeing that the battery status stays at "Estimating..." indefinitely. The Icon correctly reflects the current charge percentage. Applying the PPA fix allows us to see the percentage in the state, but there is still never a time estimate. We're seeing the exact same issue on the SerP6 and the LemU2. I initially got a reading for 5:05 for the Serval (Which is far too long), then it went away to be replaced with estimating. Applying the fix on both computers allows the indicator to display the battery percentage, but not the time remaining. We've also seen this on our Star3 and Star4 models, so this is an across the board issue. On all systems, in the battery data window, the "Time to Empty" is "0 seconds" and "Time to Full" is "0 seconds".

Marking as invalid for the paper cuts project since this appears to be a hardware related issue that is not present on every default installation of Ubuntu.

Sorry but I think marking it as "invalid" is completely wrong... I use
Ubuntu in my laptop since 8.04 and I never had this problem. Suddenly, after
upgrading Ubuntu version, it appears and you say it's a hardware problem?
You could say it's a kernel stuff but never a hardware stuff...

I'm going to test another distro on my laptop and I'll post the results
here.

Rodrigo: please read Chris' reply in comment #128 careful. This bug is still very much Confirmed and valid, but because it will likely take one person more than one working day to it is not eligible for One Hundred Papercuts. See the following for more information about the remit of the papercuts project:

   https://wiki.ubuntu.com/PaperCut#How%20can%20I%20tell%20if%20a%20bug%20is%20easy%20to%20fix?

This bug seems still present in natty (alpha1), on a dell mini9.

This affects me too, on an HP HDX16t laptop.

I tried the PPA version of upower given above with no result. Strangely, looking at upower's dbus interface in d-feet shows that it knows my energy_rate (discharge rate) and the amount of energy in my battery, but doesn't calculate time_until_full or time_until_empty.

It reads these from charge_now, not current_now. My current_now is -1000, but I don't see how that could be causing the bug.

I'll fire up gdb and have a look at upower if I can. I've never debugged anything but C# and Python before, so it will be interesting...

I have this problem on my HP Pavilion DV9812NR running 10.10 with all updates.

Percentage shows up in power statistics, but the power indicator context menu always says estimating. I never had an estimated time since I got this laptop over a year ago (Time to full/empty is always 0 seconds). If I remember correctly I did have a percentage in the context menu in Lucid and definitely in Karmic.

I tried Brian's fix and after rebooting the context menu is showing percentage again. An estimated time would be a nice bonus, but as far as I'm concerned percentage is all I need to know.

For the record I experienced this but in lubuntu 10.10 on a dell mini 9 and the provided patched upower .deb resolved the issue.

Install Battery status:
type in terminal:
sudo add-apt-repository ppa:iaz/battery-status && sudo apt-get update
sudo apt-get install battery-status

once installed click on Alt+F2 and type:
/usr/lib/battery-status/battery-status --indicator

Amr's fix from the PPA does not work for me. Battery indicator still always says "estimating..." when on battery power.

rfugger, you can check this link out.
I applied everything written there on my HP dv4 pavillion and now the battery is showing me a percentage when charging and discharging
http://www.webupd8.org/2010/11/battery-status-ppa-finally-updated-with.html
Try again and let me know because I'm still trying to find more solutions for this bug

> Amr's fix from the PPA does not work for me. Battery indicator still
> always says "estimating..." when on battery power.

Yes, Amr appears to be suggesting a workaround; to install a different piece
of software (battery-status) and use that.

Please try to limit this discussion to the issue at hand, which is strictly
upower and the stock power indicator (gnome-power-manager) failing to
provide an estimate.

I'm curious that upower has been marked fix released :)
Is that accurate? The reason I'm confused is the upstream bug report
(Launchpad still calls upstream devicekit-power) appears to be open with
little activity. Was battery-status getting the missing information from
upower on one of the offending batteries?

If thats the case then ya you're right the fix for this particular bug is not yet available, but the work around mentioned works fine.

Ok, the workaround is better, but still does not give a time estimate,
only a percentage estimate, and the icon doesn't obey the visibility
set in power management preferences.

Hello Amr,

How is the patch coming along? Have you cleaned it up and posted it upstream? Is there a corresponding upstream bug report other than the Device-Power? ... which seems to be inactive currently. I'd be great to get a definitive fix upstream so that the released packages can start being patched.

Thanks for your work!

Confirming bug presence on HP G60-468ca using natty alpha 3 with daily updates and unity 3d... amd64 release

this seemed to have broke during the transition from devicekit-power to upower; and looking in gnome-power-statistics confirms that it's not collecting samples for the data it uses to generate the estimate; as upower doesn't provide it for my battery (i don't know for sure if it offers it at all on other batteries, though) where devicekit-power provided _something_

https://bugs.freedesktop.org/show_bug.cgi?id=24329#c2

this here in particular, my battery:

  battery
    present: yes
    rechargeable: yes
    state: charging
    energy: 21.492 Wh
    energy-empty: 0 Wh
    energy-full: 43.1784 Wh
    energy-full-design: 47.52 Wh
    energy-rate: 0 W
    voltage: 11.577 V
    percentage: 49.7749%
    capacity: 90.8636%
    technology: lithium-ion

and as my comment above, it was apparently from hal, not between dk-p and up

Bug still there in natty beta 2 (updated from beta 1) HP dv6745

eeepc 900 natty beta2 too ...:(((

Bug is still alive and kicking. My HP g60 125nr does this and it drives me nuts. If we can get a discharge rate (Wh/time) isn't it just simple arithmetic to get at least a half-decent fallback routine should the current implementation fail/time out? I've had the stock battery replaced via BestBuy, and unsurprisingly it's a cheap Taiwanese knock-off. I can check if the stock battery (as in genuine HP) can give an estimate of remaining charge (it could be HP's hardware level vendor locking, similar to ink cartridges), but I still see no reason for not having a history based estimation as a failsafe.

This seems a little crazy, my Tosh NB200 battery estimation worked fine until an upgrade, can't remember now if it was 9.10 to 10.04 or 10.04 to 10.10. Anyway, the on screen pop-ups with the % remaining are fine, it's just the panel monitor that doesn't display a time. I installed batmon today as a test, it's graphically very poor, but at least it reports a percentage, it too cannot report an estimated time. Can an option for percentage or time be added to the indicator applet until this is resolved?

Bug still alive, on a natty fresh install :(

I'm a Linux Geek and IT Tech of 10 years and I just installed Natty yesterday on a HP Pavilion dv6 and YES guys we have a BUG here so please let's get a fix for this...

THANKS

the same problem in HP-Mini-210-1000

ubuntu 11.04 clean install

battery:
    dispositive: battery_BAT0
    productor: Hewlett-Packard
    model: Primary
    present: yes
    rechargeable: yes
    state: charging
    energy: 11.4 Wh
    energy-empty: 0 Wh
    energy-full: 24.9 Wh
    energy-full-design: 27.5 Wh
    energy-rate: 0 W
    voltage: 10.9 V
    percentage: 45.8.7749%
    capacity: 90.4%
    technology: lithium-ion

The bug is known upstream, we just need somebody to re-enable the needed code. Please stop commenting, there's no point in giving any additional information: you can only help by actually doing the work yourself...

I think what Milan is saying, is the proper way to say "me too" is to select "Affects Me" at the top of the bug, which will help to give developers an accurate scope of impact _ though this one is pretty high already. I posted upstream (freedesktop-bugs link at the top) where IMHO the bug needs a new title and some more activity. I noted the last dev comment was to look at turning on the time estimation code in October 2009 .. I'm guessing that presented a challenge.

I'm having the same issue. Today I found at http://www.omgubuntu.co.uk/2011/02/battery-applet-status-ubuntu/ an applet which can estimate the battery percentage.

the battery-status applet emulates the indicator status.. it isn't one...
try using expo trough unity and look at the tray area with and without
"indicators".. you'll see what I mean. It's layered in .. not actually
integrated into the bar.

On Sun, Jun 5, 2011 at 10:19 AM, Airam RR <email address hidden> wrote:

> I'm having the same issue. Today I found at
> http://www.omgubuntu.co.uk/2011/02/battery-applet-status-ubuntu/ an
> applet which can estimate the battery percentage.
>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (758441).
> https://bugs.launchpad.net/bugs/629258
>
> Title:
> Battery life estimation never comes around
>
> Status in DeviceKit based power management D-Bus backend:
> In Progress
> Status in Gnome Powermanager:
> Invalid
> Status in One Hundred Paper Cuts:
> Invalid
> Status in NULL Project:
> Invalid
> Status in System76:
> Confirmed
> Status in Release Notes for Ubuntu:
> Fix Released
> Status in Upower:
> New
> Status in “upower” package in Ubuntu:
> Triaged
> Status in “upower” source package in Maverick:
> Triaged
>
> Bug description:
> Binary package hint: gnome-power-manager
>
> When running on battery, the mouse over text for the battery icon (when
> running on battery) permanently says "Battery life (estimating...)". An
> estimate never shows up.
> Computer: HP Envy 14
>
> ProblemType: Bug
> DistroRelease: Ubuntu 10.10
> Package: gnome-power-manager 2.31.90-0ubuntu5
> ProcVersionSignature: Ubuntu 2.6.35-19.28-generic-pae 2.6.35.3
> Uname: Linux 2.6.35-19-generic-pae i686
> NonfreeKernelModules: wl
> Architecture: i386
> Date: Fri Sep 3 06:38:47 2010
> ExecutablePath: /usr/bin/gnome-power-manager
> GConfNonDefault:
> /apps/gnome-power-manager/lock/blank_screen=false
> /apps/gnome-power-manager/lock/use_screensaver_settings=false
> /apps/gnome-power-manager/notify/sleep_failed_uri=
> /apps/gnome-power-manager/ui/icon_policy=charge
> GnomeSessionIdleInhibited: No
> GnomeSessionInhibitors: None
> GnomeSessionSuspendInhibited: No
> InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Beta i386
> (20100901.1)
> MachineType: Hewlett-Packard HP ENVY 14 Notebook PC
> ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-19-generic-pae
> root=UUID=76ae939d-2ce2-466e-88d5-98b11aad6098 ro quiet splash
> ProcEnviron:
> LANG=en_DK.UTF-8
> SHELL=/bin/bash
> SourcePackage: gnome-power-manager
> dmi.bios.date: 07/21/2010
> dmi.bios.vendor: Hewlett-Packard
> dmi.bios.version: F.12
> dmi.board.asset.tag: Base Board Asset Tag
> dmi.board.name: 1436
> dmi.board.vendor: Hewlett-Packard
> dmi.board.version: 59.20
> dmi.chassis.asset.tag: CNU0274F2B
> dmi.chassis.type: 10
> dmi.chassis.vendor: Hewlett-Packard
> dmi.chassis.version: Chassis Version
> dmi.modalias:
> dmi:bvnHewlett-Packard:bvrF.12:bd07/21/2010:svnHewlett-Packard:pnHPENVY14NotebookPC:pvr0492100000241910000620000:rvnHewlett-Packard:rn1436:rvr59.20:cvnHewlett-Packard:ct10:cvrChassisVersion:
> dmi.product.name: HP ENVY 14 Notebook PC
> dmi.product.version: 0492100000241910000620000
> dmi.sys.vendor: Hewlett-Packard
>
> See also bug #629257 (one lower) for previous ...

This bug is still prevalent in System76 netbooks with Ubuntu 11.04 installed.

This bug is still present in Natty. Sorry, I can't get LauchPad to add natty/upower as a new target for this bug - maybe somebody more au fait with launchpad can do that.

I have, however, examined & tested my earlier patch (for upower on 10.10) against upower-0.9.9 that ships with Natty, and it checks out and works fine.

Hence, I attach a .deb with the i386 binary of my patched upower, plus the source.

If somebody wants to also compile for amd64 architecture and add to their PPA (like they did with the earlier patch) to aid distribution, then I'd be thankful - I don't have time for this.

I also see a lot of comments about upstream patches and the need to re-enable the disabled code - this patch does exactly that - fixes the broken estimation code and re-enables it. I don't have time to do it myself, but if somebody wants to commit my patch back up to the ubuntu upower project, then this bug would be fixed for everybody.

Can you attach a real patch file or debdiff?

Yes. Attached.

Thanks Andy ! I applied you patch and it's work.

Just a little bug. The informations are shown twice (see the attachment / capture). Any idea ?

Hi Mohegan.

I too saw the double reporting of battery status, when I first installed 11.04. However, I saw it *before* I'd installed the patched upower, so I don't think it's related to that (unless you tell me that you only had one line *until* you installed the patch).

The thing is, the patch affects upower and the data that it reports -- but the icon belongs to gnome-power-manager, which reads the upower data and draws the graphs and things -- and is nothing to do with upower per se. Unless you can definitely identify the behaviour as coming from the patched upower, I'd be tempted to file a new bug under gnome-power-manager.

If it's any help, the double reporting seemed to go away for me as soon as I installed all the latest package updates, though as I said, that was before I'd installed the upower patch.

andy

> I too saw the double reporting of battery status, when I first installed
> 11.04. However, I saw it *before* I'd installed the patched upower
>

I confirm this behavior. Seems that it has nothing to do with proposed
patch.

@Mohegan, Andy

The double reporting of battery status was already present before that.
It happens when the system resume from suspending, i opened a bug
about that, bug #764055

--
Sergio Zanchetta
https://launchpad.net/~primes2h

A VERY GOOD alternative for now, for me that is, is to use the
battery-status applet as indicator to get a proper read on what's going on
with my battery and on my cpu governor status...

maybe we could just merge that as a replacement?

On Sun, Jun 26, 2011 at 6:51 PM, Sergio Zanchetta <email address hidden>wrote:

> @Mohegan, Andy
>
> The double reporting of battery status was already present before that.
> It happens when the system resume from suspending, i opened a bug
> about that, bug #764055
>
> --
> Sergio Zanchetta
> https://launchpad.net/~primes2h
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (758441).
> https://bugs.launchpad.net/bugs/629258
>
> Title:
> Battery life estimation never comes around
>
> Status in DeviceKit based power management D-Bus backend:
> In Progress
> Status in Gnome Powermanager:
> Invalid
> Status in One Hundred Paper Cuts:
> Invalid
> Status in NULL Project:
> Invalid
> Status in System76:
> Confirmed
> Status in Release Notes for Ubuntu:
> Fix Released
> Status in Upower:
> New
> Status in “upower” package in Ubuntu:
> Triaged
> Status in “upower” source package in Maverick:
> Triaged
>
> Bug description:
> Binary package hint: gnome-power-manager
>
> When running on battery, the mouse over text for the battery icon (when
> running on battery) permanently says "Battery life (estimating...)". An
> estimate never shows up.
> Computer: HP Envy 14
>
> ProblemType: Bug
> DistroRelease: Ubuntu 10.10
> Package: gnome-power-manager 2.31.90-0ubuntu5
> ProcVersionSignature: Ubuntu 2.6.35-19.28-generic-pae 2.6.35.3
> Uname: Linux 2.6.35-19-generic-pae i686
> NonfreeKernelModules: wl
> Architecture: i386
> Date: Fri Sep 3 06:38:47 2010
> ExecutablePath: /usr/bin/gnome-power-manager
> GConfNonDefault:
> /apps/gnome-power-manager/lock/blank_screen=false
> /apps/gnome-power-manager/lock/use_screensaver_settings=false
> /apps/gnome-power-manager/notify/sleep_failed_uri=
> /apps/gnome-power-manager/ui/icon_policy=charge
> GnomeSessionIdleInhibited: No
> GnomeSessionInhibitors: None
> GnomeSessionSuspendInhibited: No
> InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Beta i386
> (20100901.1)
> MachineType: Hewlett-Packard HP ENVY 14 Notebook PC
> ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-19-generic-pae
> root=UUID=76ae939d-2ce2-466e-88d5-98b11aad6098 ro quiet splash
> ProcEnviron:
> LANG=en_DK.UTF-8
> SHELL=/bin/bash
> SourcePackage: gnome-power-manager
> dmi.bios.date: 07/21/2010
> dmi.bios.vendor: Hewlett-Packard
> dmi.bios.version: F.12
> dmi.board.asset.tag: Base Board Asset Tag
> dmi.board.name: 1436
> dmi.board.vendor: Hewlett-Packard
> dmi.board.version: 59.20
> dmi.chassis.asset.tag: CNU0274F2B
> dmi.chassis.type: 10
> dmi.chassis.vendor: Hewlett-Packard
> dmi.chassis.version: Chassis Version
> dmi.modalias:
> dmi:bvnHewlett-Packard:bvrF.12:bd07/21/2010:svnHewlett-Packard:pnHPENVY14NotebookPC:pvr0492100000241910000620000:rvnHewlett-Packard:rn1436:rvr59.20:cvnHewlett-Packard:ct10:cvrChassisVersion:
> dmi.product.name: HP ENVY 14 Notebook PC
> dmi.product.version: 0492100000241910000620000
> dmi.sys.v...

Happening on HP dv6-3006tx

I pointed the upstream maintainer to Andy's patch, and he just committed something slightly improved.

This bug was fixed in the package upower - 0.9.12-1

---------------
upower (0.9.12-1) unstable; urgency=low

  * New upstream release:
    - Fix estimation rate for batteries that do not provide this data.
      (LP: #629258)
  * debian/copyright: Fix headers.
  * debian/watch: Look for *.xz tarballs, upstream only publishes these now.
    Repack our tarball as tar.bz2.
 -- Martin Pitt <email address hidden> Fri, 08 Jul 2011 05:47:19 +0000

will there be a natty backport? (please! :)

If someone provides a debdiff for natty and adds the required information for a SRU, I am happy to sponsor that.

Rebuilding the 0.9.12-1 sources on Natty and installing it not only doesn't fix the problem, but makes my laptop suspend any time it is unplugged.

I don't understand all the null updates. My laptop HP DV6646US worked perfectly on the previous 2 releases of Ubuntu. It worked correctly on Natty initially using the classic desktop. But after about a month it stopped working and only shows estimating. I am convinced something changed shortly after Natty was released. Anyhow I think my computer battery must pass the correct information or it would not have worked on the previous releases. And it appears hundred of other users must agree with me.

I'm on Precise right now, with upower 0.9.15 and the problem appears to be solved.

I'm on saucy 13.10, and the problem seems to still be present!

I have this problem on Ubuntu 16.04 running on my Acer Aspire ES 17.

I have it on 16.04 LTS running on a Fujitsu LifeBook T4215. There is an "estimating" message, and the percentage rises from 50% to 100%, then cycles in the same range.

The laptop is a dual boot with Windows 10, and Windows is also showing the same, "estimating and cycling" behavior. I've read in other threads that it is a potential BIOS update issue. IJS.

This bug was fixed over six years ago. If you experience similar systems on multiple operating systems, contact your PC vendor. Otherwise, report a separate bug.