Huawei Matebook X Pro 2020 - battery charge threshold - end seems active, start seems inactive
jerabaul29 opened this issue · 13 comments
I am using Ubuntu 20.04 (recently installed, nothing special) on a Huawei Matebook X Pro 2020. It looks like the end threshold (i.e. the content of /sys/class/power_supply/BAT0/charge_control_end_threshold) is well taken into account, but the start threshold (/sys/class/power_supply/BAT0/charge_control_start_threshold) is not. I.e., if end threshold is set to 70, I never observe battery levels over 70%. However, if the start threshold is set to 40, I still see the battery starting to charge even if the battery level is 60. I make sure that these thresholds are set at boot time, using a small cron job (the sleep seems needed for whatever reason, probably to let the system warm up):
@reboot sleep 20; echo 70 > /sys/class/power_supply/BAT0/charge_control_end_threshold
@reboot sleep 30; echo 55 > /sys/class/power_supply/BAT0/charge_control_start_threshold
To Reproduce
- Set the end threshold to 70 and the start threshold to 55 (or any other value really).
- Battery over 70 is never observed: this works fine
- However, starting from a battery at a level of 65, and plugging in the power supply, the battery starts to charge; i.e., the start threshold seems to be ignored.
Expected behavior
Starting at battery level of 65, with a start threshold of 55, the battery should not start charging at all.
(please complete the following information):
-
dumps: see attached files (coming in 2 minutes :) ).
-
others:
$ uname -a
Linux MBX20 5.8.0-63-generic #71~20.04.1-Ubuntu SMP Thu Jul 15 17:46:08 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
- Distro: Ubuntu 20.04
$ lsmod | grep wmi
intel_wmi_thunderbolt 20480 0
wmi_bmof 16384 0
huawei_wmi 20480 0
sparse_keymap 16384 1 huawei_wmi
ledtrig_audio 16384 3 snd_hda_codec_generic,huawei_wmi,snd_sof
snd_rawmidi 36864 1 snd_seq_midi
snd_seq_device 16384 3 snd_seq,snd_seq_midi,snd_rawmidi
snd 94208 22 snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_compress,snd_soc_core,snd_pcm,snd_rawmidi
mxm_wmi 16384 1 nouveau
wmi 32768 5 intel_wmi_thunderbolt,huawei_wmi,wmi_bmof,mxm_wmi,nouveau
Additional context
Curious if anyone else is able to reproduce? Is this a know issue? There is also a SO issue, though no activity there: https://stackoverflow.com/questions/68073262/charge-control-thresholds-on-ubuntu-20-04-seems-like-end-threshold-is-active-b .
Is this behavior the same in Windows?
What do you mean @aymanbagabas ? :)
I have wiped off windows, no way to do any windows Vs Linux tests for my part unfortunately if this is what you mean. But I am pretty sure that this is not the expected behaviour. On my ThinkPads with tlp enabled and similar threshold, the effect of start threshold is that charging starts only when battery level falls below the threshold - to avoid super many small charging around the top threshold).
ThinkPads != Matebooks, different vendors have different specifications. If this is happening with Huawei-WMI then I'm pretty certain Windows will give you the same behavior since both PC Manager and this driver use the same underlying interface.
Closing until you verify or someone with the same device verifies the issue. Sorry
I can semi-confirm the issue.
My device is a Matebook X Pro 2018, not 2020. Otherwise it's the same, also using Ubuntu 20.04.
Both charge thresholds used to work previously, but now the lower one doesn't. I only noticed it a month ago, now sure when it started.
Don't have Windows for comparing behavior.
@Helium314 could you try the wq branch and test it from there?
Battery at 83%, thresholds at 60 and 88.
Started charging as soon as I plugged in.
Stopped when setting upper limit to 83, but started again after setting to 84.
After plugging/unplugging and changing thresholds a few times it started working properly (until reboot). Not sure what exactly caused this... will try again tomorrow.
Current behavior, checked using /sys/class/power_supply/BAT0/power_now and /sys/class/power_supply/BAT0/status
| battery | start threshold | end theshold | charging |
|---|---|---|---|
| 69 | 60 | 80 | yes |
| 69 | 60 | 70 | no |
| 69 | 60 | 65 | discharging |
| 71 | 70 | 70 | yes |
| 71 | 70 | 71 | discharging |
| 72 | 71 | 73 | no |
charging result never changed after unplugging and plugging.
The discharing despite being plugged is something that definitely didn't happen before...
Yesterday I was able to get it working correctly (i.e. same behavior as described in #35) one more time after a lot of plugging, unplugging and threshold changing, today I wasn't.
I did not manage to reliably reproduce the switch to a working-as-usual state. Only notable thing is that when the switch works, the command (e..g echo 70 > /sys/class/power_supply/BAT0/charge_control_end_threshold) takes about a second to finish, as opposed to the normal immediate execution.
Anyway, the root cause appears to be a BIOS update to 1.36 I did in summer (before removing Windows 10). On BIOS 1.29 everything works as it used to.
Should this issue be re-open since we are several who can confirm the issue and the bug seems "reproducible"? :) . Then of course it is a question if this should be also forwarded to Huawei (if there is an issue with their BIOS? or is it some other organisation that "produces" the BIOS? a bit of a n00b there :) )?
BIOS is coming from Huawei, and I just saw there is a newer version 1.37 for Matebook X Pro 2018, maybe it's a related bugfix.
If new BIOS version changes the intended behavior, then issue could maybe be re-opened, but if it's a bug it has nothing to do with the Huawei-WMI here.
:) .