Bug 215531
| Summary: | Lenovo charge limit feature stops 1% short of the configured limit and says it's still charging | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Nate Graham (nate) |
| Component: | Platform_x86 | Assignee: | drivers_platform_x86 (drivers_platform_x86) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | jwrdegoede, rui.zhang |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 5.15.16 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
Nate Graham
2022-01-25 17:50:26 UTC
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. > 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"?
(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. OK, thank you for the information. I will adjust our code in KDE Plasma accordingly. (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. 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. |