-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Battery protection settings #2
Comments
Thank you for your awesome work, I'll test. Right away from the start I can say that |
Yep, something is definitely off here. I just got
Both Setting |
I meditated in front of registry table ( |
Interesting! |
I have no Windows running on this machine, so my best chance would be finding someone who still does. As for DSDT/SSDTs, here is the result of |
Also, I received these ACPI dumps from a person running Windows. There are three, for three conditions: battery protection off and two modes for on. AcpiTbls.zip |
...and they kindly supplied EC states as well. |
After looking at the EC states, definitely, REG[0xe4] and REG[0xe5] are responsible for battery thresholds as you can see they correspond with the thresholds values. For example, in EC6662_40_70.rw, REG[0xe4]=0x28 which is 40 in decimal and REG[0xe5]=0x46 which is 70. Please try the following while charging and test if battery protection works
Thanks! |
In PC Manager, there is a setting that makes the default behavior of the first row either function keys or multimedia. So if this is turned off, F1 key would decrease brightness and Fn+F1 would trigger F1. Now if on, it would be the opposite, F1 key would be just F1 and Fn+F1 would be brightness.
|
No such luck. First of all, I totally agree that REG[0xe4] and REG[0xe5] are most likely thresholds, that's rather obvious. However, REG[0x9c] looks like a poor candidate for battery protection, since it has the same contents in "disables" and "70-90" dumps. Wouldn't it be natural for battery protection register to be the same in "70-90" and "40-70", but a different value in "disabled"? Anyway, I gave it a try, and I don't have any idea what is happening.
I tried to find a register that would be the same in "40-70" and "70-90" dumps but different in "disabled" dump. I found three of those: REG[0x22], REG[0x9e] and REG[0xb2]. However, neither of them looks a good enough candidate to me:
Maybe I'm missing something? |
This. Is. Awesome. Really, thank you for that, that alone deserves your name to be remembered among the living and your image cast in stone somewhere on Mt. Everest. I had no idea this function lock even existed (since I barely looked at PC Manager before wiping Windows off my machine). I had my comrade on 4pda.ru forum send me EC register dumps and now I've got it. On MB13 it's [REG0x08]. It's 0x00 by default, 0x01 with Fn key on (and Fn led lit up), that much I knew already. Now I know that setting it to 0x02 enables this Fn-Lock feature, and further pressing Fn key sets it to 0x03 and inverts behaviour. This finally allows for things like Ctrl+Ins or Alt+Shift+PrtSc to happen! Thing is, with Fn-Lock off MB13 still translates any Ctrl+Fx, Alt+Fx and Shift+Fx as Mod+Fx, so without going Fn-Lock you can never get Shift+Ins, you'll always get Shift+F12. Another thing to mention: Fn and CapsLock leds on MB13 seem to be mirrored by [0xa4]: in is [0x00] initially, [0x01] with Fn led on, [0x02] with Caps led on, and naturally [0x03] with both on. However, manually changing this register doesn't change led states. |
Lol, I don't know about that.
You could also use Shift+Fn+Ins I'm using diff to see the differences between the files and comparing each one with the disabled one. |
Does this mean that the EC data were collected while the cable is unplugged?? The status should be "Unknown" when the feature is working since Linux "still" doesn't detect such features hence the unknown value. However, you could monitor the charging rate to know if its working using something like |
Not without Fn-Lock, no. Now I can.
I wouldn't really know. I am doing some more testing, might be on something here, but still too early to say. Will update as soon as I have consistent data. |
OK, I did some more testing. What I previously said about [0x9c] seems to be only partly true (maybe I didn't pay enough attention). It indeed shows 0xc0 for not charging, 0x80 for charging, and no, it can't really be flipped manually, it gets reset back almost immediately (although not immediately enough, so to If the battery charge is low enough, I can set reasonable thresholds with power cord unplugged, and then have charging stop at the desired point.
However, the lower threshold doesn't get respected...
...and here is where consistent behaviour ends. More often than not [0x9c] flips to 0x80 at replug, and laptop starts charging up until the threshold set by [0xe5]; but sometimes [0x9c] keeps beeing 0xc0 even after replugging, in which case battery is not charging. I've noticed a few more things while testing:
I'll test more, especially at points of inconsistence (unplug-replug and setting thresholds while plugging), but you've got the picture. Can't say I really understand what's going on and what to do next. |
All right, I got it. At least I think I got it. The way battery protection works on this machine is really different from ThinkPads, and it got me going in a totally wrong direction (well, not totally wrong, but somewhat orthogonal). What I've described in previous comment is actually things working as they are supposed to, with one exception. Thing is, all the tests described in previous comment were done using a weak phone charger I happened to have in my office (as I left the original Huawei charger at home). Actually, 0xc0 in [0x9c] doesn't stand for "discharge", it stands for "don't charge", and this subtle difference explains it all. The original charger is powerful enough that under no circumstances (including massive wireless data transfer, max screen brightness and multithreaded CPU stress test all at the same time) battery charge can go down with charger plugged. As soon as I guessed how this all works, I asked the windows-running guys to confirm some of the behaviour, and indeed everything fits. Here's the logic:
I think I'll modify your script for MateBook 13 to remove all but thresholds (I have made a separate script for fn-lock anyway) and introduce two-step changing. Thank you A LOT (I really can't express how much) for all your input and work! |
That's great! I was gonna tell you to install Windows to a USB using WinToUsb but you got it all figured out.
Are you on the newest BIOS update? Some people reported broken battery protection on my model while being on an outdated BIOS update. Could you please provide me the output of |
I'm on BIOS 1.05, which is the newest available on Huawei website (I did fugure out how to update BIOS without Windows, it's documented in README of this repo, if you're interested). And here you go: dmidecode.gz Keep up the awesome work! I can hardly be of any more use (other than testing, perhaps), but if someone is ever going to write a proper natacpi driver for these batteries, I guess it would be you. |
That actually worked! You're a genius thank you. I've been trying to find a way for a while. I got to extracting the capsule using InsydeImageExtractor but that was it. You nailed it down.
I will try my best whenever I get free time. I will close this issue and the other one since we figured out how it works. I will message you whenever if I need more information. Thank you again! |
One more thing about this: I have explicitly asked windows-running guys to test this thing, and they report [0x9c] flipping to 0x80 and charging starting "immediately" when switching PC Manager preset from "40-70" to "95-100". There's a possibility I still am missing something about this. Anyway, with what info is available, two-step switching looks like a viable option. |
Yeah, that's a possibility. I'm working on updating the script. I'll notify you whenever its ready |
Mine already is. ;) |
Hey!
Could you please try this script for setting charging/discharging thresholds. I got it to work on my matebook x pro 2018 it would be really nice to test it on another device. Thanks!
The text was updated successfully, but these errors were encountered: