Skip to content
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

feat: added it87-extras for improved lm-sensors compatibility with some Gigabyte motherboards #261

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

grandpares
Copy link

Description

This recipe installs it87-extras, a packaged version of frankcrawford/it87 adding support for some Gigabyte motherboards. This package does not replace mainline it87 but installs a blacklist file for it as a dependency (contained in copr/grandapres/it87-extras/it87-extras-common).

Usecase

The primary purpose of the controllers this driver enables is PWM control of case fans, which is important for gaming systems. Therefore, this will be useful in Bazzite.

Issues

For most systems unsupported in the mainline, forcing controller ID when modprobing the driver and acpi_enforce_resources=lax are both necessary. Since the chip ID depends on the motherboard, and acpi_enforce_resources=lax is potentially destructive, neither should be set by default. A justfile that looks at the output of setup-sensors and then sets the necessary kargs is a possible solution, although I'm not sure where I could contribute one. However, users on unsupported systems should not experience any degradations compared to the mainline driver if these kargs are not set (their PWM controllers won't work in both cases).

Testing

I have tested that this module builds and installs from copr to akmod in Fedora 40 (mutable). Additionally, it builds from source, loads, and works as expected in aurora:stable. I wasn't sure if the akmods repo build actions are safe to run for testing, but if so, I can verify the image builds before merging. Currently, the copr repo is set to build from my fork of the module while I'm waiting for the upstream to review a PR containing the copr spec files.

@grandpares
Copy link
Author

Looks like the build workflows must be triggered before review anyway, updated pr to ready to review to allow maintainer to trigger
Thank you for maintaining this project. Please reach out with any additional questions via this pull request.

@grandpares grandpares marked this pull request as ready for review October 29, 2024 01:40
@grandpares grandpares requested a review from castrojo as a code owner October 29, 2024 01:40
@bsherman
Copy link
Contributor

bsherman commented Nov 2, 2024

@KyleGospo @HikariKnight @antheas

Have you discussed the inclusion of this kmod. If we were to merge would it get installed in Bazzite?

I think that's the critera for "extra" kmod additions at this point: "Does Bazzite plan to ship it?"

@KyleGospo
Copy link
Member

I'd consider it, first time seeing this.

@bsherman
Copy link
Contributor

bsherman commented Nov 2, 2024

@grandpares as is this doesn't actually build, your new build script needs to be added to the Containerfile.extra .

That will at least get it building for validation while the Bazzite team takes a look.

@grandpares grandpares marked this pull request as draft November 2, 2024 22:00
@grandpares
Copy link
Author

Done, can you re-run build checks to make sure everything works @bsherman ?

@grandpares
Copy link
Author

grandpares commented Nov 3, 2024

Okay, I think I know what's going on with the build failures. Purged some old builds that were messing with version control and renamed variables in the spec, seems to pick up the kernel version that akmods passes now. Hopefully this will fix it.

@grandpares
Copy link
Author

@bsherman could you rerun the build checks to make sure everything builds now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants