feat: Add acpi_call kernel module

[cr7pt0gr4ph7]

Add the acpi_call¹ kernel module to the extra/ stream.

Note about the current build failure: This PR is written as-if the COPR build for acpi_call-kmod and acpi_call-kmod-common had already been set up at https://copr.fedorainfracloud.org/coprs/ublue-os/akmods/ - preferably sourced from github.com/nix-community/acpi_call once nix-community/acpi_call#28 has been merged².

Until that PR has been merged, an example COPR build of acpi_call-kmod and acpi_call-kmod-common can be found at https://copr.fedorainfracloud.org/coprs/cr7pt0gr4ph7/acpi_call/, currently using my own acpi_call repository fork, and example image builds can be found at https://github.com/cr7pt0gr4ph7/akmods/actions.

Footnotes

1. The acpi_call module allows one to manually issue ACPI method calls, which is useful to advanced users for disabling discrete Nvidia graphics cards on older laptops with hybrid Intel+Nvidia graphics where no option for this is available in the BIOS, as well as for interacting e.g. with Firmware-based fan control when no specific driver is available. ↩

2. As it appears, the people from the NixOS community now seem to be the de-facto maintainers of the acpi_call module. ↩

[antheas]

The extras feed is used by the bazzite kernel and the bazzite kernel already has acpi_call?

[cr7pt0gr4ph7]

The extras feed is used by the bazzite kernel and the bazzite kernel already has acpi_call?

I'm running Bluefin, which uses the stock Fedora kernel AFAICT, so it would be nice to be able to use this module on that stock kernel. (As an aside: I have no real preference on where the sources for that kernel module come from, though - maybe it is possible to use the same patchset as Bazzite).

Thanks for pointing out that Bazzite already includes the acpi_call module. The knowledge about that is hidden within a gigantic Patchfile that isn't indexed by GitHub due to its size, and Google was of no help here either. May I suggest providing a list of extra kernel modules provided by Bazzite somewhere in the documentation?

Coming back to this PR: The README says (emphasis added):

The akmods package is broken out into three akmod "streams":

• common - any kmod installed by default in Bluefin or which was originally in main pre-39
• extra - primarily for kmods used in Bazzite or any others we need, but don't fit in common
• nvidia - only for the nvidia kmod and addons
• zfs - only for the zfs kmod and utilities

The acpi_call kmod is neither related to nvidia nor zfs, and is also not intended to be installed by default in Bluefin, so the only remaining matching "stream" is therefore extra.

Is your objection based on extra being the wrong location, or on the fact that Bazzite already includes that kmod, and so it shouldn't be included in the akmods repository at all?

[antheas]

Ah, well the extras stream is not being used by bluefin at all, so you will not be able to use the module. Unless you redownload it every time you update bluefin.

And if you use bazzite, well it is already included. I do not have a good solution for this.

Bluefin does have a hwe variant that uses the Bazzite kernel for the time being. @castrojo is that being deprecated?

[castrojo]

Yea sorry Bluefin is going stock-kernel only and the handful of main akmods we already have.

[cr7pt0gr4ph7]

Ah, well the extras stream is not being used by bluefin at all, so you will not be able to use the module. Unless you redownload it every time you update bluefin.

I'm already building my own Bluefin image at cr7pt0gr4ph7/bluefin, so that's not really an issue. Would there be value in creating a separate additionals stream for sharing such non-default but generally useful modules, or is it clearly out-of-scope for this project?

[bsherman]

I just wrote this on #317...
We don't generally approve/include new kmods unless there's a plan to include them in Bazzite/Bluefin/Aurora/uCore.

But the previous comment here asks the question of "should we have an additionals build for kmods not included in our downstreams (Bazzite/Bluefin/Aurora/uCore)"?

I tend to be against the idea because it incurs a maintenance burden while implying support. We do effectively support what we build by virtue of including them in the downstreams, thus we get reports if they aren't working, and try to fix things, etc.

If we are building things unused by our downstreams they will have a much lower chance of catching issues, but still imply support.

[antheas]

I guess I did not write this above but if you have a custom image and don't care about secure boot, you can just add the kmods to your image and build it for the kernel?

[cr7pt0gr4ph7]

I tend to be against the idea because it incurs a maintenance burden while implying support. We do effectively support what we build by virtue of including them in the downstreams, thus we get reports if they aren't working, and try to fix things, etc.

If we are building things unused by our downstreams they will have a much lower chance of catching issues, but still imply support.

That's a perfectly reasonable position! After all, resources are limited and should be spent in the most effective way.

We don't generally approve/include new kmods unless there's a plan to include them in Bazzite/Bluefin/Aurora/uCore.

The acpi_call module is already present in Bazzite (as mentioned by @antheas), but applied as an in-tree patch via handheld.patch instead of being built as a separate module.

Building it as a separate kmod instead would (probably?) not increase the support burden, but would allow usage by Bluefin users that require it to coerce non-cooperative hardware (hello, hybrid Intel graphics on laptops...) into doing what they want.

So, my suggestion would be to remove acpi_call from the Bazzite kernel repository, and instead build it as an out-of-tree module here.

I guess I did not write this above but if you have a custom image and don't care about secure boot, you can just add the kmods to your image and build it for the kernel?

That's the fallback plan. Secure boot makes things a lot more complicated, though :D