From: Hans de Goede <hansg@kernel.org>
To: Matthew Schwartz <matthew.schwartz@linux.dev>,
pmarheine@chromium.org, Sebastian Reichel <sre@kernel.org>
Cc: regressions@lists.linux.dev, stable@vger.kernel.org,
rafael.j.wysocki@intel.com, linux-acpi@vger.kernel.org
Subject: Re: [REGRESSION] - Multiple userspace implementations of battery estimate broken after "ACPI: battery: negate current when discharging"
Date: Thu, 3 Jul 2025 16:47:47 +0200 [thread overview]
Message-ID: <84dfa466-d201-4a51-8794-6c64568bec95@kernel.org> (raw)
In-Reply-To: <87C1B2AF-D430-4568-B620-14B941A8ABA4@linux.dev>
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
next prev parent reply other threads:[~2025-07-03 14:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84dfa466-d201-4a51-8794-6c64568bec95@kernel.org \
--to=hansg@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=matthew.schwartz@linux.dev \
--cc=pmarheine@chromium.org \
--cc=rafael.j.wysocki@intel.com \
--cc=regressions@lists.linux.dev \
--cc=sre@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox