Hey,
I have recently bought a Logitech Marathon Mouse/Performance Plus M705,
and I ended up with 2 power_supply class batteries for it when it was
turned off already when using kernel 5.9.13.
Using a newer kernel (5.11-rc2), the power_supply class device doesn't
disappear either:
P: /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.2/0003:046D:C52B.0005/0003:046D:406D.0008/power_supply/hidpp_battery_2
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.2/0003:046D:C52B.0005/0003:046D:406D.0008/power_supply/hidpp_battery_2
E: SUBSYSTEM=power_supply
E: POWER_SUPPLY_NAME=hidpp_battery_2
E: POWER_SUPPLY_TYPE=Battery
E: POWER_SUPPLY_ONLINE=0
E: POWER_SUPPLY_STATUS=Unknown
E: POWER_SUPPLY_SCOPE=Device
E: POWER_SUPPLY_MODEL_NAME=Marathon Mouse/Performance Plus M705
E: POWER_SUPPLY_MANUFACTURER=Logitech
E: POWER_SUPPLY_SERIAL_NUMBER=406d-b1-4d-65-da
E: POWER_SUPPLY_CAPACITY_LEVEL=Unknown
But the "online" state changes, which upower doesn't handle at all for
device power (as opposed to system power).
Is the fact that the power_supply device doesn't disappear a known
problem? I'll look into the upower problem soon.
Cheers
On Fri, 2021-01-08 at 12:42 +0100, Bastien Nocera wrote:
On Fri, 2021-01-08 at 12:23 +0100, Bastien Nocera wrote:
quoted
Hey,
I have recently bought a Logitech Marathon Mouse/Performance Plus
M705,
and I ended up with 2 power_supply class batteries for it when it
was
turned off already when using kernel 5.9.13.
Using a newer kernel (5.11-rc2), the power_supply class device
doesn't
disappear either:
<snip>
I'll look into the upower problem soon.
Filed as:
https://gitlab.freedesktop.org/upower/upower/-/issues/134
I actually don't think this is a bug. The docs for "online" mention:
"
Indicates if VBUS is present for the supply. When the supply is
online, and the supply allows it, then it's possible to switch
between online states (e.g. Fixed -> Programmable for a PD_PPS
USB supply so voltage and current can be controlled).
"
So this isn't really something we can use to signal that a device is
plugged in or not.
And the docs for "present" say:
"
Reports whether a battery is present or not in the system.
"
Well, that would mean that the device is there, but no battery is
present. eg. an XBox joypad without batteries but plugged in to the
system via USB.
Looks like a bug in the hidpp kernel code. This is what "solaar show"
shows for the device:
"
3: Marathon Mouse M705 (M-R0073)
Device path : /dev/hidraw4
WPID : 406D
Codename : M705 (M-R0073)
Kind : mouse
Protocol : HID++ 4.5
Polling rate : 8 ms (125Hz)
Serial number: B14D65DA
The power switch is located on the base.
Battery: unknown (device is offline).
"
Cheers
On Fri, 2021-01-08 at 12:23 +0100, Bastien Nocera wrote:
Hey,
I have recently bought a Logitech Marathon Mouse/Performance Plus
M705,
and I ended up with 2 power_supply class batteries for it when it was
turned off already when using kernel 5.9.13.
Using a newer kernel (5.11-rc2), the power_supply class device
doesn't
disappear either:
<snip>
I'll look into the upower problem soon.
Filed as:
https://gitlab.freedesktop.org/upower/upower/-/issues/134