On Sat, Feb 15, 2025 at 04:08:25AM +0100, Sebastian Reichel wrote: > Hi, > > There are other drivers reporting negative values as documented. > Most of the embedded ones do this actually and there surely are > (embedded) userspace programs relying on this by now. But the > most used driver - generic ACPI battery - does not. That's why > quite a few userspace tools handle it wrong without anyone > noticing for quite some time. Fixing it to follow the ABI would > obviously end up in a bunch of regression reports, so things are > a bit messy :( > > > I think it is a problem of the 'acpi' tool. At least 'upower -d' uses > > fabs internally since the initial commit in 2008. > > It's definitely sensible to fix the userspace tools. We can't change > the documented ABI for current_now after that many years and while > documentation for power_now is missing, it would be quite unexpected > to have it behave differently than current_now. Also userspace > tooling needs to handle current_now and power_now anyways. And we > surely can't change the behaviour for all drivers reporting signed > data. So let's keep qcom_battmgr as is. It follows the documented > ABI and hopefully helps giving this more exposure (I'm typing this > on a X1E laptop right now and can see your problem with waybar). > > But we should document the power_now property. It somehow fell > through the cracks :) > > -- Sebastian Hi, As an update around this topic, I sent some patches in the different tools I'm using to correctly handle negative values in current_now and power_now: * Waybar (included in release 0.12.0): https://github.com/Alexays/Waybar/pull/3942 * Powertop (merged): https://github.com/fenrus75/powertop/pull/173 * acpi-client (included in release 1.8): https://sourceforge.net/p/acpiclient/code/merge-requests/1/ It was quicker to get this merged than what I expected, which is good news! There's probably other tools to fix, I just fixed the tools I'm using. I encounter the issue on other tools, I'll send a patch. -- Anthony Ruhier
