Bug 816775

Summary: Gnome power manager thinks Bluetooth mouse/keyboard battery is notebook battery, suspends if depleted/removed
Product: [Fedora] Fedora Reporter: Jeff Gustafson <ncjeffgus>
Component: gnome-power-managerAssignee: Richard Hughes <hughsient>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 17CC: alfredo.maria.ferrari, beland, bugzilla, charlesr.harris, christian.menzel, david, dkl, hughsient, hyperthinker1024, ian1roberts, ikke, james, mark.harfouche, mikeloco14, nouveau, stevenvandenbrandenstift, vic
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-01 00:39:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jeff Gustafson 2012-04-26 23:36:02 UTC
Description of problem:
When I click on the battery icon in Gnome it shows two batteries. One battery had a very low % of charge and gnome kept putting the computer to sleep/hibernate. After running gnome-power-statistics, I found that one of the batteries it is reporting is the Apple MagicMouse AA batteries. Gnome thinks the internal notebook battery is a "secondary battery". 

Version-Release number of selected component (if applicable):
Fedora 17 -- current packages as of April 26.

How reproducible:
Always

Steps to Reproduce:
1. Connect Apple MagicMouse to gnome using normal procedures.
2. Disconnect the mouse.
3. Put the system to sleep and then turn the system back on.
4. The second battery will still be listed. Gnome thinks the battery is the notebook battery.
  
Actual results:


Expected results:
Gnome should ignore the mouse battery when considering when to put the system to sleep/hibernate.

Additional info:

Comment 1 Jeff Gustafson 2012-04-27 08:37:14 UTC
Dump from upower:

