Fwupd killing Logitech peripheral battery life by sending commands every 30 seconds

[rishabh-chromium]

Describe the bug
When an Logitech USB receiver is attached, fwupd sends signals every 30 seconds that is then sent to the peripheral that wakes up the peripheral device from sleep mode reducing the battery life of the peripheral from 14 months to 6 months.

Steps to Reproduce
Logitech peripheral paired with its Logitech Bolt USB receiver https://www.logitech.com/en-us/products/mice/logi-bolt-usb-receiver.956-000007.html

1. power on the peripheral
2. plug the USB receiver into the device: issue is not present
3. unplug/replug the receiver

Expected Results: The device should not send superfluous commands to the USB receiver, especially none that the receiver is supposed to forward to the peripheral. This way the peripheral can enter and remain in sleep mode.

Actual Results: Every 30 seconds, Fwupd sends commands via USB to the receiver which are intended for the peripheral. The receiver forwards those commands to the peripheral via RF. The peripheral wakes up and acknowledges those commands, then goes back to sleep. The receiver acknowledges the command to the Device via USB.

Observed with the following receivers: https://www.logitech.com/en-us/products/mice/logi-bolt-usb-receiver.956-000007.html i.e., VID = 0x046D (Logitech) / PID = 0xC548

firmware MPR05.01_B0010
firmware MPR05.02_B0016
Observed with the following peripherals: https://www.logitech.com/en-us/products/keyboards/mx-mechanical.htm

fwupd version information
1.9.10

IMP Notes

usbmon I saw this traffic repeated periodically:

ffff9feeb4fa86c0 999003472 S Co:014:00 s 21 09 0210 0002 0007 7 = 10020017 0000aa
ffff9feeb4fa86c0 999003975 C Co:014:00 0 7 >
ffff9fee84a60d80 999902027 C Ii:014:03 0 20 = 11020017 0405aa00 00000000 00000000 00000000
ffff9fee84a60d80 999902069 S Ii:014:03 -115 20 <

This looks very close to the fu_logitech_hidpp_device_ping message which is called when fwupd polls logitech devices

• Operating system and version: ChromeOS

[hughsie]

So there's certainly something funky going on here. I think the best thing to do is to work out why we're not getting the hotplug events in some cases, and then completely skip polling. When we put together the bolt code in fwupd it was before the kernel hidpp stuff landed and so some of the assumptions we had then may no longer be valid. I suspect we can make things a bit simpler too. If anyone wants to work on this please be my guest, but I'll not be back until the 15th.

[superm1]

I do wonder if this is part of the reason for https://gitlab.freedesktop.org/upower/upower/-/issues/256 as well.

[superm1]

Yup, @smallorange did confirm that masking fwupd no unknown events are received by power anymore for the Logitech device.

[rishabh-chromium]

Is this good to close then or is work still required here, @hughsie?

[superm1]

There is definitely work to be done.

[hughsie]

We can kill the polling for Unifying (as in #7204) but for bolt devices there are no kernel events when devices "come and go" -- this means if you pair a new mouse we don't notice until you reboot the computer. If you turn off the mouse, we'll show it as active (and upgradable) until you reboot again.

We're registering for Wireless + SoftwarePresent which may be overkill.

[superm1]

For bolt behavior you say I don't know it's that big of a deal.

The reason being we have the daemon auto quit. Are clients really checking in often enough that the update would never be found because daemon kept alive?

If so; how about the polling is like 10 minutes, or 30 minutes?

[superm1]

Or maybe just when there is a get devices or get updates call the daemon does the ping then?