New package: nvidia-open-dkms-580.126.18#54593
New package: nvidia-open-dkms-580.126.18#54593JkktBkkt wants to merge 1 commit intovoid-linux:masterfrom
Conversation
|
Being not really comfortable with git cli I tried to preserve mike's contribution (and failed miserably as can be seen above) And dkms make log: |
|
Oh, and also this makes |
|
@classabbyamp can re-build be approved? |
|
@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. |
|
Hello, While I do not have anything more to add as of now, I'd like to answer your question about the 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. I'm also unsure how to implement the 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 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: Thus, I would have both the current proprietary dkms 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: 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. |
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. 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. 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 |
Personally, I'm down with pretty much anything you deem the appropriate path, including you taking over this package as the maintainer. P.S. sorry for the delayed update, had to finish other stuff on the machine before rebooting and testing new version |
|
Hi! I just tried to use this PR, but was hitting an issue with the DKMS not installing properly. It said it was building, but I noticed that the module never ended up in Should we add |
|
I went on a dive to find where xz comes from, thought it's dkms itself or something in the kernel configs changed, but no, the modules aren't using xz.. Should be fixed now Oh and lsmod only shows the loaded modules, completions to modinfo / modprobe / etc. should show you the built ones, and files should be in |
|
6.18 compatibility patch added. Tested, no issues detected. |
|
last commit, upgrading to .119, does not work in my computer dmesg output |
|
@revington looks like the kernel panic'd a bit over 11 minutes after starting, I'd suggest looking at the rest of the logs around the 670 mark (which is seconds from boot) mark to see the rest of the message and perhaps figure out what's causing that. Also worth double-checking that the rest of the nvidia- packages have been updated to the same 580.119.02 version There are reports of 580.119.02 (and 590.4x versions) being broken in various setups as well, so if you'd prefer to not figure it out much with it much, a rollback to 580.105.08 ( |
|
@JkktBkkt thanks for your help. Here is the output of xbps-query for the nvidia package. Is there any other package I must downgrade? I did not have the .xbps packages so I switched to previous commit and rebuild the package from there. |
|
@revington I'm not sure if xbps-query checks that all dependencies are satisfied, but if those installed match what's listed in run_depends, that should be good. EDIT: nvidia's changelog for 580.126.09 (released today) shows:
Maybe that's what's happening on your system? |
|
Wanted to comment as well that I'm having some graphical glitches with the standard EDIT: Finally got around to building the 580.126.09 package, and so far it's working great. Tested with an RTX 3080 FE card and kernel 6.12.74_1 |
|
@JkktBkkt thanks, finally I got it working with 580.119.02. |
|
Forgot to change the commit description and title ^, it's just another version bump to keep in line with |
|
Right now for me, the module fails to build for kernel 6.19, but builds for 6.18 and lower |
|
Its being tracked.
NVIDIA/open-gpu-kernel-modules#1015
…-Andrew
On Mon, 23 Feb 2026 at 19:53, halfbit0 ***@***.***> wrote:
*halfbit0* left a comment (void-linux/void-packages#54593)
<#54593 (comment)>
Right now for me, the module fails to build for kernel 6.19, but builds
for 6.18 and lower
make.log <https://github.com/user-attachments/files/25503721/make.log>
—
Reply to this email directly, view it on GitHub
<#54593 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABXP5MVDO7O3GMSMV2LKR34NOOHVAVCNFSM6AAAAABYNHYWTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNBYGIZTMNBVGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Nevermind, its been fixed.
https://www.nvidia.com/en-us/drivers/details/264090/
…-Andrew
On Tue, 24 Feb 2026 at 08:28, Andrew Benson ***@***.***> wrote:
Its being tracked.
NVIDIA/open-gpu-kernel-modules#1015
-Andrew
On Mon, 23 Feb 2026 at 19:53, halfbit0 ***@***.***> wrote:
> *halfbit0* left a comment (void-linux/void-packages#54593)
> <#54593 (comment)>
>
> Right now for me, the module fails to build for kernel 6.19, but builds
> for 6.18 and lower
>
> make.log <https://github.com/user-attachments/files/25503721/make.log>
>
> —
> Reply to this email directly, view it on GitHub
> <#54593 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AABXP5MVDO7O3GMSMV2LKR34NOOHVAVCNFSM6AAAAABYNHYWTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNBYGIZTMNBVGU>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
Co-authored-by: Miguel <migue07mx@protonmail.com>
|
rev2 so that xbps doesn't try to replace |
Important: PR has been set to WIP as the template requires additional review, for cleanup and tie-in with main nvidia package.Unset, current version should be a bit cleaner, not requiring manual removal of -dkms before re-installing updated -open-dkms on every update.
Here's a permalink to the commit that doesn't change thenvidiatemplate if you want to install or upgrade before this can land and in case more changes are requested by maintainers: 78cc73d^ current version doesn't change
nvidiatemplate either, but see there for previous update notes.See #54593 (comment) and below to track that progress
Testing the changes
Local build testing
Comments
Most recent versions I test on 6.18
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