search

aymanbagabas / Huawei-WMI

Huawei WMI laptop extras linux driver
GNU General Public License v2.0
226 stars 15 forks source link

Huawei Matebook X Pro 2020 - battery charge threshold - end seems active, start seems inactive #51

Closed jerabaul29 closed 3 years ago

jerabaul29 commented 3 years ago

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

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):

$ 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
$ 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 .

jerabaul29 commented 3 years ago

dmidecode.txt dmesg.txt acpidump.txt

aymanbagabas commented 3 years ago

Is this behavior the same in Windows?

jerabaul29 commented 3 years ago

What do you mean @aymanbagabas ? :)

jerabaul29 commented 3 years ago

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).

aymanbagabas commented 3 years ago

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

Helium314 commented 3 years ago

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.

aymanbagabas commented 3 years ago

@Helium314 could you try the wq branch and test it from there?

Helium314 commented 3 years ago

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.

Helium314 commented 3 years ago
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.

Helium314 commented 2 years ago

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.

jerabaul29 commented 2 years ago

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 :) )?

Helium314 commented 2 years ago

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.

jerabaul29 commented 2 years ago

:) .