This repository has been abandoned. Contribute to active forks instead!

[FaridZelli]

As you may have already noticed, the project's original developer, YoyPa, has been offline (or to be specific, not been publicly active on this GitHub account) since February 26th, 2020. As I wasn't able to find another alias or contact him during this time, I've made a fork of ISW including various fixes (thanks to @BeardOverflow's contributions at request #205 and others) to get it working again on most Linux distributions. You can find my repository at:

https://github.com/FaridZelli/ISW-Modern
(Note: This fork is no longer maintained.)

The main reason for breakage occurring since mid-2021 is a dependency on the ec_sys Linux kernel module, which some distros are no longer including while compiling their kernels (such as Debian and Fedora). One universal way to resolve this is by embedding a DKMS (Dynamic Kernel Module Support) module with the same functionality into the project, which can also be somewhat-futureproof as the module is automatically rebuilt with every update to the system's kernel.

While BeardOverflow managed to pull this off perfectly for the Debian package, unfortunately I did not have the same coding skills to implement a similar solution for other distros as well, and therefore my current workaround relies on Sayafdine Said's acpi_ec DKMS module as a base.

While we wait on potentially receiving a project status update from YoyPa someday, feel free to make contributions to active forks of ISW in the meantime where they are more likely to be implemented. Or alternatively, make your own!

If you happen to make a fork of the project, leave a reply bellow and I'll leave a link to your repository on this post:

---

Placeholder

---

At last, here are a few alternatives to consider:

• MControlCenter
• MSI Laptop Fan Control
• OpenFreezeCenter - MSI Dragon Center for Linux.
• NBFC Linux - a C port of Stefan Hirschmann's NoteBook FanControl, for Linux.

Check out msi-ec, a dedicated kernel module for MSI Laptops.

[BeardOverflow]

Past year I was working in a kernel module [1], which could be a better long-term solution. In my mind, I wish continue it adding generic sysfs, ex: platform profiles [2][3]. With a matured and standardize module, we can get rid custom UI interfaces or CLI tools. This issue is related too: #226, but the referenced ticket is closed as not-a-bug [4].

However, ISW project as-is would be useful to play with experimental settings. We need to work over newer EC models still. Until now, we have little knowledge about how to send to/read from it. Moreover, could MSI collaborate with us giving support with internal documentation? Reversing EC is the current path, but nobody have tried to ask them including me.

Also, @marshevms has contributed with its own project here: https://github.com/marshevms/mlfc

[1] https://github.com/BeardOverflow/msi-ec
[2] https://www.kernel.org/doc/html/latest/userspace-api/sysfs-platform_profile.html
[3] https://www.phoronix.com/scan.php?page=news_item&px=Linux-ACPI-Platform-Profile
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1943318

[FaridZelli]

Hey @BeardOverflow, first of all thanks for sharing these resources!
I read through the links in the morning, and have been considering our options throughout the day.

msi-ec is an awesome project, and should definitely be the standalone DKMS module we use for MSI devices in the future. I think it can serve as a great base for MLFC, as it still seems to be reliant on ec_sys at the moment. I'm also interested in the idea of using ISW as a testing ground, to later implement our findings into a fresh codebase.

As for issue #226 and the Red Hat bugzilla thread, I wasn't aware of the fact that most OEMs already have drivers implemented within the kernel, as stated by Hans de Goede himself. Since MSI don't seem to be working on a solution themselves, this can be a great opportunity to work on something far more interesting.

It's a real headache to reverse engineer every single update MSI make to their EC models, and therefore certainly worth a shot to try getting in contact with them first. Of course, they aren't going to be handing out documentation to community devs and so the only chances we have of receiving any support from them would be through an official (or semi-official) collaboration, as you stated. After all, they're the same company who developed Afterburner. There's great potential here if we manage to get in contact with the right people.

Do you still have an MSI laptop? If so, are you currently available to start working on a new project?
Would be great if we form a small group, and make a proposal to MSI on the concept of a lightweight open-source control center for Linux, I wonder if we can get @marshevms and possibly @YoyPa on board.

[YoyPa]

I don't like how ISW ended, when I started I had no idea if every models where working the same way and if I should rely on laptop branding or motherboard name to discriminate. That's why there is a super long config file with every motherboard and it's a pain to maintain longterm. I think the config file is now dumb by design©.

An msi-ec giving acces to relevant settings and mlfc acting as user friendly interface seems awesome.

It's a real headache to reverse engineer every single update MSI make to their EC models

They did not change the logic in 10 years (gt60 from now, fans work the same) not even a difference between single and dual fan design to my knowledge. I think we can assume there is only one "logic" between every G/W series laptops + their weirdly branded Modern. And if an exception comes it can be handled as exception later.

worth a shot to try getting in contact with them first. [...] After all, they're the same company who developed Afterburner.

I'm pessimistic about this one, maybe via some youtube tech channel like LTT or wendell from Level1Tech, and I think afterburner started as a re-branding of rivatuner from https://en.wikipedia.org/wiki/RivaTuner // https://videocardz.com/35604/gpu-overclocking-apps-review/2
Maybe insisting on the fact that they sell laptops with no OS and Steam/Proton gaming future

I wonder if we can get @marshevms and possibly @YoyPa on board.

[FaridZelli]

Thanks for joining on the conversation YoyPa!

I think the config file is now dumb by design©

Lmao didn't see a single variation in the entire list, I made a [SILENT] section so now it acts like more of a "Shhh!" button. I'll do a proper cleanup of ISW someday, it's still a very reliable CLI tool for users looking to set a silent curve and forget about it. A merge between mlfc and msi-ec will be epic.

afterburner started as a re-branding of rivatuner

Very true, guess that's the "corporate way" of picking up existing projects. Still, they not only vastly improved on the base but also continued optimizing it for various cards of not only their own, but other brands too. This mindset is what mainly puts MSI in another category (or well, at least the developers working on Afterburner).

Trying to reach out to them through a media outlet / YouTube channel may not be the way to go, I'll see whether it's possible to get a hold of a dev through the forums in the long run :-]

P.s. can you perhaps guide me on how to add a 30 second "downstep time" delay to ISW? I'm assuming this addition would be related to ~ Line 326, where a delay should be added if the new fan speed value is lower than the previous one. Also, what's the current polling rate ISW operates at? Sorry if these questions sound dumb, I've never used Python before and I'm still trying to learn the basics of how this all works.

[marshevms]

Hi guys. I am in :) As I wrote #226 I wanna try, but I don't have much time right now. Do you have telegram?

[FaridZelli]

Sure do! I'll send you a message, there are links to my Telegram channel and Matrix ID on my profile.

[BeardOverflow]

@FaridZelli I have my MSI laptop and I use it most of the time. For my model #204 and newer ones, some constants doesn't match with the "standard" constants, ex: auto fan mode 0x0c (standard) vs 0x0d (newer).

Currently I have no time to continue developing msi-ec, but after the summer I can. Meanwhile, part of the work can move forward. Again, personally I think it is very important re-analyze newer ECs (which constants are working or have changed) from the issue list in this repo.

@marshevms, would you be interested in adapt your UI over my msi-ec module? I liked your project and many standard sysfs are already addressed by another daemons like powerdevil (KDE), but extended power-profiling are vendor-specific logic.

About Telegram, sounds good, so I will write you @FaridZelli too.

[marshevms]

@BeardOverflow OK. Can you give us useful sources? Documents or articles or something like that

[BeardOverflow]

Useful resources... Well, it's hard answer and I just prefer fit it as an example.

Taking as an example to powerdevil (KDE) / upower (GNOME):

• In the server-side, sysfs paths are read/written and msi-ec exposes partially some of them:
  • powerdevil ChargeThresholdHelper
  • upower Changing thresholds
  • msi-ec power_supply subsystem

These sysfs standarized paths are known as part of a subsystem in Linux. For a complete full review of the power_supply subsystem, go to here

msi-ec only implements a subset of the power_supply subsystem because the rest can rely on a generic battery implementation.

What is missing then? The answer is the platform_profile subsystem in order to select Power Save - Balanced - Performance by a generic way. It shouldn't be hard to implement it, but again I have no time to do it actually (until after the summer):

• hadess
• nate
• phoronix
• kernel
• testbead

(Screenshot from the powerdevil widget of KDE)

So, what can do MLFC currently?
Give an UI for all non-standarized msi-ec sysfs paths (or standarized sysfs paths too, why not). You need be a privileged process to write to that sysfs paths.
Server part is needed, but only as a bypass. It will write to sysfs like this:

echo on > /sys/devices/platform/msi-ec/webcam
echo off > /sys/devices/platform/msi-ec/webcam

with open('/sys/devices/platform/msi-ec/webcam', 'w') as fd:
  fd.write('on')

As you can see, the current logic for talking with the EC implemented by the server-side of MLFC can be moved to the msi-ec module softly.

[levnikmyskin]

@FaridZelli I have my MSI laptop and I use it most of the time. For my model #204 and newer ones, some constants doesn't match with the "standard" constants, ex: auto fan mode 0x0c (standard) vs 0x0d (newer).

Currently I have no time to continue developing msi-ec, but after the summer I can. Meanwhile, part of the work can move forward. Again, personally I think it is very important re-analyze newer ECs (which constants are working or have changed) from the issue list in this repo.

@marshevms, would you be interested in adapt your UI over my msi-ec module? I liked your project and many standard sysfs are already addressed by another daemons like powerdevil (KDE), but extended power-profiling are vendor-specific logic.

About Telegram, sounds good, so I will write you @FaridZelli too.

+1 for the different addresses. I found out yesterday after some reverse engineering that my GF66 (MSI Katana) has a different battery threshold address (namely, 0xd7). If you need help I might be able to join you every now and then (my experience with C is close to 0 though, much more proficient with Python).

[dmitry-s93]

Hello. I am currently developing an MControlCenter application. This is a GUI (QT) application to change the settings of MSI laptops. It requires the ec_sys kernel module to work. Maybe it will be useful for someone.

[FaridZelli]

Hello. I am currently developing an MControlCenter application. This is a GUI (QT) application to change the settings of MSI laptops. It requires the ec_sys kernel module to work. Maybe it will be useful for someone.

Sounds cool, I'll leave a link to it on the post. Maxim's working on a similar project, MLFC. If you have Telegram you can send me a message @FaridZelli and I'll add you to the chat.