switch to negativo17 for nvidia akmod

[bsherman]

It seems RPMfusion has dropped the 470 driver ( https://admin.rpmfusion.org/pkgdb/package/nonfree/nvidia-470xx-kmod/ ). So, it may be time to switch to negativo17 for nvidia.

@KyleGospo and I have previously discussed this. The negativo17 packaging allows more granular installation of only desired components. For example, in ucore I already use negativo17 as it allows only installing nvidia-driver-cuda which is just the driver and CUDA support, as is proper for a server. RPMfusion's package pulled in all of Xorg and Wayland. In addition, negativo17 provides a cuda-gcc package to aid users needing (nvidia's CUDA does not yet support GCC 14 which is current in Fedora).

We were not keen to move to negativo17 before now, but because they only package the latest drivers, while we were using both latest and legacy 470 drivers from RPMfusion.

With RPMfusion's orphaning of the 470 package, I believe we should now move to negativo17. This will mean dropping the 470 driver... but it's orphaned upstream, so I unless we want to maintain the package, I don't think we can continue providing it in good conscience.

I'll prep the appropriate PRs for this.

[dylanmtaylor]

As you said, https://negativo17.org/repos/nvidia/fedora-40/x86_64/ does not seem to have a 470 driver, but looking at https://negativo17.org/repos/nvidia/fedora-39/x86_64/ they also no longer have v545. It seems to only be the very latest version. Is this desirable? It might mean that images tagged with -550 will no longer get new updates when 555 comes out for instance and we will have to update build logic more often.

"No alternatives system, only the latest version which integrates CUDA support is available. For older releases nouveau works great; and anything below a GeForce 8xxx it’s in my opinion too low end to play anything modern. And Quake 3 and Doom 3 work greatly with nouveau, so that’s not a case!"

Shipping just the latest one might mean we can just have -nvidia without a version tag like -550 though.

[dylanmtaylor]

How would we implement #82 with this?

[KyleGospo]

My vote is ship whatever Negativo supports, with any lost hardware support being cost of doing business with owning a Nvidia GPU, and focus on supporting NVK as the path forward, which is 16xx/2xxx and up due to Nvidia's actions and supported in main without an HWE.

Leave the proprietary stuff as an option once NVK is performant, but make it an afterthought and intentionally less easy to find/select.

[dylanmtaylor]

My vote is ship whatever Negativo supports, with any lost hardware support being cost of doing business with owning a Nvidia GPU, and focus on supporting NVK as the path forward, which is 16xx/2xxx and up due to Nvidia's actions and supported in main without an HWE.

Leave the proprietary stuff as an option once NVK is performant, but make it an afterthought and intentionally less easy to find/select.

So I looked at the docs for Negativo and it does look like the open variant is supported:

akmods

Check which version you have installed:

# modinfo -l nvidia
NVIDIA

Change the type of modules you want to use and trigger a rebuild and a reinstall:

# sed -i -e 's/kernel$/kernel-open/g' /etc/nvidia/kernel.conf
# akmods --rebuild

Now check again the license and you should see that it has changed to MIT/GPL:

# modinfo -l nvidia
Dual MIT/GPL
# reboot

To switch back, change the configuration again and then trigger the same process for rebuilding installing:

# sed -i -e 's/kernel-open$/kernel/g' /etc/nvidia/kernel.conf
# akmods --rebuild
# reboot

[bsherman]

Yes, negativo17's nvidia supports open variant, which is a plus. It is something to be considered in the future.

[dylanmtaylor]

Yes, negativo17's nvidia supports open variant, which is a plus. It is something to be considered in the future.

I'd love to see us offer both open and proprietary nvidia options when we do the transition to negativo17's repo. :)

[Sharkitty]

Leave the proprietary stuff as an option once NVK is performant, but make it an afterthought and intentionally less easy to find/select.

Let's keep in mind that despite the great progress that NVK brings for the average user, CUDA is still required for professional work in some fields. It is enough of a pain already as it is to deal with the proprietary drivers. One of the great aspect of having an open source stack, is that there would no longer be a need to have a variant to use it. While users who still rely on proprietary drivers, will still need a variant (i.e., it's a consideration before you even install anything, as it currently is. Please don't make it worse).

