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