$ upower -d
Device: /org/freedesktop/UPower/devices/line_power_ADP1
  native-path:          /sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/ADP1
  power supply:         yes
  updated:              Fri Apr 27 01:06:34 2012 (1726 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    online:             yes

Device: /org/freedesktop/UPower/devices/battery_hid_34o15o9EoCAo49o75_battery
  native-path:          /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.3/1-1.1.3:1.0/bluetooth/hci0/hci0:12/0005:05AC:030D.0013/power_supply/hid-34:15:9E:CA:49:75-battery
  power supply:         yes
  updated:              Fri Apr 27 01:35:08 2012 (12 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               charging
    energy:              0 Wh
    energy-empty:        0 Wh
    energy-full:         0 Wh
    energy-full-design:  0 Wh
    energy-rate:         0 W
    percentage:          0%
    capacity:            100%

Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0
  vendor:               SMPNz451ABX0ADEF0123456789ABCDE
  model:                bq20z451ABX0ADEF0123456789ABCDE
  power supply:         yes
  updated:              Fri Apr 27 01:35:09 2012 (11 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               fully-charged
    energy:              58.4 Wh
    energy-empty:        0 Wh
    energy-full:         59.72 Wh
    energy-full-design:  69 Wh
    energy-rate:         28.214 W
    voltage:             12.399 V
    percentage:          97.7897%
    capacity:            86.5507%

Daemon:
  daemon-version:  0.9.15
  can-suspend:     yes
  can-hibernate    yes
  on-battery:      no
  on-low-battery:  no
  lid-is-closed:   no
  lid-is-present:  yes
  is-docked:       no

Comment 2 James 2012-05-09 15:16:24 UTC
Similar seen here with a Nikkai Bluetooth mouse:


Device: /org/freedesktop/UPower/devices/battery_hid_00o12oA1o68o7Do2C_battery
  native-path:          /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/bluetooth/hci0/hci0:21/0005:3938:1001.0005/power_supply/hid-00:12:A1:68:7D:2C-battery
  model:                Bluetooth Mouse
  power supply:         no
  updated:              Wed May  9 16:05:06 2012 (8 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    energy:              0 Wh
    energy-empty:        0 Wh
    energy-full:         0 Wh
    energy-full-design:  0 Wh
    energy-rate:         0 W
    percentage:          54%
    capacity:            100%
  History (charge):
    1336575902	54.000	discharging


Observations:

 - Mouse's battery shows up as "Laptop Battery" both in Gnome Shell power
   menu and gnome-power-statistics

 - Capacity remains at 0% until I run upower -d (provokes a polling op?)

 - Although in this case it reports 54% above (cannot state how accurate
   this actually is), there are statements like


[18205.673061] power_supply hid-00:12:A1:68:7D:2C-battery: driver failed to report `capacity' property: -5


   in dmesg. In that case, should upower be reporting anything about the
   mouse's battery's state?

 - When the mouse is plugged in and charging, this is not reflected in the
   output of upower -d.

Running
upower-0.9.16-1.fc17.x86_64
gnome-shell-3.4.1-3.fc17.x86_64
kernel-3.3.5-2.fc17.x86_64

Comment 3 Dave Lawrence 2012-08-19 15:43:31 UTC
This also occurs on my macbook pro 13 using the apple bluetooth keyboard and bluetooth magic trackpad. Very annoying when you come out of suspend when not around either of the bluetooth devices any longer and it thinks your laptop battery is at 0% and automatically shutsdown the system. Even though the laptop battery itself has plenty of power.

Is there anyway to configure upower or the bluetooth settings to disregard the certain bluetooth devices power level? The apple devices use alkaline batteries anyway so its not like we can recharge them.

dkl

Comment 4 Mark Harfouche 2012-09-09 22:55:55 UTC
Same bug on 
HP Envy 4-1030us 
with a Apple Mouse.

Comment 5 Christian Menzel 2012-10-08 16:57:39 UTC
Same here on ThinkPad X220 with Lenovo Bluetooth Laser Mouse

Comment 6 charles harris 2013-01-06 03:46:11 UTC
Seen here on my desktop (!) computer. Fedora thinks my bluetooth K810 keyboard battery is a laptop battery and estimates it to be dead. Consequently the keyboard is gone after the computer wakes up from a suspend.

Comment 7 Alfredo Ferrari 2013-01-27 11:20:30 UTC
... same on Dell Latitude E6520 after upgrade to kernel 3.7.3-101. The battery icon does no longer report the battery state, but rather the (external) mouse power (?) state given as 0.

The output of upower -d is:

Device: /org/freedesktop/UPower/devices/line_power_AC
  native-path:          /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/AC
  power supply:         yes
  updated:              Sun Jan 27 08:06:20 2013 (15107 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    online:             yes

Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0
  vendor:               Sanyo
  model:                DELL 2VYF51A
  serial:               2964
  power supply:         yes
  updated:              Sun Jan 27 08:06:25 2013 (15102 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               fully-charged
    energy:              62.16 Wh
    energy-empty:        0 Wh
    energy-full:         62.16 Wh
    energy-full-design:  62.16 Wh
    energy-rate:         0.0111 W
    voltage:             12.724 V
    percentage:          100%
    capacity:            74.8036%
    technology:          lithium-ion

Device: /org/freedesktop/UPower/devices/mouse_input7
  native-path:          /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.2/0003:046D:C52B.0003/input/input7
  vendor:               Logitech
  model:                Wireless Mouse M325
  power supply:         no
  updated:              Sun Jan 27 12:17:22 2013 (45 seconds ago)
  has history:          yes
  has statistics:       no
  mouse
    present:             yes
    rechargeable:        yes
    state:               unknown
    percentage:          0%

Daemon:
  daemon-version:  0.9.19
  can-suspend:     yes
  can-hibernate:   yes
  on-battery:      no
  on-low-battery:  no
  lid-is-closed:   no
  lid-is-present:  yes
  is-docked:       no

Comment 8 Christopher Beland 2013-02-20 20:08:35 UTC
*** Bug 808237 has been marked as a duplicate of this bug. ***

Comment 9 Christopher Beland 2013-02-20 20:22:50 UTC
*** Bug 830046 has been marked as a duplicate of this bug. ***

Comment 10 Vic Ricker 2013-02-27 23:26:55 UTC
I'm not sure if this is related, but recently, Gnome started reporting my mouse (Logitech MX510) as having 0% charge.  Luckily, it's not affecting the system other than that annoying low battery icon.

I also have a UPS which reports proper charge.

Comment 11 David Strauss 2013-03-08 21:14:56 UTC
My Logitech T650 has the same issue as Vic's setup.

Comment 12 Ian Roberts 2013-03-11 07:46:44 UTC
Logitech MK700/710 (wireless kb / mouse combo) is also represented in gnome power management incorrectly.  It reports mouse power as 100%, keyboard power as 0% and causes lower power notifications to be displayed.  I changed the batteries in the keyboard to demonstrate that power representation was wrong.

Comment 13 James 2013-03-13 07:05:08 UTC
Das Keyboard USB keyboard reports %0, Also my logitech m950 is reported as %0

$ upower -d
Device: /org/freedesktop/UPower/devices/line_power_ADP1
  native-path:          /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP1
  power supply:         yes
  updated:              Wed Mar 13 17:22:05 2013 (2547 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    online:             yes

Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0
  vendor:               SMPNz4517D3LAK6c00ASDI
  model:                bq20z4517D3LAK6c00ASDI
  power supply:         yes
  updated:              Wed Mar 13 18:04:13 2013 (19 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               charging
    energy:              46.21 Wh
    energy-empty:        0 Wh
    energy-full:         51.99 Wh
    energy-full-design:  57.7 Wh
    energy-rate:         17.472 W
    voltage:             12.561 V
    time to full:        19.8 minutes
    percentage:          88.8825%
    capacity:            90.104%
  History (charge):
    1363158253	88.882	charging
    1363158223	88.652	charging
    1363158193	88.421	charging
    1363158163	88.190	charging
  History (rate):
    1363158253	17.472	charging
    1363158223	17.772	charging
    1363158193	18.084	charging
    1363158163	18.397	charging

Device: /org/freedesktop/UPower/devices/mouse_input20
  native-path:          /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.2/2-1.2.2/2-1.2.2:1.2/0003:046D:C52B.000F/input/input20
  vendor:               Logitech
  power supply:         no
  updated:              Wed Mar 13 18:04:17 2013 (15 seconds ago)
  has history:          yes
  has statistics:       no
  mouse
    present:             yes
    rechargeable:        yes
    state:               discharging
    percentage:          0%

Device: /org/freedesktop/UPower/devices/keyboard_input19
  native-path:          /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.2/2-1.2.2/2-1.2.2:1.2/0003:046D:C52B.000F/input/input19
  vendor:               Logitech
  power supply:         no
  updated:              Wed Mar 13 18:04:17 2013 (15 seconds ago)
  has history:          yes
  has statistics:       no
  keyboard
    present:             no
    rechargeable:        yes
    state:               unknown
    percentage:          0%

Daemon:
  daemon-version:  0.9.19
  can-suspend:     yes
  can-hibernate:   no
  on-battery:      no
  on-low-battery:  no
  lid-is-closed:   no
  lid-is-present:  yes
  is-docked:       no

Comment 14 Fedora End Of Life 2013-07-03 22:38:45 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

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 prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 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 to Fedora 17's end of life.

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.

Comment 15 Fedora End Of Life 2013-08-01 00:39:34 UTC
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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.

Thank you for reporting this bug and we are sorry it could not be fixed.