However, it would be fair to adjust the way it's presented to users, by telling them the open source stack is the recommended way to use uBlue-OS and its derivative, and that the Nvidia image is only for those who still require proprietary drivers.

[bsherman]

Upon further testing, I discovered this set of changes is disabling wayland for GDM. Obviously this is not acceptable.

I am reverting and will do more testing.

[bsherman]

The changes made in the PRs for this seem to have caused GDM to disable Wayland.

So I reverted:

• Revert "feat: swap to negativo17 as nvidia driver source (#170)" #172
• Revert "feat: swap to negativo17 as nvidia driver source" hwe#233

This requires further testing before a merge can occur.

[dylanmtaylor]

@bsherman can you elaborate on the need to revert the patches that were merged for this work? Is there a way we can reintoduce this patch and fix the GDM issue?

I chatted about this on #ublue-dev on Discord as well, but I think that it would be great to revert those reverts to get the 555 driver which is currently in 40/39 in the negativo repos right now.

Some key points I would like to make:

• Negativo17's treating it as stable in their repositories due to the huge demand and major improvements.
• Many people want it even if it's a beta because 550 is extremely bad to use.
• Due to this, I would love to see ublue make an exception for 555, specifically, and ship it early for Fedora 39 & 40

Niklas mentioned that people will say "Why would you ship a beta driver? / The new driver broke my computer!" etc.
My response to that would be "Why would we choose to ship a known broken driver over one with a fix that anyone using their computer for even the most basic web browsing will notice in under an hour of use?"

I would appreciate it if we can move forward with the negativo17 repos and finally get a working Nvidia driver experience on Wayland. Yes, I'm aware that X11 'works', to a degree.

Thank you.

[castrojo]

What's stopping you from merging this in a fork and reporting feedback?

Every time you send one of these "I want new nvidia drivers" messages it clogs up discord and github and actually slows every thing down.

[bsherman]

@dylanmtaylor I'm a bit confused by your comment.

The reason for reverting is documented in my previous comment which you acknowledged in a discord post. This has nothing to do with package/driver versions.

Why is this not done yet? This is an open source, volunteer powered effort with varied priorities and tasks. This one did get set back for a bit while we solved some other things, and also because life (work and personal) takes precedence.

On that note, I am tired of your requests for faster updates to the next new/beta/pre-release version of package X and of PRs which clearly weren't tested.

If you want to help by providing tested solutions via PR, I still welcome it, but your past contributions have caused me to be skeptical.

[dylanmtaylor]

What's stopping you from merging this in a fork and reporting feedback?

I haven't really considered maintaining my own fork of the project. That might be a better approach to contribute changes going forward, and I'll consider doing so.

On that note, I am tired of your requests for faster updates to the next new/beta/pre-release version of package X and of PRs which clearly weren't tested.

I apologize if that has been burdensome. That wasn't my intention at all. The biggest reason for me to want these new versions has been in hopes of having a functional graphics stack on Wayland on Nvidia hardware. If you look at the requests I made, I have specifically requested new Xwayland releases, Nvidia releases, and Fedora 40 (with patches to support explicit sync with these drivers) in the hopes that explicit sync finally works correctly on Nvidia hardware. This has been a painpoint not just for myself but for almost everyone running Nvidia on Linux for a very long time. If you follow any of the Linux-related subreddits, it's clear that the excitement around explicit sync and the Nvidia 555 driver series is very pronounced and I'm not the only one who feels this way. I don't want to slow down the project and create more burden though. I'll try to exercise more patience regarding new driver/OS releases.

My contributions have all come from a good-faith effort to see the project improve. While this is very opinionated, I feel that the largest area for improvement in recent years on desktop Linux including has been hardware enablement, and I think that there will be immense value to users when we reach a state where thins just work out of the box.

[m2Giles]

This is now completed and Nvidia drivers are now sourced from Negativo17.