On Jul 3, 2025, at 7:47 AM, Hans de Goede hansg@kernel.org wrote:

Hi Matthew,

...

On 3-Jul-25 3:54 AM, Matthew Schwartz wrote: Hello,

I installed kernel 6.15.4 to find that my battery estimate on my handheld gaming device was completely inaccurate, instead giving negative values and an unknown estimated battery life in multiple places.

After bisecting, I landed on "ACPI: battery: negate current when discharging” as the bad commit. This commit breaks not one but several userspace implementations of battery monitoring: Steam and MangoHud. Perhaps it breaks more, but those are the two I have noticed so far.

Thank you for reporting this.

As Rafael already indicated this patch will need to be reverted to unbreak userspace.

But, the patch was actually doing the right thing, according to:

Documentation/ABI/testing/sysfs-class-power

What: /sys/class/power_supply/<supply_name>/current_avg Date: May 2007 Contact: linux-pm@vger.kernel.org Description: Battery: ... Access: Read

           Valid values: Represented in microamps. Negative values are
           used for discharging batteries, positive values for charging
           batteries and for USB IBUS current.

(and the same for current_now)

and there are many power_supply fuel-gauge drivers (1) under drivers/power/supply/ which do adhere to this specification and report a negative current for discharging.

So if any of the userspace consumers of this API you mention were to run on hw with these drivers the same problem will be hit. Can you please file bugs against these userspace projects so that they can fix this?

Sure, I filed a bug with MangoHud last night about the kernel change breaking the current battery logic so I will mention this concern when updating that issue, and I will also file a new bug with Steam.

Thanks, Matt

Regards,

Hans

1. For directly accessing fuel-gauge chips on devices where these

are directly accessible instead of being exposed through ACPI

Hi Peter,

On 4-Jul-25 6:56 AM, Peter Marheine wrote:

I'm not surprised that there exist a number of userspace programs that assume the buggy ACPI battery behavior is the only one, but this does leave us in the previous situation where there's a clear bug in the ACPI driver.

...

But, the patch was actually doing the right thing, according to:

Documentation/ABI/testing/sysfs-class-power

This is the key issue, since it's entirely plausible for a program assuming non-negative battery current to run on a non-ACPI platform and misbehave in the same way. If we're not going to fix the ACPI driver to behave as specified for the kernel ABI, then the ABI needs to be redefined to reflect the actual behavior. It's either that or we give userspace an opportunity to fix itself (and I'm not sure exactly how that would be done such that the clients which need to be fixed discover that they need to be) and correct the driver's behavior later.

Right, this is why I asked for bugs to be filed against the problematic userspace programs, so that we can try to fix the ACPI driver again in say 1 or 2 years from now.

In the mean time you could submit a patch to document the known broken behavior of the ACPI battery driver in:

Documentation/ABI/testing/sysfs-class-power

with a big warning that userspace should not rely on this behavior.

You could even document how to work around this, e.g.:

"Negative currents are always discharging. Because of the broken ACPI battery driver behaviour positive currents should be seen as discharging rather then charging when the "status" sysfs attribute reports discharging."

Regards,

Hans