Bug 806295 - 3.3.0-4.fc16.x86_64 is FUBAR on imac 27" which now thinks it has a battery.
3.3.0-4.fc16.x86_64 is FUBAR on imac 27" which now thinks it has a battery.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: upower (Show other bugs)
17
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
: Reopened
: 809279 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-23 07:41 EDT by Andrew Walrond
Modified: 2013-08-01 13:05 EDT (History)
14 users (show)

See Also:
Fixed In Version: kernel-2.6.43.2-6.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 13:05:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of acpidump as root (129.06 KB, application/octet-stream)
2012-03-23 11:57 EDT, Andrew Walrond
no flags Details
dmesg from broken kernel (99.20 KB, application/octet-stream)
2012-03-23 12:33 EDT, Andrew Walrond
no flags Details
sudo upower --dump (1.06 KB, application/octet-stream)
2012-03-24 06:08 EDT, Andrew Walrond
no flags Details
lsinput with apple bt trackpad and keyboard (3.08 KB, text/plain)
2012-10-24 01:37 EDT, Ilkka Tengvall
no flags Details
rdesc for apple bt keyboard (17.86 KB, text/plain)
2012-10-24 07:34 EDT, Ilkka Tengvall
no flags Details

  None (edit)
Description Andrew Walrond 2012-03-23 07:41:01 EDT
Description of problem:

System has been working perfectly for months and most recently with kernel 3.2.10-3.fc16.x86_64.

After updating to 3.3.0-4.fc16.x86_64, System booted fine, but now has a battery icon (This is an imac, no battery and on a/c)
 After a short while, (I think after 'estimating' the remaining battery time), fedora announced it was hibernating due to critical battery. Bluetooth kb and mouse froze. System hibernated.
 After restart, bluetooth non functional, had to use usb keyboard to reboot.

I tried this all again to make sure it wasn't a temporary madness, but problem is repeatable.

Rebooting to 3.2.10-3 and everything is fine again.


Version-Release number of selected component (if applicable):

3.3.0-4.fc16.x86_64
Comment 1 Matthew Garrett 2012-03-23 10:58:31 EDT
Can you install the pmtools package and attach the output of the acpidump command (when run as root)?
Comment 2 Andrew Walrond 2012-03-23 11:57:56 EDT
Created attachment 572320 [details]
Output of acpidump as root

Sure thing - see attachment.
Comment 3 Matthew Garrett 2012-03-23 12:06:48 EDT
Thanks! Any chance you can get dmesg for the broken case?
Comment 4 Andrew Walrond 2012-03-23 12:33:25 EDT
Created attachment 572329 [details]
dmesg from broken kernel

Dmesg output as requested
Comment 5 Matthew Garrett 2012-03-23 12:42:43 EDT
The battery is coming from your wireless keyboard. What desktop environment are you running?
Comment 6 Richard Hughes 2012-03-23 12:47:35 EDT
Can you also get the output of "upower --dump" -- Thanks.
Comment 7 Andrew Walrond 2012-03-23 14:29:52 EDT
I'm running default fedora gnome 3 environment.
I'll grab the upower output when I get to the office in the morning.
Enjoy your Friday evenings :)
Comment 8 Andrew Walrond 2012-03-23 14:35:02 EDT
PS it is rather amusing that my iMac thinks it's running off the AA batteries in the Bluetooth keyboard! No wonder it panicked! :)
Comment 9 Andrew Walrond 2012-03-24 06:08:30 EDT
Created attachment 572418 [details]
sudo upower --dump

Here you go
Comment 10 Richard Hughes 2012-03-25 16:30:05 EDT
Urgh:

> power supply:         yes

What does "ls /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/bluetooth/hci0/hci0:12/0005:05AC:030D.0004/power_supply/hid-10:9A:DD:76:0A:5A-battery" and "cat /sys/class/power_supply/BAT0/type" say?

Thanks,

