Conversation
…cture that seems correct.
…readme to mention COPR repo.
|
instead of merging main into this branch you can just rebase it onto main |
|
Also please squash commits like this |
|
You can make it later tho, when it will be ready to merge |
Yeah I was planning to squash everything as it is a bit messy.
True, but teachers did not teach that to us ! They said the opposite which is the stupidest thing ever as it is causing a lot of merge conflict (rebasing main into your dev branch 💀 ) |
|
As you not changed files, changed in other commits - this can't create conflicts. But I'm using GUI for squash/rebase |
Yeah ok. I am mainly using the CLI so it is a bit hard. Do you happen to know if it will be possible to add a webhook to this repo to trigger the COPR builds upon merging in the main branch ? |
|
No, but if you have guide lets think how make it possible. I mean that only setting I have is GH Actions |
|
Okay, I think we can make it work that way. I will study that and add a github action file to my PR. If you want I can do it on a different PR. |
|
If Github have native webhooks support, we can ask BeardOverflow to enable it |
|
Okay there is push trigger, but not merge, when Actions have more fine grained settings |
|
What I really would like to automate is supported devices and issues list #277 |
What would you want with that ? Like every PR gets linked to the issue, or every new issue creates a new PR ? Because if it is the latter, it is a good recipe for instability and merge conflicts IMO. |
|
And if you want CI/CD to update the list, then I think it may be possible, but I will have to see how. |
|
OK Just went through everything, and I think auto-updating the device list may be something possible. However, we may have to change again and switch back to a Markdown file. Let me explain: |
|
And if you'd prefer a local database, that may be possible too but i am a bit scared of how that would turn with merge conflicts, unless we are running the CI/CD in it's own branch. |
|
My goal was to reduce amount of new issues, which duplicate already existing ones. And problems tracing. Next goal is getting rid of versions in version strings. We've figured out that SKU from DMI represents board revision, as same as EC version string. But I need more data to prove this. |
|
You made me think about GH wiki, which can be updated in CI/CD pipeline. But now we have no reliable way to link devices to Issues and PRs, except text in them. Linking helps, but not enough. Tagging will create email storm and eat API rate limit if automated. Would be nice to find markup format which can be easily updated and rendered |
|
Do you mean to build by Github or just trigger remote buildbot? |
|
It would be a trigger for a remote build operated by copr directly. A webhook could also do trick. It means however that we will have to change the version regularly (this is why it is in a new makefile in my pr, so we can automate that) |
|
So you want automate version bumping in repo via CI/CD? Currently we are bumping it rarely because you can't uninstall DKMS module if you bumped version. It should be easy fixable tho. But actually I will prefer webhook from gh repo settings than script. But what will happen if copr buildbot sees same version? Just skip build? |
|
@BeardOverflow Hi, can you add Fedora copr webhook to repo settings, so we can automate builds for Fedora Silverblue? |
|
@Xabi08YT Do you know anything about Bazzite? It built on top of Silverblue so may it have some benefits from this copr release? |
Yeah i think it would be fixable pretty easily if you want i can do a separat makefile only for that.
Yes it is based on silverblue and also uses akmods, so it should also benefit from this COPR repo. The install process should be the same as the one for Silverblue I think. |
No it wont skip the build, but the client won't be able to update. So if you want I make a separate makefile just for akmod. |
|
Anyway; I am super happy i finally got it to work. Do you want me to test the akmod on bazzite ? It won't be able to test it before 23:00 CEST. |
|
I personnaly think it would be better to trigger the build through CI/CD though. Because on PR we could add the -experimental flag to all packages coming out of copr, avoiding peaple getting versions that do not build. |
|
If you have installed Bazzite - would be nice, but if not - don't bother. Bazzite devs worked on About webhooks - let's wait for BeardOverflow's answer |
Okay. For bazzite, the WMI platform is great but most commands about TDP, performance mode and so on are passing directly to the ec, if I recall correctly. |
|
Also, I don't knwo what you think about that, but I though I could try publishing the rpm package to rpm fusion in the near future. I have a last idea, that I may implement later, but it would be a .deb package for Debian based distro, since many beginner may use these distro. |
|
Better idea would be to switch to developing the |
True. I tried decompiling MSI's ACPI, and the IASL (Intel's tool to do so) said nope. |
Actually this all available through EC directly, but mapped to ACPI calls. But sadly MSI in own software used direct addressing in most cases. |
I've planned to simplify version matching and get rid of release number part. SKU number seemed promising, but in reality was just BIOS + BIOS revision, while EC carries 2 revision numbers |
|
And worst thing that I have WMI1 laptop, so I can't test |
|
Actually this all available through EC directly, but mapped to ACPI calls. But sadly MSI in own software used direct addressing in most cases. Okay. I understand better. So at the moment, this module is a backup solution. I will try disassembling everything again shortly because if MSI support can be improved for machines that I use, I'm in.
Okay I think it would be great to avoid having to update supported versions every day.
Mine is WMI2 if you want. |
|
Their code is just big hardcoded name matching. Other basic functions seems standard for all models, but whitelisted by their logic. For WMI1 devices they used kernel ring0 driver, so I'm curios did they've found workaround of it being marked malware |
Oh... Yup that's bad. Looking forward to the evolution of MSI WMI driver. |
|
BTW, just throwing that here, but do you think creating a new issue label named "Package issue" would be a good idea ? |
|
WMI1 and 2 are partially compatible by design, but WMI1 lacks some address mappings to EC, so direct access is needed |
Oh I though msi_wmi was the recent one since it is also loaded. Is the new one msi_wmi_platform ? Both are actually loaded on both of my laptops. |
|
msi-wmi is intended for soft keys on old devices. Currently through same WMI callbacks events are sent in other format. Events are like fan button, usb-c charge, backlight key, etc |
Interesting thank you. |
added back old config for those who need it for dkms.
improved english concerning dkms over copr
|
Do you have other ways to contact you? Telegram, Matrix, |
I have discord, but like, discord.... That is the most reliable way to contact me. Then you have email... |
2 participants
SRPM packaging script for MSI-EC.
Designed to work on Fedora and Fedora Silverblue. Builds may be opened to more RPM-based distro in the future.
Distros:
x RHEL 8 (Cannot build on COPR)
x RHEL 9 (Cannot build on COPR)
Anyway, I stated into the COPR install instruction, that the recommended way for Workstation editions and RHEL remains this github repo and DKMS. COPR are only provided as backup for distros like Fedora Silverblue/Kinoite that are only supporting Akmod.