Repository: pwr-Solaar/Solaar

Issue:
Solaar uses 100% of one logical CPU
**Information**
<!-- Make sure that your issue is not one of the known issues in the Solaar documentation at https://pwr-solaar.github.io/Solaar/ -->
<!-- Do not bother opening an issue for a version older than 1.0.6.  Please update to the latest version and see if your issue persists. -->
- Solaar version (`solaar --version` or `git describe --tags` if cloned from this repository): solaar 1.0.6
- Distribution: Fedora 34
- Kernel version (ex. `uname -srmo`): `Linux 5.13.12-200.fc34.x86_64 x86_64 GNU/Linux`
- Output of `solaar show`:

<details>

```
Nano Receiver
  Device path  : /dev/hidraw1
  USB id       : 046d:C534
  Serial       : None
    Firmware   : 29.01.B0016
  Has 1 paired device(s) out of a maximum of 2.
  Has 19 successful pairing(s) remaining.
  Notifications: wireless, software present (0x000900)

  2: Wireless Mouse M185 new
     Device path  : /dev/hidraw4
     WPID         : 4054
     Codename     : M185n
     Kind         : mouse
     Protocol     : HID++ 4.5
     Polling rate : 8 ms (125Hz)
     Serial number: E01641EF
     Model ID:      000000000000
     Unit ID:       00000000
          Firmware: RQM 64.00.B0008
     The power switch is located on the base.
     Supports 20 HID++ 2.0 features:
         0: ROOT                   {0000}   
         1: FEATURE SET            {0001}   
         2: DEVICE FW VERSION      {0003}   
            Firmware: Firmware RQM 64.00.B0008 4054
            Unit ID: 00000000  Model ID: 000000000000  Transport IDs: {}
         3: DEVICE NAME            {0005}   
            Name: Wireless Mouse  
            Kind: mouse
         4: RESET                  {0020}   
         5: REPROG CONTROLS V4     {1B04}   
            Key/Button Actions (saved): {'80': 80, '81': 81, '82': 82}
            Key/Button Actions        : {'80': 80, '81': 81, '82': 82}
         6: WIRELESS DEVICE STATUS {1D4B}   
         7: LOWRES WHEEL           {2130}   
            Wheel Reports: HID
            Scroll Wheel HID++ Scrolling (saved): False
            Scroll Wheel HID++ Scrolling        : False
         8: POINTER SPEED          {2205}   
            Pointer Speed: 1.0
            Sensitivity (Pointer Speed) (saved): 256
            Sensitivity (Pointer Speed)        : 256
         9: DEVICE RESET           {1802}   internal, hidden
        10: unknown:1810           {1810}   internal, hidden
        11: unknown:1830           {1830}   internal, hidden
        12: unknown:1850           {1850}   internal, hidden
        13: unknown:1869           {1869}   internal, hidden
        14: unknown:1890           {1890}   internal, hidden
        15: unknown:18B1           {18B1}   internal, hidden
        16: unknown:1DF3           {1DF3}   internal, hidden
        17: unknown:1E00           {1E00}   hidden
        18: unknown:1F03           {1F03}   internal, hidden
        19: unknown:1E80           {1E80}   internal, hidden
     Has 3 reprogrammable keys:
         0: Left Button               , default: Left Click                  => Left Click                
             mse, reprogrammable, pos:0, group:1, group mask:g1
             reporting: default
         1: Right Button              , default: Right Click                 => Right Click               
             mse, reprogrammable, pos:0, group:1, group mask:g1
             reporting: default
         2: Middle Button             , default: Mouse Middle Button         => Mouse Middle Button       
             mse, reprogrammable, divertable, raw XY, pos:0, group:2, group mask:g1,g2
             reporting: default
     Battery status unavailable.
```
</details>

**Describe the bug**
Likely the same problem with https://github.com/pwr-Solaar/Solaar/issues/99. After sometime, `solaar` uses one core of the CPU 90-100% and never stops. Replugging does not work.

**To Reproduce**
Steps to reproduce the behavior:
1. Open `solaar`
2. Wait for a uncertain time

**Screenshots**
If applicable, add screenshots to help explain your problem.
![solaar](https://user-images.githubusercontent.com/29679552/131417767-2ddcc052-ab01-47c5-bc6a-0c490bd2580c.png)


**Additional context**
Add any other context about the problem here.



Discussion:
Bug #99 is very old so it is not certain that this is the same bug.

It would be helpful if you could trigger a backtrace to show where Solaar is when it is consuming CPU.    Run Solaar as `solaar -d` from a terminal (after quitting any running Solaar).  Enter control-C when Solaar is consuming CPU.  It make take a few times to pinpoint what is going wrong.


Also, does Solaar continue to consume CPU if all Logitech devices are turned off or unplugged?
Bug #833 is the closest one, but I thought that it had been solved.
> Also, does Solaar continue to consume CPU if all Logitech devices are turned off or unplugged?

Yes, unplugging or turning off didn’t affect the CPU usage. Will share the traces as soon as I encounter the problem again. Thanks for your interest!
It started to do like that with `solaar -dd`:
[solaar-log1.txt](https://github.com/pwr-Solaar/Solaar/files/7080307/solaar-log1.txt)

OK, I see that Solaar is in a loop thinking that the mouse status is changing.  But I'm not sure why.  The output from just before the loop might be useful.  Also what trigger the loop - were you working with the mouse - was the computer resuming from suspend - had the mouse been unused for a while?

I have the same hardware and I'm not seeing the looping.
[solaar-log2.txt](https://github.com/pwr-Solaar/Solaar/files/7082513/solaar-log2.txt)
It's happening after waiting for a time while the mouse is unused. Simply I locked the laptop with CTRL-L in GNOME (not suspending) and went to sleep. Then I unlocked, moved the mouse and that happened. I'm going to try replugging the receiver while debugging and pass the output there.
I just reproduced the problem so I should be able to investigate it.  It seems to be #833 again, which I thought was fixed.  On resume from suspend there is some loop condition.
Perfect! Also want to add that I use TLP with `USB_AUTOSUSPEND=1`.  It may work for you. Waiting for a custom build then.

Resolving patch:
diff --git a/lib/logitech_receiver/status.py b/lib/logitech_receiver/status.py
--- a/lib/logitech_receiver/status.py
+++ b/lib/logitech_receiver/status.py
@@ -272,7 +272,7 @@ def set_battery_keys(self, battery, voltage=None):
         if battery is not None:
             level, status, nextLevel = battery
             self.set_battery_info(level, status, nextLevel, voltage)
-        elif KEYS.BATTERY_STATUS in self:
+        elif self.get(KEYS.BATTERY_STATUS, None) is not None:
             self[KEYS.BATTERY_STATUS] = None
             self[KEYS.BATTERY_CHARGING] = None
             self[KEYS.BATTERY_VOLTAGE] = None


Test patch: