feat: add nvidia-open in build

[damachine]

Peace for all - KISS 🐸 💋

Add optional NVIDIA open module in-tree kernel support

New features

• NVIDIA open module package (_nvidia_open): Build open NVIDIA kernel modules (kernel-open) as a separate split package (e.g. linux619-tkg-bore-nvidia-open), sourced directly from NVIDIA's official tarball.
• Apply nvidia-open kernel patches
• Build _build_nvidia_open="true" Sanity checks & guards.
• Nouveau, lbm-nouveau, nova_core, and nova_drm are blacklisted in the nvidia-open package.

Config options added to customization.cfg

Option	Default	Description
_nvidia_open	"false"	Build NVIDIA open kernel modules as split package
_nvidia_open_version	""	Driver version (prompted if empty)

[zekdav]

Wow, that's great! You do very important work.

[AdelKS]

Any chance we can make RPMs and DEBs ? would it make sense ?

What's the benefit of doing it here instead of the nvidia-all repo ?

[damachine]

Any chance we can make RPMs and DEBs ? would it make sense ?

good point! started with PKGBUILD first since that's what I know — haven't touched install.sh yet. Would be a shame if the config options only worked for Arch, so yeah, making it work for RPM and DEB too makes total sense. will look into it

What's the benefit of doing it here instead of the nvidia-all repo ?

not everyone uses nvidia-all. if you're already building a custom kernel with linux-tkg, having the open modules build alongside it — versioned and matched — is just more convenient. otherwise users are usually stuck with the distro's DKMS package on top of their custom kernel anyway.

[AdelKS]

making it work for RPM and DEB too makes total sense. will look into it

Unfortunately it may not be straight forward since we'd need to dive into RPM spec files and whatnot 😢

but! maybe we can just include it as part of the kernel package itself (as if it was in-tree), just like any other kernel modules, and not make any extra package. That sounds best to me because we'd:

• Leverage the existing packaging process.
• Keep this repo about a single package: the kernel

And if people want to go the DMKS way, nvidia-all is there for them 🤔 ? Although currently it only supports Arch.

not everyone uses nvidia-all.

tkginstaller would be there as a single entry point hehe

[damachine]

making it work for RPM and DEB too makes total sense. will look into it

Unfortunately it may not be straight forward since we'd need to dive into RPM spec files and whatnot 😢

Yes, to be honest, I'm not that enthusiastic about it either. 🥵

but! maybe we can just include it as part of the kernel package itself (as if it was in-tree), just like any other kernel modules, and not make any extra package. That sounds best to me because we'd:

• Leverage the existing packaging process.
• Keep this repo about a single package: the kernel

That should work! I think Cachyos also builds their package intigrated in one linux-cachy-nvidia-open, so we could name the package according to that pattern, if build with _nvidia_open.

And if people want to go the DMKS way, nvidia-all is there for them 🤔 ? Although currently it only supports Arch.

Sorry, I think I wasn't clear. I meant that the distribution can't provide in-build modules with a custom kernel (tkg) – therefore, DKMS is practically the only option at the moment. Of course, you could create an integrated module with nvidia-all (unfortunately, only for Arch 😮).
Sorry, I just realized I'm repeating myself, but here are a few points why:

• It's handy.;)
• I love nvidia-all, but we probably shouldn't bind users to use it.
• Users should also be able to use stock distro packages.
  this as an alternative solution for quick troubleshooting (if something breaks)

not everyone uses nvidia-all.

tkginstaller would be there as a single entry point hehe

lol, 👍 💯

small comment:
Personally, I find this interesting for the following reason: If I compile the Nvidia module with the kernel direct, I can sign it because the kernel sources are available at runtime. With nvidia-all, I would first have to download the kernel sources, which makes things a bit more complicated. This also led me to the topic of signing and Secure Boot.
I don't know to what extent this might be a prerequisite for other solutions against anti-cheat systems in games.

update:
I've looked at it again. I think a third package is the right solution to resolve dependencies and package conflicts. Should someone decide on a different Nvidia package, they would have to reinstall the entire kernel package.

I understand what you mean better now. Would you have to completely recompile the kernel with every Nvidia update; Since this isn't separated in linux-tkg – unless he uses nvidia-all in the future – yeah, it's rather cumbersome. 🤔

Nevertheless, I think it's a good addition.
To avoid headaches, we should only support this, let's say, from kernel 6.18(lts) and nvidia 580+ onwards. We could leave it completely disabled without promt and only enable it via .cfg when needed.

[AdelKS]

I've looked at it again. I think a third package is the right solution to resolve dependencies and package conflicts.

I was thinking of installing the nvidia modules (the .ko or .ko.zst) files with the kernel's in-tree modules, i.e. in e.g. /lib/modules/6.18.7-tkg-eevdf-llvm.

Now, about the package conflicts, if DKMS or regular nvidia installer script tries to install the module files in that same folder, yeah... But the whole point of having linux-tkg include the Nvidia driver kernel module is to not use either.

Should someone decide on a different Nvidia package, they would have to reinstall the entire kernel package.

True, the same goes for any in-tree kernel module. The kernel gets updated every week, not a huge loss honestly. And everyone here goes for latest and greatest hehe

Nevertheless, I think it's a good addition.

I agree, now we are discussing included with the kernel as if it's in-tree, vs a separate package. I am all in for the former because I see that it's realistic to support other distros, and we could even ship it by default in the CI builds (and tell that nvidia is already there), basically make nvidia Just Work ™️ , just like AMD.

I just realized... Isn't Nvidia shipping user-space and kernel-space utilities as part of the same package actually ? If so then the package conflicts you are talking about are complete show stoppers and you would be absolutely right on that, at least on distros other than Arch: how does it work in arch actually ?

If I compile the Nvidia module with the kernel direct, I can sign it because the kernel sources are available at runtime.

Not sure if you are aware of that, but secure boot does not require module signing: the moment you use signed UKIs you are good. Now, if it's data-at-rest security you are after, you are much better off with full disk encryption on the root partition at least (can exclude /home if you want): every block is encrypted and signed to be tamper proof. This therefore covers every file, including the kernel modules. I understand that module signing is useful for those who don't want to encrypt their entire root filesystem, but the moment they keep their private key in their unencrypted filesystem, it makes no sense anymore.

[damachine]

I agree, now we are discussing included with the kernel as if it's in-tree, vs a separate package.

Regarding the In-tree vs. Separate package discussion:

• On Arch, we have to be careful with file conflicts. If we put the .ko files directly into the kernel package, we might run into issues with nvidia-utils dependencies or users trying to switch e.g. to nvidia-all later. A split package (building both linux-tkg and linux-tkg-nvidia-open from the same PKGBUILD) is the cleanest way for Arch users.

• For RPM and DEB, I agree that 'In-tree' is the way to go to avoid the nightmare of maintaining extra .spec or control files. We could have the best of both worlds:
  RPM/DEB: Bundle the .ko files directly into the main kernel package.
  To avoid dependency hell, we can place the modules in the /updates/ or /extra/ subfolders and add a Provides: nvidia-kmod (or equivalent) to the package metadata. This makes the NVIDIA driver 'Just Work' like an AMD driver—signed and matched out-of-the-box. But Honestly, I'm not that versed in RPM and Deb-like distros <X

Not sure if you are aware of that, but secure boot does not require module signing: ...

thx, i agree that makes perfect sense what you say 💯
To clarify my point on signing/secure boot: security itself wasn't my primary focus when I started this, but rather the Anti-Cheat (AC) aspect.

Regarding signing kernel modules: nvidia v4l etc.:

Please excuse me if I'm wrong and talking bullshit. While I'm not an expert in AC internals, the trend in gaming is moving heavily towards Kernel-level verification.

If we want Linux to be taken seriously as a secure gaming platform, providing a signed kernel and signed modules is a huge step. It ensures a 'Chain of Trust' that modern AC systems look for. By signing modules during the TKG build, we're future-proofing the setup for users who need Secure Boot or might face stricter and maybe a prerequisite for other solutions against AC systems requirements down the road. It's about giving the system a 'verified' status that is much harder to achieve with standard unsigned DKMS builds.

[AdelKS]

(building both linux-tkg and linux-tkg-nvidia-open from the same PKGBUILD) is the cleanest way for Arch users

I agree. I just checked and nvidia-utils doesn't depend on nvidia-open, few. And the user-space drivers are inside of that thing. Okay everything is clear to me now on Arch.

We could have the best of both worlds [...] I'm not that versed in RPM and Deb-like distros <X

Sounds good, I'll look into it eventually myself, don't worry I am not going to ask you to look into it :P But I will look deeper into this PR to see how you can make my life easier on that front.

It ensures a 'Chain of Trust' that modern AC systems look for.

I am sorry to break it to you but Anti-Cheat don't care at all about the security of our system, they just want cheaters to not use kernel level cheats, which means they want secure boot enabled with Microsoft's keys only ...

Let's step back a bit, what's "secure boot": there's a chip on the motherboard that acts as "hardware security module", the TPM. In the scope of "secure boot", when it's enabled, the TPM receives the binary blob (the kernel) that the BIOS wants to boot and checks it signature against a public key that got saved in its memory, if it checks out, it allows booting it, otherwise it refuses.

This chip has two modes:

1. "setup mode": secure boot is off, you can enroll / save any public keys you want in it, which automatically locks it. You can reset the TPM into this mode in the BIOS.
2. "locked mode": no key can be enrolled anymore, secure boot can be enabled: i.e. make the TPM always check the binary that wants to boot and only allow those who are signed with the enrolled keys to boot.

Now, games can query the TPM and ask it if it's locked with secure boot on, and which public keys got enrolled, and I expect the games who go this far check that the TPM answers with a single key, Microsoft's key. So they can be sure the Windows kernel that got booted is the vanilla Microsoft one and not a hacked variant with kernel level cheats (the hacker does not have the private key of Microsoft to sign their hacked kernel version).

All of that to say, that Anti-Cheat systems cannot do the same on Linux, unless they start looking for vendor keys like Canonical's, RHEL's, Archlinux' (???). Our own generated signinig keys that we use to sign the kernel and its modules, to enable secure boot, are not useful at all for Anti-Cheats. You can only theoretically improve the security of your computer with that :P

[damachine]

I am sorry to break it to you

I definitely learned something new about how ACs handle TPM queries and Microsoft keys. It seems the 'Chain of Trust' on Linux is indeed a much steeper hill to climb than I thought.

Sounds good, I'll look into it eventually myself, don't worry I am not going to ask you to look into it :P But I will look deeper into this PR to see how you can make my life easier on that front.

I'm glad the Arch split-package approach is clear now! I'll focus on getting the local patches and the codebase ready so it’s as easy as possible for you to look into the RPM/DEB side 😄 I m happy if I can help 🐸

Yeah, take all the time you need to look through the PR for what is useful and doesn't give us headaches or unnecessary maintenance. ;)

PR Update: Scope the PR down to nvidia-open only:

cleanup: remove v4l2loopback, _RESIGN_AFTER_STRIP and _install_signing_keys

• Remove v4l2loopback out-of-tree module integration
  no maintenance burden needed here.

• Remove _RESIGN_AFTER_STRIP: re-signing all in-tree modules after
  strip is a niche edge-case unrelated to nvidia-open.

• Remove _install_signing_keys: Secure Boot does not require module
  signing (signed UKIs suffice).

[AdelKS]

Thanks for removing v4l2loopback, can you move those commits to a new PR, I'll have a look at it after this one. it may make everyone's life better indeed.

Back on the main PR, the idea is to put as much code in prepare as possible to make it re-usable for other distros, e.g:

• The code that asks for, pulls then extracts the tarball
• The patching
  • Do they patch code from the tarball or code in-tree ?
    • Note that in prepare there's this tkgpatcher function we use.
• The building
  • Are the tarball's files merged within the kernel sources folder ? i.e. after we extract the Nvidia sources, does a simple make modules with the kernel's own Makefile build the Nvidia modules along with the rest ?
  • I am still thinking using an approach of as-if the Nvidia modules are in-tree, compile the kernel as usual, and in the PKGBUILD, during packaging, you extract out those modules into a separate package.

I am not fully aware if this is possible, hard to achieve, etc... but it would make my life easier for other distros afterwards hehe. So I would like to hear your thoughts on the matter

Great work, looking forward to working with ya!

[damachine]

Happy to hear, looking forward to working with ya, too! <3

Yeah, sorry — I was a bit too eager. I realize that changing too much at once wasn't the right approach. I've saved those changes in a separate branch for now and will open a new PR for it. ;)

Let's see the main PR:

• The code that asks for, pulls then extracts the tarball
• The patching

Agreed, I'll move tarball fetching/extraction and patching into the shared prepare script. Currently the download/extraction is handled by makepkg's source=() array, so for install.sh I'd need to add wget + tar logic to the shared prepare script. The version prompting (_set_nvidia_open) is already there.

The patches only touch files inside the NVIDIA tarball, not the kernel source tree:

• nvidia-drm/nvidia-drm-linux.c — enable atomic modesetting by default
• nvidia-drm/nvidia-drm-os-interface.c — same feature, matching change
• src/nvidia-modeset/Makefile — IBT support (-mharden-sls=all)
• kernel-open/nvidia-uvm/ — kernel-version-specific build fixes

I can look into integrating these into _tkg_patcher — though it would need
to support patching against the NVIDIA source dir instead of the kernel source dir.

• Are the tarball's files merged within the kernel sources folder ? i.e. after we extract the Nvidia sources, does a simple make modules with the kernel's own Makefile build the Nvidia modules along with the rest ?

No. Currently the NVIDIA tarball is extracted alongside the kernel sources (into $srcdir/NVIDIA-kernel-module-source-<version>/), not merged into them. The NVIDIA modules are built with a separate make call that points back at the kernel build tree via SYSSRC/SYSOUT — the kernel's own make modules does not touch them.

• I am still thinking using an approach of as-if the Nvidia modules are in-tree, compile the kernel as usual, and in the PKGBUILD, during packaging, you extract out those modules into a separate package.

I looked into this Nvidia Build , making it truly in-tree (where make modules just builds everything together) would be very difficult because:

1. NVIDIA uses its own build system — their kernel-open/Makefile has a custom conftest infrastructure that probes kernel features at build time, generates headers, and manages dependencies.
2. Kconfig integration — we'd need to create Kconfig entries for each NVIDIA module and wire them into the kernel's menuconfig. This could break with every NVIDIA driver update.
3. Conftest replacement — NVIDIA's conftest system checks for ~200+ kernel symbols/features and generates conftest.h headers. We'd need to replicate or replace all of that within the Kbuild framework.
4. Maintenance burden — every new NVIDIA driver version could change conftest checks, add/remove modules, or restructure the build. We'd be fighting upstream on two fronts (kernel + NVIDIA). 🥵

I am not fully aware if this is possible

What I think is realistic and still helps with other distros:

• prepare: Move tarball download, extraction, patching, and version prompting there → reusable by install.sh
• Build: Keep the separate make call against the NVIDIA source tree — this is the NVIDIA-supported way (same approach as DKMS). A single make modules building everything together isn't feasible without rewriting NVIDIA's entire build system (Kconfig entries, conftest replacement, etc.) X)
• Packaging: The .ko think output files can go wherever we want:
  • Arch → split package (clean dependency handling)
  • RPM/DEB → copy the .ko files into the kernel's module dir (e.g. /lib/modules/<version>/extramodules/) as part of the same package — no separate spec/control file needed

The build stays separate, only the packaging differs per distro. Would that work for you?

[AdelKS]

Thanks for taking the time to answer my questions.

So this package is actually very independent. I had a different mental image of how it works. Thanks! Yeah exactly let's go with what you see works best.

Maybe it actually just makes sense to have a entirety separate script file for it instead of prepare ?

[damachine]

Ah,

Adel sorry, I forgot to thank you for taking the time for me!! 💪

I'm currently pondering an important question: how do RPM/DEB distos handle dependencis? Let's say someone has the brilliant funny idea of ​​adding the driver from today's 595, for example. I strongly suspect that these distributions don't have such up-to-date packages deps. One possibility would be to lock the version to a specific one. So, I need to examine this more closely.

I think we need a little more time now.

[AdelKS]

RPM/DEB distos handle dependencies?

You are saying that the user-space utilities can only work with a specific kernel module version ? In any case, I don't see the DEB/RPM support coming any time soon haha, maybe never xD. That's why I was pondering if we should not just promote nvidia-all more, and maybe have it have a tighter integration with linux-tkg or something, basically to answer the need you had that made you open this PR.

I will look into their user-space Nvidia packages.

[damachine]

Looks like a nightmare to integrate and Maintaining see: https://salsa.debian.org/nvidia-team/nvidia-graphics-drivers

As I understand it, these are:

• The rules file: This is the equivalent of your build() and package() functions in PKGBUILD. It controls how make is called.

• The control file: This contains all the dependencies (depends, providers, conflicts).

• The .install files?

I have no idea what else needs to be considered to keep this properly successful integrate.

Perhaps to salvage this PR is that we concentrate on a clean pkbuild Arch only intigration. :(
Assuming a clean, compliant integration, it should run like clockwork there.

[AdelKS]

Yeah I expected as much. Let's go for Arch only then we'll see.

[damachine]

Took another closer look at this and honestly, the maintenance burden is just too much. The problem is that NVIDIA's open modules break against kernel changes on a regular basis. almost every new kernel version needs its own build-fix patches, and each one has to be maintained separately. With the number of kernel versions linux-tkg supports, that workload just blows up. 🥵

Linus was right with his famous "NVIDIA, f*** you", they still work against the kernel rather than with it. The open modules are a step in the right direction, sure, but in practice something changes in the internal APIs with every kernel release and NVIDIA doesn't keep up in time. For us that means: constantly writing new patches, testing them, and hoping nothing else breaks along the way.

For a project like linux-tkg that covers this many kernel versions, it's just not realistic to keep up with long-term without it becoming a full-time job. DKMS or nvidia-tkg are the better paths here, they handle compatibility per system on their own.

Big thanks @AdelKS ❤️ for pushing on this with me and for the input along the way. Your concerns turned out to be spot on, and I'm sorry for the extra time you spend. it had sounds to good.

What might still be worth exploring is integrating nvidia-all(more) as an option; but building the modules in-tree directly alongside the kernel across this many versions is something we shouldn't put on ourselves. If it's okay I'll leave this PR open for now, maybe we find a better angle down the road or NVIDIA gets their act together at some point Nova. Not holding my breath, but stranger things have happened. 🐸

[AdelKS]

Yeah I understand perfectly what you are saying. Happy to have looked at this with you. I'll leave what's next to you :D

[ptr1337]

Im not sure, if this really makes sense for linux-tkg since people would need to handle the versioning for the nvidia module manually, which isnt required at tkg.

For distributions like Archlinux/CachyOS this is a good way ensuring the module compiles and works properly, since they can be distributed directly with the kernel. See as example nvidia-open-lts/nvidia-open package in the arch repository.

[AdelKS]

We can pin nvidia versions per kernel version, with a manually maintained dictionary. Don't count on me to do that though hehe

[damachine]

fair point on the versioning. one option would be a pinned dictionary like the existing _rt_subver_map, mapping kernel versions to tested nvidia versions. user wouldn't need to handle it manually, just works out of the box. obviously needs maintenance but it's a known pattern in the codebase already.

e.g

_nvidia_open_version_map=(
  ["6.18"]="590.x"
  ["6.12"]="580.x"
  ....
)

will look into it Adel xD — and yeah, the goal was never to turn linux-tkg into a nvidia patchwork, just a clean optional integration that doesn't become a maintenance nightmare

[AdelKS]

will look into it Adel xD — and yeah, the goal was never to turn linux-tkg into a nvidia patchwork, just a clean optional integration that doesn't become a maintenance nightmare

Haha yeah this is absolutely fine, we can integrate it with the arch build ci so it checks and releases the latest version with Nvidia modules, and maybe earlier LTS versions later down the line.

I am unhappy a little that we make Nvidia users' life a little easier, Nvidia doesn't deserve more users, but it is what it is :P

[damachine]

Huge thanks to @AdelKS and @ptr1337 — not just for the review, but for genuinely engaging with the idea and being willing to go there if a clean solution had emerged. That means a lot.

As you already said linux-tkg users want to stay in control of their setup, and forcing a pinned NVIDIA version into the build goes against that spirit. Furthermore, Arch-only feels like it defeats the purpose for a project like linux-tkg that's meant for everyone.

The maintenance burden is just too real for now, so DKMS and nvidia-all are the better path here. Maybe NVIDIA surprises us someday with Nova.

Feel free to close this PR if it's in the way - I don't mind either way.

We might explore an unofficial linux-tkg staging fork on the side — a playground for extended options like this that don’t belong here. just an idea. 🐸

KISS

[AdelKS]

Let's leave it around, nothing is pushing us to close PRs :P