That doesn't sound complicated to fix, though I'm not sure what's the best strategy in term of UPower handling of that case. Richard, do you have any hint, or you're comfortable enough to fix it?
I can test a patch if you don't have the hardware.

I'm now at a machine which has these devices attached. I can reproduce the bug with 0.9.19, but interestingly with git head I don't see the devices at all any more. There might be some regression in http://cgit.freedesktop.org/upower/commit/?id=b1f12feb1fd45, did you or Julien happen to try current master with such a device?

The udev rule seems to work somewhat; it attaches the property to the USB HID device (not the input device); I assume that's intended?

P: /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.2/0003:046D:C52B.0004/0003:046D:C52B.0005
E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.2/0003:046D:C52B.0004/0003:046D:C5
2B.0005
E: DRIVER=logitech-djdevice
E: HID_ID=0003:0000046D:0000C52B
E: HID_NAME=Logitech Unifying Device. Wireless PID:1024
E: HID_PHYS=usb-0000:00:1a.0-1.5.1:1
E: MODALIAS=hid:b0003g0000v0000046Dp0000C52B
E: SUBSYSTEM=hid
E: UDEV_LOG=3
E: UPOWER_BATTERY_TYPE=unifying
E: USEC_INITIALIZED=47249781752

P: /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.2/0003:046D:C52B.0004/0003:046D:C52B.0006
E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.2/0003:046D:C52B.0004/0003:046D:C5
2B.0006
E: DRIVER=logitech-djdevice
E: HID_ID=0003:0000046D:0000C52B
E: HID_NAME=Logitech Unifying Device. Wireless PID:2011
E: HID_PHYS=usb-0000:00:1a.0-1.5.1:2
E: MODALIAS=hid:b0003g0000v0000046Dp0000C52B
E: SUBSYSTEM=hid
E: UDEV_LOG=3
E: UPOWER_BATTERY_TYPE=unifying
E: USEC_INITIALIZED=47249782421


With that, the debugging output is

TI:04:15:59     registering subsystem : hid
TI:04:15:59     failed to coldplug /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.3/0003:046D:0A29.0001
TI:04:15:59     failed to coldplug /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/0003:046D:C52B.0002
TI:04:15:59     failed to coldplug /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.1/0003:046D:C52B.0003
TI:04:15:59     failed to coldplug /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.2/0003:046D:C52B.0004
TI:04:15:59     Using Unifying receiver hidraw device file: /dev/hidraw1
TI:04:15:59     Getting idx for feature GetDeviceNameType [05]
TI:04:15:59     Failed to get feature idx: invalid response from device: 7
TI:04:15:59     Getting idx for feature BatteryLevelStatus [1000]
TI:04:15:59     Failed to get feature idx: invalid response from device: 7
TI:04:15:59     Getting idx for feature SolarDashboard [4301]
TI:04:15:59     Failed to get feature idx: invalid response from device: 7
TI:04:15:59     failed to coldplug unifying device: device is unreachable
TI:04:15:59     failed to coldplug /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.2/0003:046D:C52B.0004/0003:046D:C52B.0005
TI:04:15:59     Using Unifying receiver hidraw device file: /dev/hidraw1
TI:04:15:59     Getting idx for feature GetDeviceNameType [05]
TI:04:15:59     Failed to get feature idx: invalid response from device: 7
TI:04:15:59     Getting idx for feature BatteryLevelStatus [1000]
TI:04:15:59     Failed to get feature idx: invalid response from device: 7
TI:04:15:59     Getting idx for feature SolarDashboard [4301]
TI:04:15:59     Failed to get feature idx: invalid response from device: 7
TI:04:15:59     failed to coldplug unifying device: device is unreachable
TI:04:15:59     failed to coldplug /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.2/0003:046D:C52B.0004/0003:046D:C52B.0006

Julien, FTR, I'm "pitti" on Freenode (hanging out in e. g. #udev) if you want to discuss/debug on IRC.

On 0.9.19, the debug output is

