* [REGRESSION] - Multiple userspace implementations of battery estimate broken after "ACPI: battery: negate current when discharging"
@ 2025-07-03 1:54 Matthew Schwartz
2025-07-03 10:58 ` Rafael J. Wysocki
2025-07-03 14:47 ` Hans de Goede
0 siblings, 2 replies; 7+ messages in thread
From: Matthew Schwartz @ 2025-07-03 1:54 UTC (permalink / raw)
To: pmarheine; +Cc: regressions, stable, rafael.j.wysocki, linux-acpi
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.
Thanks,
Matthew Schwartz
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [REGRESSION] - Multiple userspace implementations of battery estimate broken after "ACPI: battery: negate current when discharging"
2025-07-03 1:54 [REGRESSION] - Multiple userspace implementations of battery estimate broken after "ACPI: battery: negate current when discharging" Matthew Schwartz
@ 2025-07-03 10:58 ` Rafael J. Wysocki
2025-07-03 14:47 ` Hans de Goede
1 sibling, 0 replies; 7+ messages in thread
From: Rafael J. Wysocki @ 2025-07-03 10:58 UTC (permalink / raw)
To: Matthew Schwartz
Cc: pmarheine, regressions, stable, rafael.j.wysocki, linux-acpi
Hi,
On Thu, Jul 3, 2025 at 3:55 AM Matthew Schwartz
<matthew.schwartz@linux.dev> 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.
Thanks for letting me know, I'm queuing up a revert of this one.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [REGRESSION] - Multiple userspace implementations of battery estimate broken after "ACPI: battery: negate current when discharging"
2025-07-03 1:54 [REGRESSION] - Multiple userspace implementations of battery estimate broken after "ACPI: battery: negate current when discharging" Matthew Schwartz
2025-07-03 10:58 ` Rafael J. Wysocki
@ 2025-07-03 14:47 ` Hans de Goede
2025-07-03 15:51 ` Matthew Schwartz
2025-07-04 4:56 ` Peter Marheine
1 sibling, 2 replies; 7+ messages in thread
From: Hans de Goede @ 2025-07-03 14:47 UTC (permalink / raw)
To: Matthew Schwartz, pmarheine, Sebastian Reichel
Cc: regressions, stable, rafael.j.wysocki, linux-acpi
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?
Regards,
Hans
1) For directly accessing fuel-gauge chips on devices where these
are directly accessible instead of being exposed through ACPI
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [REGRESSION] - Multiple userspace implementations of battery estimate broken after "ACPI: battery: negate current when discharging"
2025-07-03 14:47 ` Hans de Goede
@ 2025-07-03 15:51 ` Matthew Schwartz
2025-07-06 22:27 ` Sebastian Reichel
2025-07-04 4:56 ` Peter Marheine
1 sibling, 1 reply; 7+ messages in thread
From: Matthew Schwartz @ 2025-07-03 15:51 UTC (permalink / raw)
To: Hans de Goede
Cc: pmarheine, Sebastian Reichel, regressions, stable,
rafael.j.wysocki, linux-acpi
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [REGRESSION] - Multiple userspace implementations of battery estimate broken after "ACPI: battery: negate current when discharging"
2025-07-03 14:47 ` Hans de Goede
2025-07-03 15:51 ` Matthew Schwartz
@ 2025-07-04 4:56 ` Peter Marheine
2025-07-04 8:47 ` Hans de Goede
1 sibling, 1 reply; 7+ messages in thread
From: Peter Marheine @ 2025-07-04 4:56 UTC (permalink / raw)
To: Hans de Goede
Cc: Matthew Schwartz, pmarheine, Sebastian Reichel, regressions,
stable, rafael.j.wysocki, linux-acpi
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [REGRESSION] - Multiple userspace implementations of battery estimate broken after "ACPI: battery: negate current when discharging"
2025-07-04 4:56 ` Peter Marheine
@ 2025-07-04 8:47 ` Hans de Goede
0 siblings, 0 replies; 7+ messages in thread
From: Hans de Goede @ 2025-07-04 8:47 UTC (permalink / raw)
To: Peter Marheine
Cc: Matthew Schwartz, Sebastian Reichel, regressions, stable,
rafael.j.wysocki, linux-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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [REGRESSION] - Multiple userspace implementations of battery estimate broken after "ACPI: battery: negate current when discharging"
2025-07-03 15:51 ` Matthew Schwartz
@ 2025-07-06 22:27 ` Sebastian Reichel
0 siblings, 0 replies; 7+ messages in thread
From: Sebastian Reichel @ 2025-07-06 22:27 UTC (permalink / raw)
To: Matthew Schwartz
Cc: Hans de Goede, pmarheine, regressions, stable, rafael.j.wysocki,
linux-acpi
[-- Attachment #1: Type: text/plain, Size: 2490 bytes --]
Hi,
On Thu, Jul 03, 2025 at 08:51:10AM -0700, Matthew Schwartz wrote:
> > 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.
I also asked the Collabora team supporting Valve with the Steamdeck
to look into it. So I hope that it will be fixed soon :)
Thanks for coordinating this Hans. I fully agree with your analysis
and middle term plans to revert the revert :)
Greetings,
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2025-07-06 22:27 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-03 1:54 [REGRESSION] - Multiple userspace implementations of battery estimate broken after "ACPI: battery: negate current when discharging" Matthew Schwartz
2025-07-03 10:58 ` Rafael J. Wysocki
2025-07-03 14:47 ` Hans de Goede
2025-07-03 15:51 ` Matthew Schwartz
2025-07-06 22:27 ` Sebastian Reichel
2025-07-04 4:56 ` Peter Marheine
2025-07-04 8:47 ` Hans de Goede
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox