Power management baterry level does not fill up the bar

I have wireless mouse that gets charged via USB cable.

Here is screenshot from Plasma 5.27.5 on Debian 12 bookworm where I access this menu:

And here is screenshot when I click on that icon:

What’s the problem?

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.

this reads like a bug

you could try just logging out instead of rebooting which is much of a disruption.

you can even try just refreshing the plasmashell by using this command in console

systemctl restart --user plasma-plasmashell.service

1 Like

Thank you for possible solution, I’m going to wait until my mouse discharges to test this and will report back.

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
1 Like

Thank you for suggestion, however this tools seems to be useful for laptops, at least according to debian package details:

The primary target audience are laptop users

Here is output of the command, it doesn’t recognize mouse battery, this option is for laptop battery:

acpitool -B
  Battery #1     : slot empty

But I’m glad to learn about it!

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

I just tested this but unfortunately neither logout nor the command updates the charge bar.

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)

1 Like

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

What do you think is the problem?

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.

1 Like

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.

1 Like

I installed solaar but my mouse is not listed in the UI, I’m now troubleshooting this, looks like I’m missing some modules, will see.

Bluetooth service is disabled, thanks for hint!

I’ll let you know what I come up with.

It should indicate that is charging, which Solaar is able to do.

Just checked again and it went from 80% to 85% so at least on my device the battery is being reported correctly

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

Enabling Experimental bluetooth feature didn’t help.

lsmod | grep logi

hid_logitech_dj        40960  0
hid_logitech_hidpp     69632  0
usbhid                 77824  2 hid_logitech_dj,hid_logitech_hidpp
hid                   253952  4 usbhid,hid_generic,hid_logitech_dj,hid_logitech_hidpp
usbcore               401408  8 xhci_hcd,usbhid,rtl_usb,btmtk,rtl8192cu,btusb,xhci_pci,hid_logitech_hidpp

Sadly my mouse is not recognized.

Did you have any luck with Solaar? According to this issue Logitech g703 battery not detected/ unknown in GUI (feature BATTERY_VOLTAGE) · Issue #570 · pwr-Solaar/Solaar · GitHub it should work.

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 the battery status/level is reported correctly in Solaar?

Is the upower reading is still the same after enabling the bluetooth service?

I’m charging right now, can’t say yet until I see the percentage go up, will report soon.

Yes it does work this time while charging:

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. 20:53:40 CET (21 seconds ago)
  has history:          yes
  has statistics:       yes
  keyboard
    present:             yes
    rechargeable:        yes
    state:               charging
    warning-level:       none
    percentage:          91%
    icon-name:          'battery-full-charging-symbolic'

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.