TI:04:19:37        invalid bitmask entry for /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/
1-1.5/1-1.5.1/1-1.5.1:1.2/0003:046D:C52B.0004/input/input5
TI:04:19:37        Using Unifying receiver hidraw device file: /dev/hidraw1
TI:04:19:37        object path = /org/freedesktop/UPower/devices/mouse_input5
TI:04:19:37        Unifying device 1 is offline
TI:04:19:37        added native-path: /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.2/0003:046D:C52B.0004/input/input5
TI:04:19:37        using id: Logitech
[...]
TI:04:19:37        invalid bitmask entry for /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.2/0003:046D:C52B.0004/input/input6
TI:04:19:37        Using Unifying receiver hidraw device file: /dev/hidraw1
TI:04:19:37        object path = /org/freedesktop/UPower/devices/keyboard_input6
TI:04:19:37        Unifying device 2 is offline
TI:04:19:37        added native-path: /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.2/0003:046D:C52B.0004/input/input6

TI:04:19:37        using id: Logitech

The "invalid bitmask" might be related to http://cgit.freedesktop.org/upower/commit/?id=35b0d25 ?

With git reset to commit 35b0d25 I basically get the same output as with 0.9.19, so the "invalid bitmask" still remains with 35b0d25.

Julien was talking to me on IRC, and got me some clarifications:

 - The "invalid bit mask" thing is something else, and nothing to worry about.

 - In the original bug report, both devices were "present", whereas in my remote ssh testing they are both "offline". That's because these devices power down after some minutes of inactivity, which is plausible because the person owning this device is asleep right now, and I only have ssh access.

 - You can't read charge levels or much else from powered down devices. However, that's not the bug here as even in the original report, where both devices are online, the percentage is 0%

 - Julien only wrote support for the HID 1.0 protocol, but on that machine they are using HID++ 2.0.

So we are back to the original problem that upower should not claim a 0% percentage if its actually unable to read the percentage.

Also, it seems that the refactoring patch broke these devices entirely, but that might also just be fallout from the powered down devices somehow, and thus I'd rather let Julien test it again on master.

Thanks!

Hi all, 

Anyone having a beginning of a fix to test for this bug?
I'm having kind of a similar problem with my wireless logitech mouse.
From time to time upower shows the mouse at 100% and other times at 1%. So I get notification all the time in gnome-shell.
If you have any code path to look at I would be happy to try some things out.

Thanks.

Lionel, a mouse you say? I guess that is an issue which occurs when older (non-related!) reports from hidraw are seen as a response to the battery query.

Please try https://git.lekensteyn.nl/upower/log/?h=hidpp-rework, that should resolve your issue. At least get the commits up to https://git.lekensteyn.nl/upower/commit/?h=hidpp-rework&id=a375524c52e75079236127f9a89bd335cd37b3c9

This should be fixed with the set of Peter Wu's "hidpp" rewrite patches which landed in upstream master now.

Thanks for merging. Martin, note that the battery percentage may still show as 0% if a device was unavailable when UPower starts, but in that case the state is "unknown". Applications should check the state before using "percentage".

Heads-up: I noticed that the K800 reports 0% while charging (0 means "unknown level"). I think this is unfixable in UPower and that applications should not warn when a device is charging and the percentage is 0.

This also messes up history, if you expected a nice history with a climbing percentage, you will be disappointed. I wonder what happens when the battery is fully charged.

Using upower 0.9.23-2 on Debian, I still have this issue:

Device: /org/freedesktop/UPower/devices/mouse_0003o046DoC52Bx0004
  native-path:          /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.2/0003:046D:C52B.0003/0003:046D:C52B.0004
  vendor:               Logitech, Inc.
  model:                Performance MX
  serial:               CC1238BC
  power supply:         no
  updated:              lun. 28 oct. 2013 23:24:33 CET (58 seconds ago)
  has history:          yes
  has statistics:       no
  mouse
    present:             yes
    rechargeable:        yes
    state:               discharging
    percentage:          20%

The battery level is wrong and sometimes fluctuate (between 1%; 20% and 55%).
Currently the battery is almost full (thanks to the LEDs on the mouse) and the battery level only indicates 20%.

(In reply to comment #12)
> Using upower 0.9.23-2 on Debian, I still have this issue:
> [..]
> The battery level is wrong and sometimes fluctuate (between 1%; 20% and 55%).
> Currently the battery is almost full (thanks to the LEDs on the mouse) and
> the battery level only indicates 20%.

The Performance MX uses the HID++ 1.0 protocol for reading the battery level from a register. Is the displayed battery percentage always from a fixed set of numbers? Does the number jump upwards and downwards all the time, or is it decreasing over time?

Can you verify the battery level with Solaar?