Created attachment 776369 [details] lspci -vvv I have a Lenovo T430 ThinkPad with a single battery installed. Sometimes after resuming the laptop from suspend, the gnome-shell battery indicator displays two batteries instead of just one. The real battery and the erroneous phantom battery are each displayed with a different charge percentage.
After a little more investigating, I've discovered that the second battery is actually the battery in a Bluetooth mouse connected to the laptop. However, it is being misidentified by GNOME as an extra laptop battery instead of a Bluetooth device battery.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
Still here with kernel 3.11.1-200.fc19.x86_64. $ upower -e /org/freedesktop/UPower/devices/line_power_AC /org/freedesktop/UPower/devices/battery_BAT0 /org/freedesktop/UPower/devices/battery_hid_f0o65oddo67oa2ob9_battery
This only happens after a resume, or any time the bluetooth mouse is used?
After resume, with the BT mouse off and BT not yet bounced, the battery is still showing up as a laptop battery in the gnome shell battery indicator, albeit at 0%. Upower says: $ upower -e /org/freedesktop/UPower/devices/line_power_AC /org/freedesktop/UPower/devices/battery_hid_f0o65oddo67oa2ob9_battery /org/freedesktop/UPower/devices/battery_BAT0 It disappears only after disabling bluetooth. I'll reboot and see what happens on fresh boot.
On fresh boot, the mouse battery still shows up as a laptop battery. $ upower -e /org/freedesktop/UPower/devices/line_power_AC /org/freedesktop/UPower/devices/battery_BAT0 /org/freedesktop/UPower/devices/battery_hid_f0o65oddo67oa2ob9_battery bluez and bluez-libs are at 4.101-9.fc19, kernel is 3.11.1-200.fc19.
There's a scope to HID batteries that upower is supposed to be looking at.
This same issue seems to be happening on Fedora 20. It worked correctly when I first installed F20. Not sure which update reverted the behavior.
Update on my previous comments, suspend/resume doesn't seem to have any relevance with F20 lately. As Ivan said, this worked correctly for some period after upgrading to F20 but lately is broken again. With AC adapter plugged in: BT Mouse connected: Power Settings: - Summary is "discharging 99%" - Main laptop battery shown as discharging, 98% - Mouse battery is mis-identified as extra laptop battery, shown as charging. Status menu: - Battery icon does not show charging symbol, label is "estimating" BT mouse disconnected: power displays are now correct Power Settings: - Battery now only consists of a single bar, "Fully charged". Status menu: - Battery icon correct, label is "Fully charged". Reconnecting the BT mouse reverts to first behavior. This is all on a fresh boot, to suspend/resume involved. upower -e output is the same as above.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I can confirm this bug in Fedora 21.
With F21 here: Status icon behavior is correct. When running on battery, and with the BT mouse connected, status is stuck in "Estimating" for a little while (few minutes?) but eventually switches to correct estimate. BT mouse battery in all cases is shown as "extra" in power settings and with a different color than the one used for the main battery. Is that intended behavior? Henrique, have you given it a few minutes for estimation to catch up? $ upower -e /org/freedesktop/UPower/devices/line_power_AC /org/freedesktop/UPower/devices/battery_BAT0 /org/freedesktop/UPower/devices/battery_hid_00o1fo20oe5o47obf_battery /org/freedesktop/UPower/devices/DisplayDevice
I don't get any status for the mouse battery in the system status area. Anyway, I was just reporting about the mouse battery being identified as an extra laptop battery.
(In reply to Henrique Ferreiro from comment #13) > I don't get any status for the mouse battery in the system status area. > Anyway, I was just reporting about the mouse battery being identified as an > extra laptop battery. To clarify, in https://bugzilla.redhat.com/show_bug.cgi?id=986633#c12 I was referring to the (displayed) status of the main battery. Under F20 the presence of a BT mouse would interfere with that, it no longer does under F21. BT battery is identified as an "extra" battery in power settings, I no longer remember (F19? earlier F20?) how the BT battery was supposed to display there.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.