void-linux
New package: nvidia-open-dkms-570.169
Testing the changes
- I tested the changes in this PR: YES
Local build testing
- I built this PR locally for my native architecture, x86_64-glibc
Comments Built and tested on 6.12.16 as soon as the #50458 landed No longer WIP since this release is out of beta and is now the recommended driver for supported devices, which are Turing and newer, so 16-series and newer of the GeForce lineup. Closes #51384 Perhaps package info should mention which GPUs are supported
Thanks to mike7d7 for original template and PR #51538
Being not really comfortable with git cli I tried to preserve mike's contribution (and failed miserably as can be seen above)
Just double-checked by cloning the pr as described in contributing.md and re-ran per-stage ./xbps-src {stage} -f -K nvidia-open-dkms to verify no issues preset.
Understanding that this smells of blind editing with no testing done, here's my xbps-query nvidia-open-dkms
architecture: x86_64
changelog: https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/CHANGELOG.md
filename-sha256: 8380e0918aa0db31a732331d378116859938b07afa1f8fecfe32662e313ff607
filename-size: 14MB
homepage: https://github.com/NVIDIA/open-gpu-kernel-modules
install-date: 2025-03-02 21:18 MSK
install-script: 950B
installed_size: 100MB
license: GPL-2.0-only, MIT
maintainer: mike7d7 <[email protected]>
metafile-sha256: f57e061a8bdbdda880176a90028ef935820d92799c29377065e3f5017c17b046
pkgname: nvidia-open-dkms
pkgver: nvidia-open-dkms-570.124.04_1
remove-script: 947B
replaces:
nvidia-dkms>=0
repository: /home/jkkt/Projects/void-packages/hostdir/binpkgs/nvidia-open
run_depends:
dkms>=0
nvidia>=0
short_desc: NVIDIA Linux open GPU kernel module source
state: installed
And dkms make log: make.log
Oh, and also this makes nvidia package (in current state) report not satisfied dependency in form of nvidia-dkms, as that's replaced by this driver. So far I'm not up to speed with xbps-src and templates enough to understand how exactly that should be fixed.
@abenson If I may bother you, since you're the maintainer of the proprietary driver package, what would be the appropriate way for dealing with this conflicting files issue? Especially considering that not all cards supporting 570.124.04 can run the open-source version of it.
Would adding conflicts="nvidia470-dkms>=0 nvidia390-dkms>=0" be enough?
Would, perhaps, transferring this into the main package while defaulting to open for newer versions and leaving the proprietary version symlinked (like 390/470 versions are) be preferred? (Although then the question of these having different licenses arises too)
While at it, anything else you may be able to suggest or would require for this to go through?
Hello,
While I do not have anything more to add as of now, I'd like to answer your question about the conflicts situation.
No, it would not be enough, the nvidia470 & nvidia390 respectively support older nvidia cards, but there exist newer nvidia cards that are still not supported by the open driver, for example the GTX 10 series.
about how that could go down well, personally I'd look into having an equivalent proprietary package(if there ain't one already) and have them conflict each other, with the open one picked as a default while adding an appropriate section in the void handbook for those cards in between, but that's me so take everything with a spoonful of salt.
Definitely ain't a simple change though, so practice patience, and just keep bumping those versions, eventually attention will be brought to this topic out of necessity.
Hi, thanks for your reply.
Regarding the similar proprietary package that would conflict this one — to my knowledge, that's partially how "replaces" here operates, and is about as much as I can do without messing with abenson's nvidia template.
Adding this template into conflicts section for nvidia390-dkms, nvidia470-dkms and nvidia-dkms subpackages would be possible but I'm unsure if that's the correct way to implement this.
I'm also unsure how to implement the dependency:
Currently nvidia-open-dkms lists nvidia as a dependency, while nvidia-dkms does not, as that's a subpackage, thus I'm unsure what happens if one tries to install nvidia-dkms without nvidia already installed and whether it'd behave the same way with an external template with circular dependency.
As I mentioned above, I am also unsure whether it'd be better to add the open dkms module as a subpackage, and what do do with the license being set to nvidia proprietary in that package. Another thing that bugs me about the licenses is that it theoretically puts this template into the main repo while the nvidia one is in nonfree one.
Making people manually choose the module could be a possibility, I suppose, but it'd be inconvenient as heck. We could probably automate it to some degree via querying which device id are enabled unless explicitly called for (for now the readme provided by the upstream lists the pci device ids of supported devices) — though that's me fantasizing the possibilities, I have little to no idea whether xbps is capable of operating on that level.
The idea is that if you install nvidia you get all of its dependencies including nvidia-dkms which you rightfully pointed that it's the proprietary counterpart of this package.
I also understood that currently the script replaces nvidia-dkms.
What I would want to achieve:
installing nvidia -> installs the open kernel driver.
Users that want/need the proprietary driver because of CUDA support or because their card is not supported by the open one -> instructed by the handbook to install the proprietary dkms package before installing nvidia or provide a secondary nvidia template that achieves the same but uses the closed kernel driver.
How I'd achieve that, here is what I found in the manual:
As a special case, virtual dependencies may be specified as runtime dependencies in the depends template
variable. Several different packages can provide common functionality by declaring a virtual name and version
in the provides template variable (e.g. provides="vpkg-0.1_1"). Packages that rely on the common functionality
without concern for the specific provider can declare a dependency on the virtual package name with the prefix
virtual? (e.g., depends="virtual?vpkg-0.1_1"). When a package is built by xbps-src, providers for any virtual
packages will be confirmed to exist and will be built if necessary. A map from virtual packages to their default
providers is defined in etc/defaults.virtual. Individual mappings can be overridden by local preferences in
etc/virtual. Comments in etc/defaults.virtual provide more information on this map.
Thus, I would have both the current proprietary dkms provide the dependency for nvidia, with the open one used by default, and users could instead opt into using the proprietary one. As far as whether this decision could be automated cleanly eh, I am gonna assume not cause otherwise they wouldn't have the two older nvidia packages and they'd implement the logic to pick a driver into the nvidia package itself. Probably amounts to too much effort and spaghetti to make it worth.
Why?
The nvidia open kernel driver is now the default supported by the respective newer cards, (20 series+), we are going against the default by supplying the proprietary one out of the box.
I must have overlooked that section, thanks for pointing it out to me
Made this patch (to be applied when both nvidia-open-dkms and nvidia templates are up-to-date, i.e. this PR locally merged)
Renamed nvidia-dkms dependency into nvidia-proprietary-dkms, which provides new virtual dependency: nvidia-meta-dkms, also provided by nvidia-open-dkms (default) Removed "replaces=" section from nvidia-open-dkms in favor of "provides=" and "conflicts="
The installation order and specifically dkms pkg section in nvidia template are not adjusted here, I am wondering if messing with that order by installing the nvidia-open-dkms contents way later may break anything.
Am testing 570.144 locally since we haven't merged the proprietary version yet. Had to change the distfiles url to nvidia's site because release is still N/A on gh
Am testing 570.144 locally since we haven't merged the proprietary version yet. Had to change the distfiles url to nvidia's site because release is still N/A on gh
I've an open PR for 575 which I'll keep updating till the next production release, just saying.
Tried to rename the branch, that closed the PR, then restored, local git refused to push into it, so I tried to recreate the branch, but then couldn't re-open due to force-pushing. Sorry for the spam. 470 and 390 dkms builds are still conflicting with this as I haven't changed the "replaces" into "conflicts" due to how update process ends up running, instead keeping the easier-to-test version.
Added patches sourced from arch, although I haven't found the necessity of them in my own testing, both seem to not break things and be used commonly
Hi. I am interested in testing this. How do I switch from the proprietary drivers to these ones? I already now how to build the package, so instructions after that would be appreciated. Thanks.
Edit: Instructions are in the template.
Hi, any ideas when this might get merged in?
Unfortunately this isn't ready for merging. I'm essentially bumping versions, running daily with this (it installs and runs fine but upgrading is a bit of a nuisance, check the template file for instructions) and am waiting for feedback/guidance from maintainers.
At the very least, there is still an open question on how to handle the versions and the choice between open kernel modules vs proprietary ones (open support the newest cards but don't support older ones. proprietary supports older cards but not the newest).
^
But I'd suspect the answer is soon this will get attention. Nvidia themselves will now treat the open kernel modules as the default, it's only natural to expect distros to transition, and that doesn't exclude void.
Use this build if you want it now, otherwise be patient.
I went ahead and installed it about 5 days ago. Kinda needed it as I upgraded to a 5080. Haven't had any problems so far.
Added the "conflicts" field, but "replaces" is kept for ease of installation for testing
@Tyfuzzle I am using 5070 TI and can't get the nvidia drivers to work properly. Is this necessary for newer cards? Do I need to set the nvidia-drm.modeset=1 in the kernel params still?
Would really appreciate it if you could give some instructions on how you got it to work
@vikigenius I only followed the instructions on the template. Didn't need to do anything else. As far as I'm aware, the closed source DKMS module doesn't support newer cards. Haven't ever used any kernel parameters. If you're skeptical that it might be breaking something, remove the parameter. If it doesn't change anything, put it back.
@Tyfuzzle thanks I installed this package but I am getting issues with running niri a wayland compositor
None of the following EGL extensions is supported by the underlying EGL implementation at least one is required EGL_EXT_device_query
I created an issue here https://github.com/YaLTeR/niri/issues/2095
But I am not sure, if the error could be because of this package? Do you use wayland or xorg?
@vikigenius
wayland
While not using a 50-series gpu, I'm using wayland with this in a daily system, and was able to install and launch niri (and exit from within it)
Regarding the drivers, even though Blackwell architecture (50-series) is not officially supported by the proprietary driver, you should still install the nvidia package which pulls in the proprietary kernel driver in form of nvidia-dkms dependency and then, automatically replacing only the nvidia-dkms package in the process, this one. This process is currently necessary to install the necessary libraries, firmware for some cards, and other misc. files, provided in the nvidia template, i.e. contents of nvidia-opencl and nvidia-libs.
The nvidia package, along with it's dependencies, is in nonfree repo, since the license for it isn't open. The repo can be added via installing the void-repo-nonfree package (unless you want to manually add it). If you plan on using 32-bit packages, i.e. default variant of wine, steam, etc., you'd also want void-repo-multilib and void-repo-multilib-nonfree (i.e. for 32-bit nvidia libraries)
To verify that the 'open' kernel driver installed, you can use modinfo nvidia | grep license and cat /proc/driver/nvidia/version commands. The first should report "Dual MIT/GPL" and the latter NVRM version: NVIDIA UNIX Open Kernel Module for x86_64 570.169 Release Build ...
To use this driver, you should also check that nouveau driver isn't loaded, perhaps a system restart would be the easiest way to make sure the blacklist got applied (it should as part of installing this package, you can check that file /usr/lib/modprobe.d/nvidia.conf reads blacklist nouveau)
You can check the EGL extensions availability with command eglinfo available in mesa-demos package and visually validate with, say, glxgears in the same package (would require a running X server, Xwayland would work too). The specific capability you listed, EGL_EXT_device_query should be at the top of the list.
@JkktBkkt thanks a lot I did manage to get it working reasonably well.
I do run into this issue intermittently https://bbs.archlinux.org/viewtopic.php?pid=2254844#p2254844
Random crashes for apparently no reason at all. The entire system freezes up, I can VT switch to a different TTY but the login there hangs there as well. It's as if the OS itself crashes
After kernel upgrades am I supposed to rerun this somehow, that's the only thin I can think off since this seems to be happening more and more recently.
@vikigenius can't really say whether that is actually caused by the nvidia-open driver. There is some hope that the same fix that was applied in the 580 driver branch to fix the vkps/llama.cpp issue you've mentioned made it into the 570.181 release as well, but I haven't tested it. The other user also mentioned disabling integrated graphics (in UEFI) in the thread you've linked, perhaps that would work?
Regarding updates:
- Minor kernel changes get handled automatically: when you install a new kernel version through xbps, hooks for kernels get run — building DKMS modules, meaning Dynamic Kernel Module Support (like this one), get rebuilt automatically, kernel can get signed, initramfs for it gets generated, etc. Similar processes exist for removing kernel versions, for clean-up.
- Major kernel versions can (but not necessarily will) introduce incompatibilities. The same hooks will still run but it can result in a module that doesn't build or builds and is misbehaving in one way or another. In that case you'd need to have a compatible version of the driver installed and/or roll back to kernel version that is compatible with the one available.
- Driver updates need to be handled manually in the current state. See the contents of the template for an outline of what needs to be done.
@Tyfuzzle thanks I installed this package but I am getting issues with running niri a wayland compositor
None of the following EGL extensions is supported by the underlying EGL implementation at least one is required EGL_EXT_device_query
I created an issue here YaLTeR/niri#2095
But I am not sure, if the error could be because of this package? Do you use wayland or xorg?
Sorry for not responding sooner. Not that it matters because you mentioned youve got it working now. I'm using x11 at the moment.
I've ran into my own problem though now. The main nvidia package has upgraded to 580 but this PR is still on 570 so now I'm stuck in terminal with xinit crashing (or I assume I am because of incompatibility between the driver and kdms module version).
Edit:
Output of /var/log/Xorg.0.log
Edit 2: It took over an hour, but I managed to salvage it. For some reason, I had all nvidia 570.181_1 packages cached except nvidia-libs-32bit, so I managed to roll back everything but that. I ended up getting by checking out the commit for 570.181_1 for in void packages so I could build it myself. Bit of a pain, but Steam boots now.
upgraded to 580 but this PR is still on 570
@Tyfuzzle glad you figured this out.
For anyone else in a similar situation, here's the gist of it:
I've tested 580.76.05 open locally today and had an issue with all gtk4 applications that I've tested simply hanging (as mentioned in the accepted PR for 580)
Not sure if it only applies to the open kernel modules, but I think it's best to keep 570.181 for now.
You can use xdowngrade to downgrade the package and then hold it to prevent upgrading for the time being.
See here: https://docs.voidlinux.org/xbps/advanced-usage.html
In case you've removed the older versions from your local cache or didn't have them, the easiest would probably be to: check out this PR as-is to a branch, not rebasing it on top of master, then packaging nvidia locally, and then using the same xdowngrade command but pointing to your local repos:
void-packages/hostdir/binpkgs/current-branch-name/nonfree/
and void-packages/hostdir/binpkgs/current-branch-name/multilib/nonfree if you use 32bit libraries too
Install nvidia-570.181.x86_64.xbps nvidia-dkms-570.181.x86_64.xbps nvidia-firmware-570.181.x86_64.xbps nvidia-gtklibs-570.181.x86_64.xbps nvidia-libs-570.181.x86_64.xbps nvidia-opencl-570.181.x86_64.xbps (possibly nvidia-libs-32bit-570.181.x86_64.xbps)
And then reinstalling the nvidia-open-dkms package
@JkktBkkt I tried rebuilding after your forced push to 580.82.09 and I get build errors
/var/lib/dkms/nvidia-open-dkms/580.82.09/build/kernel-open/nvidia/nv-clk.c:30:10: fatal error: soc/tegra/bpmp-abi.h: No such file or directory
30 | #include <soc/tegra/bpmp-abi.h>
| ^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
The process I followed was:
- pull your branch rebase onto latest master.
- Upgrade nvidia drivers.
- Remove the nvidia-open-dkms
- install nvidia-dkms
- Build nvidia-open-dkms using xbps-src
- Install nvidia-open-dkms
DId you notice this?
DId you notice this?
Sorry, I forgot to add a patch that fixes this into the commit (was present in local system), should work fine now.
On the process: I'd do 3 before 2, and 4 happens automatically when you upgrade nvidia, because nvidia-dkms is a direct dependency of nvidia
While I have been using this on a "daily" machine ever since the original PR was created, as-was, I don't think the PR as a whole is in a ready-to-merge state here (permalink to it is in first comment) With nvidia and nvidia-open-dkms installed and a new version available for one or both, manual intervention from the user is required to update (or temporarily holdback), which is far from ideal.
So I think a few changes for the nvidia template would help, something like the commit below works (from neither installed, it defaults to nonfree version). Not sure if this is the proper approach to take though and about details, i.e. names for virtual and the whole handling of -dkms subpackage.
I've briefly (game via proton, mpv via vulkan playback, both in a wayland session) tested updating locally from both 580.82.05 proprietary and open versions (open as it was at the time in this PR), correctly installs the required one in working state. PR set to draft as per edited opening comment.
Not quite sure what to do with that result of CI fail:
Trying to install dependents of nvidia-firmware:
ERROR: Unexpected error: Too many levels of symbolic links (40)
Failed to install 'nvidia-firmware' and 'nvidia-580.95.05_1'
Trying to install dependents of nvidia-gtklibs:
ERROR: Unexpected error: Too many levels of symbolic links (40)
Failed to install 'nvidia-gtklibs' and 'nvidia-580.95.05_1'
Trying to install dependents of nvidia-libs:
ERROR: Unexpected error: Too many levels of symbolic links (40)
Failed to install 'nvidia-libs' and 'nvidia-580.95.05_1'
I guess this comes from nvidia-open-dkms having a pinned nvidia version in depends, but changing that to generic nvidia would mean that both have to move in sync instead of having a situation like with 580.76.05 covered through templates and thus not requiring user intervention:
To my knowledge, that version was fine with proprietary flavor of the kernel module, but the open one had issues with gtk4 applications, so I didn't push the update until another version landed without those issues.
Let's see if this is the only issue..