On Sat, Feb 15, 2025 at 04:08:25AM +0100, Sebastian Reichel wrote: > > 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 Sebastian, Thanks a lot for the detailed answer, that makes sense for me. I was sending this patch more to know which direction to follow (changing the driver or the userspace tools), and you answered it perfectly. I started fixing the different desktop tools I use, starting with Waybar: https://github.com/Alexays/Waybar/pull/3942 For powertop, the fix seems straightforward. For acpiclient, due to no activity in almost 10 years, we'll see if it goes through. -- Thanks, Anthony Ruhier
