How can I use these innovations?

[den1source]

How can I change the battery charge threshold, or, for example, switch the fan operation mode to "turbo mode"? Thank you for this work)

[teackot]

Hi!

For battery thresholds: I think KDE has this built into the settings and Gnome has an extension called "Battery Health Charging". If you can't find any settings/extensions/apps for your DE/WM or just want to use terminal, read further.

For everything else, you need to write into the corresponding files. Most files are located at /sys/devices/platform/msi-ec/. For example:

$ echo on | sudo tee /sys/devices/platform/msi-ec/cooler_boost # enables the cooler boost
$ echo right | sudo tee /sys/devices/platform/msi-ec/fn_key # swaps super and fn so that the fn key is on the right

The battery threshold files are located at /sys/class/power_supply/BAT1/charge_control_end_threshold (and ...start_threshold). Just write the battery percentage into those files:

$ echo 80 | sudo tee /sys/class/power_supply/BAT1/charge_control_end_threshold

[den1source]

Thank you very much)

[rottenpants466]

Hi!

For battery thresholds: I think KDE has this built into the settings and Gnome has an extension called "Battery Health Charging". If you can't find any settings/extensions/apps for your DE/WM or just want to use terminal, read further.

For everything else, you need to write into the corresponding files. Most files are located at /sys/devices/platform/msi-ec/. For example:

$ echo on | sudo tee /sys/devices/platform/msi-ec/cooler_boost # enables the cooler boost
$ echo right | sudo tee /sys/devices/platform/msi-ec/fn_key # swaps super and fn so that the fn key is on the right

The battery threshold files are located at /sys/class/power_supply/BAT1/charge_control_end_threshold (and ...start_threshold). Just write the battery percentage into those files:

$ echo 80 | sudo tee /sys/class/power_supply/BAT1/charge_control_end_threshold

Hi teackot!

This driver was merged in the kernel 6.4 right? if so in my case battery thresholds are not appearing in KDE settings. Some special keys are not working as well like touchpad disable and one or tow leds on the keyboard(Fedora 38).

I also tried and installed the driver here and it seems things are also not working. There is no msi-ec folder inside the platform folder (Using Fedora 38 with secure boot disabled).

[teackot]

Hi! Can you remind me your laptop's model?

[rottenpants466]

It's a Summit E16 Flip A12UCT model.

Prior to kernel 6.4 everything was working fine and the msi-ec folder was created.

With kernel 6.4/6.5 the mentioned folder is not created.

Edit: secure boot is disabled

I'm also on bios version: E1592IMS.10C

This laptop has 3 versions:
E1592IMS.10C
E1592IMS.10D
E1592IMS.10F

If i'm not mistaken, the driver merged in kernel 6.4 added support for E1592IMS.10C

[teackot]

Can you load the github version of the driver in debug mode (sudo make reload-debug), and then show me the output of cat /sys/devices/platform/msi-ec/debug/fw_version? I have suspicions that bios version != ec version

[rottenpants466]

Can you load the github version of the driver in debug mode (sudo make reload-debug), and then show me the output of cat /sys/devices/platform/msi-ec/debug/fw_version? I have suspicions that bios version != ec version

Hmm found something strange...

The msi-ec folder seems to disappear when i restart the computer. IF i don't restart after installing the driver the folder IS created.

For some reason it says that my firmware version is 1592EMS1.111 which is a version from a different model of the same laptop:
https://github.com/dmitry-s93/MControlCenter/blob/main/docs/tested_devices.md

[teackot]

Okay, so the reason it shows 1592EMS1.111 is because it is your EC version, and E1592IMS.10C/D/F is a BIOS version, which are different things. Looks like those models share the EC firmware.

Now the reason why msi-ec folder disappears is that the kernel prioritizes the kernel version of the dirver over the github version. The kernel version doesn't have the msi-ec folder yet (only charge thresholds)

[rottenpants466]

Oh.... now it makes sense. That's why there's no option to change battery thresholds in kde power settings.

Well mystery solved i guess :D

Thank you for your time and patience teackot!

[teackot]

You're welcome!

[rottenpants466]

But the battery thresholds should at least be working in kernel 6.4/6.5 right?

I'm getting same weird values:

[teackot]

I think it's the same problem as #56, you can actually change the thresholds and they will work fine

[rottenpants466]

I think it's the same problem as #56, you can actually change the thresholds and they will work fine

I did the following commands: echo 70 | sudo tee /sys/class/power_supply/BAT1/charge_control_start_threshold and echo 80 | sudo tee /sys/class/power_supply/BAT1/charge_control_end_threshold but the battery is not charging (the level it's at 55% at the moment)

Shouldn’t it start charging? Maybe i need to reset the ec?

[teackot]

Hmm, yeah, better reset the EC and reboot. Tell me if the thresholds work after that

[rottenpants466]

Hmm, yeah, better reset the EC and reboot. Tell me if the thresholds work after that

Hmm, yeah, better reset the EC and reboot. Tell me if the thresholds work after that

I did the EC reset and after rebooting i did echo 50 | sudo tee /sys/class/power_supply/BAT1/charge_control_start_threshold and echo 60 | sudo tee /sys/class/power_supply/BAT1/charge_control_end_threshold.

The battery is currently at 63% and charging, it doesn’t stop.

Edit: tried resetting the EC a couple of times and I’m getting the same result.

[teackot]

If it worked before... weird. Can you attach a debug EC dump please

[rottenpants466]

I don't know if this is the right command but

sudo hexdump -C /sys/kernel/debug/ec/ec0/io
00000000  00 80 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  0a 05 00 00 08 0c 09 08  |................|
00000030  02 05 00 0d 01 00 50 81  a0 14 60 3b 10 02 c0 00  |......P...`;....|
00000040  18 15 3e 00 37 14 0c f9  69 0c af 3b 26 0c f8 43  |..>.7...i..;&..C|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  41 00 3c 46 50 55 5a 5f  |........A.<FPUZ_|
00000070  64 37 2d 37 3c 46 5a 6e  82 00 0a 08 08 03 03 03  |d7-7<FZn........|
00000080  00 00 37 41 4b 55 59 5a  59 2d 2d 46 5a 64 6e 6e  |..7AKUYZY--FZdnn|
00000090  6e 00 05 03 03 08 07 03  02 00 7d 02 00 7d 36 00  |n.........}..}6.|
000000a0  31 35 39 32 45 4d 53 31  2e 31 31 31 30 36 32 39  |1592EMS1.1110629|
000000b0  32 30 32 32 30 39 3a 35  32 3a 32 38 00 00 00 28  |202209:52:28...(|
000000c0  00 00 01 00 00 00 00 00  00 a4 00 ad 00 00 00 00  |................|
000000d0  00 00 c1 83 0d 00 05 80  00 00 00 00 00 0e 00 00  |................|
000000e0  e2 00 00 37 14 01 00 00  00 04 00 00 00 79 01 00  |...7.........y..|
000000f0  00 00 70 00 35 64 00 00  64 00 00 00 00 01 00 00  |..p.5d..d.......|
00000100

I downgraded the kernel to 6.3 to see if battery thresholds worked but no :|

What it always worked for me was using this: https://github.com/MusiKid/acpi_ec in conjunction with this app https://github.com/dmitry-s93/MControlCenter

[teackot]

Looks like we got your battery thresholds address wrong, it should be 0xd7. I will make a PR fixing it

[rottenpants466]

Looks like we got your battery thresholds address wrong, it should be 0xd7. I will make a PR fixing it

My laptop and the MControlCenter's author are basically the same, don't know what his battery thresholds are.

[teackot]

Yeah, I checked that app, looking at the algorithm used there it should be 0xd7. I made a PR correcting this address

[glpnk]

In his code are two addresses:

const int batteryThresholdAddress_0xEF = 0xEF;
const int batteryThresholdAddress_0xD7 = 0xD7;

[teackot]

Yes, but here's the algorithm it uses to choose one of them:

int Operate::detectBatteryThresholdAddress() const {
    if (128 <= helper.getValue(batteryThresholdAddress_0xEF) && helper.getValue(batteryThresholdAddress_0xEF) <= 228)
        return batteryThresholdAddress_0xEF;
    if (128 <= helper.getValue(batteryThresholdAddress_0xD7) && helper.getValue(batteryThresholdAddress_0xD7) <= 228)
        return batteryThresholdAddress_0xD7;
    return 0;
}

It chooses the address with the value >= 0x80 and @rottenpants466's EC has 0x80 at [0xd7]
Also in #10 @rottenpants466 said that this fork worked on their laptop, it also uses 0xd7

[rottenpants466]

Ok :)

I will uninstall msi-ec and reinstall again with the new value in msi-ec.c and test.

Yes, but here's the algorithm it uses to choose one of them:

int Operate::detectBatteryThresholdAddress() const {
    if (128 <= helper.getValue(batteryThresholdAddress_0xEF) && helper.getValue(batteryThresholdAddress_0xEF) <= 228)
        return batteryThresholdAddress_0xEF;
    if (128 <= helper.getValue(batteryThresholdAddress_0xD7) && helper.getValue(batteryThresholdAddress_0xD7) <= 228)
        return batteryThresholdAddress_0xD7;
    return 0;
}

It chooses the address with the value >= 0x80 and @rottenpants466's EC has 0x80 at [0xd7] Also in #10 @rottenpants466 said that this fork worked on their laptop, it also uses 0xd7

Ok :)

I will uninstall msi-ec and reinstall again with the new value in msi-ec.c and test.

Edit: Just tested and now it works!

It's fixed!

[teackot]

Yay!

[rottenpants466]

Thank you teackot!!

Will this be merged in a future kernel release?

[teackot]

I'm not sure I'll make it in time for the Linux 6.5 release, idk if the merge window is still open. I want some PRs to be merged here first so I can add more configs in my patch

[rottenpants466]

:)

Do you have pay pal or similar? you sir deserve more than a couple of bucks 👍

[teackot]

I appreciate it, but no need
Knowing that I'm doing something important is enough for me =)

[glpnk]

Hi @teackot today I found in-kernel driver for MSI laptop from 2006, but algorithm is different: msi-laptop.c, doc

[glpnk]

Hello, anyone has this in dmesg?

[    0.289959] ACPI: \_SB_.PCI0.SBRG.EC__: Boot ECDT EC initialization complete
[    0.289960] ACPI: \_SB_.PCI0.SBRG.EC__: EC: Used to handle transactions and events

with periodical errors like that

...
[ 7753.245723] ACPI Error: Aborting method \_SB.PCI0.SBRG.EC._Q9A due to previous error (AE_NOT_EXIST) (20230331/psparse-529)
[ 8835.829681] ACPI Error: Aborting method \_SB.PCI0.SBRG.EC._Q9A due to previous error (AE_NOT_EXIST) (20230331/psparse-529)
[ 8836.945474] ACPI Error: Aborting method \_SB.PCI0.SBRG.EC._Q9A due to previous error (AE_NOT_EXIST) (20230331/psparse-529)
...

It is not related to MSI-EC. I think it related to reading EC address 0x9a but without handler in APST or similar tables