[Bug 215531] Lenovo charge limit feature stops 1% short of the configured limit and says it's still charging

[Bug 215531] Lenovo charge limit feature stops 1% short of the configured limit and says it's still charging

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215531

Zhang Rui (rui.zhang@intel.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rui.zhang@intel.com
          Component|Other                       |Platform_x86
           Hardware|x86-64                      |All
           Assignee|rjw@rjwysocki.net           |drivers_platform_x86@kernel
                   |                            |-bugs.osdl.org
            Product|Power Management            |Drivers

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215531] Lenovo charge limit feature stops 1% short of the configured limit and says it's still charging

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215531

Hans de Goede (jwrdegoede@fedoraproject.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |jwrdegoede@fedoraproject.or
                   |                            |g
         Resolution|---                         |CODE_FIX

--- Comment #1 from Hans de Goede (jwrdegoede@fedoraproject.org) ---
This has been fixed in kernels >= 5.16.3 with this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e96c1197aca628f7d2480a1cc3214912b40b3414

With these kernels:

cat /sys/class/power_supply/BAT0/status

Will now output "not charging" under these conditions. This is what the
device's firmware gives us, so this is the best the kernel can do. Translating
"not charging" + the capacity in % being more or less equal to the
charge_control_end_threshold(1) value to "full" is something for userspace
(upower) to sort out. Since we are looking on adding UI options to set
charge_control_end_threshold, it would be good if we can get upower reporting
"full" under these conditions.

Note the upower issue should be re-opened to track this.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215531] Lenovo charge limit feature stops 1% short of the configured limit and says it's still charging

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215531

--- Comment #2 from Nate Graham (nate@kde.org) ---
> 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"?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215531] Lenovo charge limit feature stops 1% short of the configured limit and says it's still charging

[bugzilla-daemon]

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.

[Bug 215531] Lenovo charge limit feature stops 1% short of the configured limit and says it's still charging

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215531

--- Comment #4 from Nate Graham (nate@kde.org) ---
OK, thank you for the information. I will adjust our code in KDE Plasma
accordingly.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215531] Lenovo charge limit feature stops 1% short of the configured limit and says it's still charging

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215531

--- Comment #5 from Hans de Goede (jwrdegoede@fedoraproject.org) ---
(In reply to Nate Graham from comment #4)
> OK, thank you for the information. I will adjust our code in KDE Plasma
> accordingly.

Does KDE Plasma not use upower for this?  This sort of low-level raw kernel
interface wrangling to make it easier to use for userspace ideally really
should be shared between different desktop environments.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215531] Lenovo charge limit feature stops 1% short of the configured limit and says it's still charging

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215531

--- Comment #6 from Nate Graham (nate@kde.org) ---
We do use upower, but upower is currently affected by the aforementioned bug
that makes it not report that the battery is full when a charge threshold has
been met, so we have code working around this until that gets fixed.

Once upower correctly reports "plugged in and fully charged" when the charge
level is at the limit and charging has stopped, we can remove that code.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.