The charge bar does not fill up while the mouse is charging, it stays at same charge level (10% in this example) and it stays so until I reboot.
Only system reboot will show updated charge bar level.
Do I miss some package as to why charge level bar isn’t filling up or is it a bug?
When I reboot system after some 1 hour the charge bar gets filled to 100%, but it does not fill up while system is running as if the battery is not charging which is false.
If you want an independent battery interface to get what the charge level is to compare to the one shown on the gui bar you can install “acpitool” and run:
acpitool -B
I’m on Fedora 42 Beta so that depends on whether Debian packages that.
For an example, my laptop shows:
acpitool -B
Battery #1 : present
Remaining capacity : unknown, 85.93%, 00:00:00
Design capacity : 4500 mA
Last full capacity : 3873 mA, 86.07% of design capacity
Capacity loss : 13.93%
Present rate : 765 mA
Charging state : Discharging
Battery type : Li-ion
Model number : MS-16WK
Ah, sorry, the GUI clip was chopped off and I thought the "G703 LIGHTSPEED. … " etc etc was a laptop battery. I never use rechargeable mice or rechargeable anything other than the laptop itself
How are you connecting the mouse to the computer, USB dongle or Bluetooth? I suppose it’s the second because AFAIK there is no driver to get the battery level when connected with a dongle, at least not for the MX Anywhere 3s that I have.
If you run upower -d does it return the same incorrect value? If it does this may indicate a compatibility problem specific to that device.
I can’t use my device for comparison because I always have it connected with a dongle and instead use Solaar to monitor the battery of the mouse and keyboard (G915 TKL)
I’m using bluetooth to use the mouse normally and when needing to charge it, I connect it to USB cable.
This is output when it’s not charging (bluetooth)
upower -i /org/freedesktop/UPower/devices/battery_hidpp_battery_1
native-path: hidpp_battery_1
model: G703 LIGHTSPEED Wireless Gaming Mouse w/ HERO
serial: d5-2b-79-a8
power supply: no
updated: 29. Mar 2025. 19:47:43 CET (18 seconds ago)
has history: yes
has statistics: yes
mouse
present: yes
rechargeable: yes
state: discharging
warning-level: none
percentage: 85%
icon-name: 'battery-full-symbolic'
This is output when it’s charging (USB)
upower -i /org/freedesktop/UPower/devices/battery_hidpp_battery_1
native-path: (null)
power supply: no
updated: 01. Jan 1970. 01:00:00 CET (1743274316 seconds ago)
has history: no
has statistics: no
unknown
warning-level: unknown
battery-level: unknown
percentage: 0% (should be ignored)
icon-name: '(null)'
When it’s charging via USB as you can see it says 0% which is incorrect.
However it reports correct value when not charging (using via bluetooth)
Also repoted date is incorrect when connected to USB, it says Jan. 1970
When it’s charging via USB as you can see it says 0% which is incorrect.
Is the communication still made over Bluetooth when charging or does it switch to USB? With the MX Anywhere 3S the connection still goes over Bluetooth and upower reports incorrect information too
Device: /org/freedesktop/UPower/devices/mouse_dev_D1_29_22_08_E0_11
native-path: /org/bluez/hci0/dev_D1_29_22_08_E0_11
model: MX Anywhere 3S
serial: D1:29:22:08:E0:11
power supply: no
updated: Sat 29 Mar 2025 12:32:05 PM CST (2124 seconds ago)
has history: yes
has statistics: no
mouse
present: yes
rechargeable: no
state: unknown
warning-level: none
percentage: 80%
icon-name: 'battery-missing-symbolic'
It should indicate that is charging, which Solaar is able to do.
To me it looks like a problem with the device not reporting the correct status correctly or it not being fully supported by bluez, the bluetooth stack.
You could also try enabling experimental Bluetooth features to see if that improves the situation, I have them enabled as I needed them for some cheap Bluetooth headphones that I no longer have, but never disabled them
I installed it from Debian backports.
I also did modprobe logitech drivers as per manuals, didn’t work right away but now I rebooted system and my mouse got recognized!
Thank you so much for help, it’s much appreciated!
So it looks like you don’t need Solaar now for the battery reporting at least.
If upower and Plasma now report correct readings I suggest temporarily removing Solaar and the bluez experimental features.
If it still works then it means you only needed to enable the service, if it stops working then enable the experimental features and check again if the problem is solved. If it doesn’t and you still need Solaar it could mean it is doing something to the device to make it report the correct readings.
Once you are sure what exactly was needed please make a new comment stating what you did and mark it as the solution.