find_battery_device() returns the first entry under /sys/class/power_supply whose type reads Battery. Wireless mice, keyboards and headsets register power supplies of that same type, and fs::read_dir yields entries in filesystem order, so whichever device the kernel registered first wins.
On my machine the battery button shows my mouse:
| device |
scope |
capacity |
hidpp_battery_7 (Logitech MX Anywhere 3) |
Device |
60% |
macsmc-battery |
System |
80% |
readdir puts hidpp_battery_7 first, so the button reads 60%. The result also isn't stable across restarts: the device is picked once at config load and kept for the lifetime of the daemon, so it depends on whether the mouse happened to be connected when tiny-dfr started.
There is a second effect. A mouse reports Discharging essentially all the time, so once its charge drops below 10% the button turns red through BatteryState::Low, as if the laptop were about to die.
The kernel distinguishes these with the scope attribute (System / Device / Unknown); peripherals report Device. Skipping Device-scoped supplies and preferring System fixes it. A missing scope file should stay acceptable, since not every driver exposes the attribute — on machines where it is absent, rejecting those supplies would regress the button to "Battery N/A".
I have this working on a branch of my fork, if it's useful as a starting point:
schotek@920b5dc
It skips Device-scoped supplies, prefers System, and sorts the remaining candidates by name so the choice is stable across boots. Tested on the machine below (button switches from the mouse's 60% to the laptop's 80%), plus synthetic /sys/class/power_supply trees covering a missing scope file, scope = Unknown, two system batteries, peripheral-only, and no battery at all. Take it in whatever form suits you, or ignore it entirely — I'm reporting the bug either way.
Disclosure: that patch was written with AI assistance; I reviewed and tested it on my own hardware. I'm aware of the repository's policy on automated contributions, which is why this is an issue with a link rather than a pull request.
Environment: Apple MacBook Pro (13-inch, M1, 2020), Fedora Linux Asahi Remix 44, kernel 7.1.6-400.asahi.fc44.aarch64+16k, tiny-dfr 0.3.7.
find_battery_device()returns the first entry under/sys/class/power_supplywhosetypereadsBattery. Wireless mice, keyboards and headsets register power supplies of that same type, andfs::read_diryields entries in filesystem order, so whichever device the kernel registered first wins.On my machine the battery button shows my mouse:
hidpp_battery_7(Logitech MX Anywhere 3)Devicemacsmc-batterySystemreaddirputshidpp_battery_7first, so the button reads 60%. The result also isn't stable across restarts: the device is picked once at config load and kept for the lifetime of the daemon, so it depends on whether the mouse happened to be connected when tiny-dfr started.There is a second effect. A mouse reports
Dischargingessentially all the time, so once its charge drops below 10% the button turns red throughBatteryState::Low, as if the laptop were about to die.The kernel distinguishes these with the
scopeattribute (System/Device/Unknown); peripherals reportDevice. SkippingDevice-scoped supplies and preferringSystemfixes it. A missingscopefile should stay acceptable, since not every driver exposes the attribute — on machines where it is absent, rejecting those supplies would regress the button to "Battery N/A".I have this working on a branch of my fork, if it's useful as a starting point:
schotek@920b5dc
It skips
Device-scoped supplies, prefersSystem, and sorts the remaining candidates by name so the choice is stable across boots. Tested on the machine below (button switches from the mouse's 60% to the laptop's 80%), plus synthetic/sys/class/power_supplytrees covering a missingscopefile,scope = Unknown, two system batteries, peripheral-only, and no battery at all. Take it in whatever form suits you, or ignore it entirely — I'm reporting the bug either way.Disclosure: that patch was written with AI assistance; I reviewed and tested it on my own hardware. I'm aware of the repository's policy on automated contributions, which is why this is an issue with a link rather than a pull request.
Environment: Apple MacBook Pro (13-inch, M1, 2020), Fedora Linux Asahi Remix 44, kernel 7.1.6-400.asahi.fc44.aarch64+16k, tiny-dfr 0.3.7.