Richard
Comment 11 Andrew Walrond 2012-03-26 04:58:43 EDT
andrew@golden ~ $ ls -l /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/bluetooth/hci0/hci0:12/0005:05AC:030D.0004/power_supply/hid-10:9A:DD:76:0A:5A-battery
total 0
-r--r--r--. 1 root root 4096 Mar 26 09:45 capacity
lrwxrwxrwx. 1 root root    0 Mar 26 09:47 device -> ../../../0005:05AC:030D.0004
-r--r--r--. 1 root root 4096 Mar 26 09:45 model_name
-r--r--r--. 1 root root 4096 Mar 26 09:47 online
drwxr-xr-x. 2 root root    0 Mar 26 09:47 power
-r--r--r--. 1 root root 4096 Mar 26 09:45 present
-r--r--r--. 1 root root 4096 Mar 26 09:45 status
lrwxrwxrwx. 1 root root    0 Mar 26 09:45 subsystem -> ../../../../../../../../../../../../../../class/power_supply
-r--r--r--. 1 root root 4096 Mar 26 09:45 type
-rw-r--r--. 1 root root 4096 Mar 26 09:45 uevent

andrew@golden ~ $ cat /sys/class/power_supply/BAT0/type
cat: /sys/class/power_supply/BAT0/type: No such file or directory

andrew@golden ~ $ cat /sys/class/power_supply/hid-10\:9A\:DD\:
hid-10:9A:DD:76:0A:5A-battery/ hid-10:9A:DD:91:97:30-battery/ 

andrew@golden ~ $ cat /sys/class/power_supply/hid-10\:9A\:DD\:76\:0A\:5A-battery/type 
Battery

andrew@golden ~ $ cat /sys/class/power_supply/hid-10\:9A\:DD\:91\:97\:30-battery/type 
Battery

andrew@golden ~ $
Comment 12 Kevin Kofler 2012-04-04 05:14:18 EDT
*** Bug 809279 has been marked as a duplicate of this bug. ***
Comment 13 Josh Boyer 2012-04-04 08:37:58 EDT
Richard, Matthew, I'm not sure this is a kernel bug.  The kernel is just reporting a battery state for a HIDE device, which seems perfectly reasonable to me.

Should this be moved to upower?
Comment 14 Josh Boyer 2012-04-18 10:02:35 EDT
For now, I disabled CONFIG_HID_BATTERY_STRENGTH in the f15/f16 kernels.  Matthew suggested we move this bug to F17 as there are kernel and upower patches needed to properly support this.
Comment 15 Richard Hughes 2012-04-18 11:56:01 EDT
I've pushed this to upower:

commit 28c8653ed8d43bfdcac4bb09c0fe16b5ac124668
Author: Richard Hughes <richard@hughsie.com>
Date:   Wed Apr 18 16:46:41 2012 +0100

    Never detect HID devices with batteries as power supplies

    Some HID devices with batteries (like bluetooth keyboards) have been
creating
    power supply devices in sysfs since Linux 3.3.
    UPower thinks that they are system devices and shuts down the system if
they
    get low. This is bad.

    This is fixed in Linux 3.4, where there is a new 'scope' file that defines
if
    the device is powering the system.
    Helpfully ACPI batteries don't populate the scope value, but soon will.

    Add support for the scope attribute now, and default to system devices if
it's
    missing. Note, you need to be running a 3.4 kernel or a 3.3 with the patch
    backported for this to work.

    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=806295
