From: bugzilla-daemon@kernel.org
To: platform-driver-x86@vger.kernel.org
Subject: [Bug 215531] Lenovo charge limit feature stops 1% short of the configured limit and says it's still charging
Date: Mon, 14 Feb 2022 20:02:58 +0000 [thread overview]
Message-ID: <bug-215531-215701-QyvyX20HwF@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-215531-215701@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=215531
--- Comment #3 from Hans de Goede (jwrdegoede@fedoraproject.org) ---
(In reply to Nate Graham from comment #2)
> > the capacity in % being more or less equal to the
> > charge_control_end_threshold(1) value
>
> Does this mean that expect userspace software to say, "79% is close enough
> to 80%, consider them equal"?
If necessary, yes. It also depends where the 79% is coming from.
On my X1 carbon gen 8, there is both a "capacity" file as well as "energy_now"
and "energy_full" files under /sys/class/power_supply/BAT0. IIRC upower prefers
the "energy_now" and "energy_full" files and then calculates a % based on these
itself.
It is possible that when the system stops charging
/sys/class/power_supply/BAT0/capacity actually is 80% where as the calculation
of the % from:
energy_now * 100 / energy_full
Results in 79% especially if that divide is down without rounding the result to
the nearest whole percent (by default integer division in C rounds down).
So it might be better if for the "full" because of hitting the charge threshold
case the check uses /sys/class/power_supply/BAT0/capacity rather then
energy_now, this will all need to be tested as this gets implemented and will
likely need some more tweaking while the feature has just landed.
Things like the above example can all lead to things looking to be 1% or
sometimes even 2% of, so yes userspace will be expected to fuzz things a bit
here if necessary.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
next prev parent reply other threads:[~2022-02-14 21:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-215531-215701@https.bugzilla.kernel.org/>
2022-02-14 6:42 ` [Bug 215531] Lenovo charge limit feature stops 1% short of the configured limit and says it's still charging bugzilla-daemon
2022-02-14 9:41 ` bugzilla-daemon
2022-02-14 18:30 ` bugzilla-daemon
2022-02-14 20:02 ` bugzilla-daemon [this message]
2022-02-14 20:11 ` bugzilla-daemon
2022-02-14 20:17 ` bugzilla-daemon
2022-02-14 21:17 ` bugzilla-daemon
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=bug-215531-215701-QyvyX20HwF@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--cc=platform-driver-x86@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.