Comment 16 Josh Boyer 2012-04-18 12:29:55 EDT
(In reply to comment #15)
> I've pushed this to upower:
> 
> commit 28c8653ed8d43bfdcac4bb09c0fe16b5ac124668
> Author: Richard Hughes <richard@hughsie.com>
> Date:   Wed Apr 18 16:46:41 2012 +0100
> 
>     Never detect HID devices with batteries as power supplies

Will a upower package with that commit get pushed to Fedora?  If so, which branches?
Comment 17 Richard Hughes 2012-04-18 12:39:53 EDT
(In reply to comment #16)
> Will a upower package with that commit get pushed to Fedora?  If so, which
> branches?

Yup, I'm planning to to a release upstream this week after someone has tested that patch with mjg's new kernel. I'll push it to F17 and rawhide, but I can do F16 as well if you want.
Comment 18 Josh Boyer 2012-04-18 12:47:51 EDT
(In reply to comment #17)
> (In reply to comment #16)
> > Will a upower package with that commit get pushed to Fedora?  If so, which
> > branches?
> 
> Yup, I'm planning to to a release upstream this week after someone has tested
> that patch with mjg's new kernel. I'll push it to F17 and rawhide, but I can do
> F16 as well if you want.

OK.  I think F17 and rawhide are probably just fine.  I've already disabled the config option on F16 so it won't help there and I'll look at backporting the changes from 3.4 to F17 later this week.

Thanks.
Comment 19 Fedora Update System 2012-04-21 12:46:15 EDT
kernel-2.6.43.2-6.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/kernel-2.6.43.2-6.fc15
Comment 20 Fedora Update System 2012-04-21 23:44:22 EDT
Package kernel-2.6.43.2-6.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-2.6.43.2-6.fc15'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-6406/kernel-2.6.43.2-6.fc15
then log in and leave karma (feedback).
Comment 21 Andrew Walrond 2012-04-22 04:23:09 EDT
Presumably the fc16 kernel will also be forthcoming soon?
Comment 22 Josh Boyer 2012-04-23 09:28:27 EDT
(In reply to comment #21)
> Presumably the fc16 kernel will also be forthcoming soon?

http://koji.fedoraproject.org/koji/buildinfo?buildID=314510

It's set to hit f16-updates on the next push.  I didn't include this bug number on the bodhi update for f16 because I didn't want bodhi to auto-close the bug.  It still needs work for F17.
Comment 23 Fedora Update System 2012-04-25 23:27:24 EDT
kernel-2.6.43.2-6.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 24 Andrew Walrond 2012-06-01 10:34:54 EDT
I thought I'd seen the back of this, but then I upgraded to F17...
Comment 25 Josh Boyer 2012-06-01 14:13:40 EDT
(In reply to comment #24)
> I thought I'd seen the back of this, but then I upgraded to F17...

Oops.  Yeah, comment #22 clearly says it needs more work in F17.  Fortunately, F17 will be rebased to 3.4.x hopefully today.
Comment 26 Andrew Walrond 2012-06-04 06:00:18 EDT
Got 3.4 from testing this morning and all is well again.

What changed? I assume the kernel now presents modified information to upower.
Is this a permanent and complete fix or is there more to do?
Comment 27 Josh Boyer 2012-06-04 08:22:23 EDT
(In reply to comment #26)
> Got 3.4 from testing this morning and all is well again.
> 
> What changed? I assume the kernel now presents modified information to
> upower.

3.4 has additional commits to provide scope for the sysfs battery information.

> Is this a permanent and complete fix or is there more to do?

As soon as 3.4 hits F17 stable updates, it will be permanent.  There's nothing more to do from what I remember.  I'll mark this bug in the 3.4 update so it gets closed by Bodhi.
Comment 28 Fedora Update System 2012-06-04 08:24:02 EDT
kernel-3.4.0-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/FEDORA-2012-8824/kernel-3.4.0-1.fc17
Comment 29 Fedora Update System 2012-06-06 22:33:05 EDT
kernel-3.4.0-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 30 Andrew Walrond 2012-08-07 04:17:25 EDT
My Imac's ghostly laptop battery is back :(

I've got testing updates enabled, so hopefully we can fix it before it reaches the main repo? I think it arrived during a yum update yesterday, although I can't be certain since I only just noticed it this morning.

Let me know what info you need.
Comment 31 Dave Jones 2012-08-07 12:08:30 EDT
I assume you're running the latest upower update already.

does upower --dump look any different from last time ?
Comment 32 Andrew Walrond 2012-08-08 09:33:37 EDT
$ upower --version
UPower client version 0.9.17
UPower daemon version 0.9.17

$ sudo upower --dump
Device: /org/freedesktop/UPower/devices/battery_hid_10o9AoDDo76o0Ao5A_battery
  native-path:          /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/bluetooth/hci0/hci0:12/0005:05AC:030D.0005/power_supply/hid-10:9A:DD:76:0A:5A-battery
  power supply:         no
  updated:              Wed Aug  8 14:31:51 2012 (5 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               empty
    energy:              0 Wh
    energy-empty:        0 Wh
    energy-full:         0 Wh
    energy-full-design:  0 Wh
    energy-rate:         0 W
    percentage:          0%
    capacity:            100%

Daemon:
  daemon-version:  0.9.17
  can-suspend:     yes
  can-hibernate    yes
  on-battery:      no
  on-low-battery:  no
  lid-is-closed:   no
  lid-is-present:  no
  is-docked:       no
Comment 33 Dave Jones 2012-08-08 12:11:02 EDT
to clarify, is this actually causing a problem like it was before ?

from the looks of things, it's just reporting that there's a battery, which is expected.  The 'on-battery: no' seems to suggest it's working.

Richard ?
Comment 34 Kevin Kofler 2012-08-08 17:36:37 EDT
AIUI, the version of upower in F16 does not support this kernel feature, and as per comment #15, it used to be disabled in F16 kernels, apparently this was lost in the 3.3 rebase.
Comment 35 Kevin Kofler 2012-08-08 17:37:52 EDT
Sorry, as per comment #14, I mean.
Comment 36 Josh Boyer 2012-08-08 19:06:49 EDT
(In reply to comment #34)
> AIUI, the version of upower in F16 does not support this kernel feature, and
> as per comment #15, it used to be disabled in F16 kernels, apparently this
> was lost in the 3.3 rebase.

I doubt it.  3.4 works fine and that is what F16 is on still.  3.5 seems to be the kernel causing this to reappear based on other bug reports, but that is only in F17.  My guess would be Andrew is on F17 now.

Either way, answering Dave's question would be good.
Comment 37 Andrew Walrond 2012-08-09 04:47:29 EDT
I'm using 17 (and this entry is marked as such) although these issues seem well travelled ;)

You are right of course; this new issue is of lesser importance since my machine does not seem to be considered as 'on battery' and shutting down at random intervals as before.

However, it's not strictly 'right' since
1) Gnome reports a 'laptop battery, 0%'
2) Upower reports a rechargeable battery - which it/they are not - disposable AAs
3) Where is the other one? There were two reported before; I have both bt keyboard and mouse.
Comment 38 Dave Jones 2012-08-09 10:38:29 EDT
I suspect upower needs to walk the sysfs path to figure out what the battery belongs to so that it can give it a better name than 'laptop battery'.
Comment 39 Andrew Walrond 2012-08-12 03:56:52 EDT
After another upgrade last night I now have both bluetooth device batteries showing up in upower and gnome.

Now if we can just get the names right it will all be tickety boo!

$ sudo upower -d
Device: /org/freedesktop/UPower/devices/battery_hid_10o9AoDDo91o97o30_battery
  native-path:          /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/bluetooth/hci0/hci0:11/0005:05AC:023A.0004/power_supply/hid-10:9A:DD:91:97:30-battery
  model:                Apple Wireless Keyboard
  power supply:         no
  updated:              Sun Aug 12 08:53:11 2012 (18 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:          0%
    capacity:            100%
  History (charge):
    1344757956	0.000	unknown
  History (rate):
    1344757956	0.000	unknown

Device: /org/freedesktop/UPower/devices/battery_hid_10o9AoDDo76o0Ao5A_battery
  native-path:          /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/bluetooth/hci0/hci0:14/0005:05AC:030D.0006/power_supply/hid-10:9A:DD:76:0A:5A-battery
  model:                andrewwalronds mouse
  power supply:         no
  updated:              Sun Aug 12 08:53:11 2012 (18 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:          40%
    capacity:            100%
  History (charge):
    1344757958	40.000	discharging
    1344757956	0.000	unknown
  History (rate):
    1344757956	0.000	unknown

Daemon:
  daemon-version:  0.9.17
  can-suspend:     yes
  can-hibernate    yes
  on-battery:      no
  on-low-battery:  no
  lid-is-closed:   no
  lid-is-present:  no
  is-docked:       no
Comment 40 W.C. Epperson 2012-08-19 10:52:32 EDT
I'm experiencing what looks like a related problem since 3.5.1-1.fc17, not sure whether to open separate bug or not.  System shows Rocketfish BT mouse battery, goes to some sort of sleep state (NOT hibernate as set in power settings) when inactive for some period.  When awakened, mouse is not responsive.  I've stumbled on the awkward workaround that CTRL-ALT-F2 to a console session and back restores mouse function.

upower -d is similar to above.  Dmesg shows this after such an event:
[151821.493051] power_supply hid-00:02:76:10:B5:D8-battery: driver failed to report `capacity' property: -5
[154466.699370] hid-generic 0005:19FF:0207.000F: unknown main item tag 0x0
[154466.717698] input: Rocketfish Apple Bluetooth Mouse as /devices/pci0000:00/0000:00:1d.2/usb7/7-2/7-2:1.0/bluetooth/hci0/hci0:11/input29
[154466.718269] hid-generic 0005:19FF:0207.000F: input,hidraw0: BLUETOOTH HID v2.45 Mouse [Rocketfish Apple Bluetooth Mouse] on 00:24:7E:17:7D:98

Will post further info here if requested, otherwise will open new bug.
Comment 41 W.C. Epperson 2012-08-20 18:09:11 EDT
Picked up kernel-3.5.2-1.fc17.x86_64 on a yum update, and two things happened that I noticed:

1) gnome power manager now shows a percentage remaining for the Rocketfish batteries
2) The mouse no longer gets lost after a sleep/quasi-sleep
Comment 42 Daniel Nicoletti 2012-09-14 22:06:35 EDT
(In reply to comment #39)
> After another upgrade last night I now have both bluetooth device batteries
> showing up in upower and gnome.
> 
> Now if we can just get the names right it will all be tickety boo!
> 
> $ sudo upower -d
> Device: /org/freedesktop/UPower/devices/battery_hid_10o9AoDDo91o97o30_battery
>   native-path:         
> /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/
> bluetooth/hci0/hci0:11/0005:05AC:023A.0004/power_supply/hid-10:9A:DD:91:97:
> 30-battery
>   model:                Apple Wireless Keyboard
>   power supply:         no
>   updated:              Sun Aug 12 08:53:11 2012 (18 seconds ago)
>   has history:          yes
>   has statistics:       yes
>   battery
>     present:             yes
>     rechargeable:        yes
>     state:               discharging
>     percentage:          0%
>     capacity:            100%
Hi, I wrote the kernel patch that probes these devices, tho most of the issues said here are userland issues I noticed this output which might need fixing.
Some Apple keyboards have wrong info in their descriptions, which is the case of  my keyboard but not my magic track pad, so in order to improve the system we need to add quirks to the kernel.

Can you please say if with an used battery the percentage is still 0% ? if so can you give use the lsinput info of your keyboard?
- The mouse is just fine...

Thanks.
Comment 43 Ilkka Tengvall 2012-10-22 06:02:39 EDT
Hi, my keyboard is doing this on fedora 17. It trashes the log with: 

-----------------------------
[349847.631435] power_supply hid-7C:C3:A1:XX:XX:XX-battery: driver failed to report `capacity' property: -5
-----------------------------


-----------------------------
$ upower --dump
Device: /org/freedesktop/UPower/devices/battery_hid_7CoC3oA1oXXoXXoXX_battery
  native-path:          /sys/devices/pci0000:00/0000:00:16.0/usb7/7-4/7-4:1.0/bluetooth/hci0/hci0:11/0005:05AC:0256.0003/power_supply/hid-7C:C3:A1:XX:XX:XX-battery
  model:                Apple Wireless Keyboard
  power supply:         no
  updated:              Mon Oct 22 12:52:30 2012 (0 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:          0%
    capacity:            100%

Device: /org/freedesktop/UPower/devices/battery_hid_60oC5o47o82oC6o3E_battery
  native-path:          /sys/devices/pci0000:00/0000:00:16.0/usb7/7-4/7-4:1.0/bluetooth/hci0/hci0:12/0005:05AC:030E.0004/power_supply/hid-60:C5:47:XX:XX:XX-battery
  model:                Apple Wireless Trackpad
  power supply:         no
  updated:              Mon Oct 22 12:52:09 2012 (21 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:          19%
    capacity:            100%

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

It seems there are several tickets open related to the same issue. At least:

812625, 830046, 845770, 806295, 863524
Comment 44 Daniel Nicoletti 2012-10-22 08:37:24 EDT
@Ilkka Tengvall
Can you please attach the lsinput output, there are some devices that do not report the correct info about how to grab the information, resulting in the error you get, in those cases I need to add a quirk to the kernel, I just need to make sure you are having the same case..
Comment 45 Ilkka Tengvall 2012-10-24 01:37:23 EDT
Created attachment 632549 [details]
lsinput with apple bt trackpad and keyboard

Daniel, here's the lsinput info.
Comment 46 Daniel Nicoletti 2012-10-24 07:03:35 EDT
(In reply to comment #45)
> Created attachment 632549 [details]
> lsinput with apple bt trackpad and keyboard
> 
> Daniel, here's the lsinput info.

Thanks, can you also attach the file /sys/kernel/debug/hid/[YOUR DEVICE]/rdesc, and also confirm that killing upower, then upower -d never shows the correct percentage of the keyboard?
Comment 47 Ilkka Tengvall 2012-10-24 07:34:27 EDT
Created attachment 632695 [details]
rdesc for apple bt keyboard

$ sudo service upower stop
Redirecting to /bin/systemctl stop  upower.service
$ ps -ef |grep u[p]owe
$
$ upower -d
Device: /org/freedesktop/UPower/devices/battery_hid_7CoC3oA1o98o49oD6_battery
  native-path:          /sys/devices/pci0000:00/0000:00:16.0/usb7/7-4/7-4:1.0/bluetooth/hci0/hci0:11/0005:05AC:0256.0003/power_supply/hid-7C:C3:A1:98:49:D6-battery
  model:                Apple Wireless Keyboard
  power supply:         no
  updated:              Wed Oct 24 14:33:34 2012 (0 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:          0%
    capacity:            100%
  History (charge):
    1351078414	0.000	unknown
  History (rate):
    1351078414	0.000	unknown
Comment 48 Ilkka Tengvall 2012-10-24 07:39:40 EDT
btw, gnome3 shows the red battery sign on the panel, and tells I have two laptop batteries on my desktop PC (apple kb&mouse). The trackpad mouse charge level there is ok, 14%, but keyboard shows 0%, and at least I'm typing this with it...
Comment 49 Daniel Nicoletti 2012-10-24 07:47:44 EDT
(In reply to comment #48)
> btw, gnome3 shows the red battery sign on the panel, and tells I have two
> laptop batteries on my desktop PC (apple kb&mouse). The trackpad mouse
> charge level there is ok, 14%, but keyboard shows 0%, and at least I'm
> typing this with it...

Thanks, your device is "broken" like mine, so a kernel patch is needed.

INPUT(71)[INPUT]
    Field(0)
      Logical(GenericDesktop.Keyboard)
      Application(Consumer.0001)
      Usage(1)
        GenericDeviceControls.BatteryStrength
      Logical Minimum(0)
      Logical Maximum(255)
      Report Size(8)
      Report Count(1)
      Report Offset(0)
      Flags( Variable Absolute )

Instead if INPUT it should report as FEATURE, and Logical Maximum (255) should be (100).

the problem is providing a patch so you could test :/
Comment 50 Kazimieras Vaina 2013-05-04 03:31:19 EDT
I'm having the same issue with Fedora 18 (3.8.x kernel series) and a low-end bluetooth mouse. The upower reports an additional battery and following messages appear in dmesg:

power_supply hid-00:60:D1:01:B1:02-battery: driver failed to report `capacity' property: -5

It also often prevents mouse from functioning - mouse is connected, but mouse cursor does not move on the screen. I need to reconnect the mouse several times to get it working.


As a workaround I recompiled the kernel with CONFIG_HID_BATTERY_STRENGTH disabled and it's all ok now.
Comment 51 Fedora End Of Life 2013-07-04 01:50:04 EDT
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 52 Fedora End Of Life 2013-08-01 13:05:17 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.