Arch Linux User Repository

Use this forum thread for discussion: https://bbs.archlinux.org/viewtopic.php?pid=1946926

Please don't flag this package out-of-date unless a new version has been released by NVIDIA.

The DKMS package guidelines are explicit that linux-headers should not be a dependency of any DKMS package.

As a concrete example of why including that as a hard dependency is a bad idea, what happens when linux is not an installed kernel?

7.3 is in my develop branch (not my work, (Philip did that!)

https://github.com/megvadulthangya/nvidia-390xx-utils/tree/develop

Or you can check manjaro's gitlab and search for the package I'm sync my repo from that repo...

Uugh... We will probably have work to do for 7.3 and it is the same fun drm kind. According to Torvalds, 7.3 will include a fairly sizable drm pull with lots of scattered fixes. That just sounds bad. I'll try and see if Joan has anything yet after I resurrect my server - 12 years of service and then POOF! They just don't make'em like they used to...

While this might not be the typical place for this discussion, I wanted to share an alternative for fellow legacy Nvidia (Fermi/Kepler) users who are struggling with keeping nvidia-390xx alive against modern kernels and Xorg ABIs.

Over the last few months, I’ve been actively working on improving and optimizing the open-source nouveau driver as a sustainable, forward-looking alternative—especially with full Wayland, DRM/KMS, and modern kernel compatibility in mind.

If you're tired of the endless cycle of patching the proprietary legacy driver, feel free to check out the discussion, benchmarks, and ongoing work on the Arch BBS:

https://bbs.archlinux.org/viewtopic.php?id=314756

Feedback and testing from the community are very welcome!

I have also put together a repository with driver patches, a dynamic clock governor, and a hardware diagnostic tool to collect VBIOS/reclocking telemetry across different OEM cards: GitHub & Contributing Guide: https://github.com/Twilight0/nouveau-fermi-reclock-dkms (AUR package: nouveau-fermi-reclock-dkms)

Thank you @vnctdj! That's a nice looking patch. No, the drm backports are always a PITA. Both you guys did a great job with the src and CONFTEST changes. Looks like we are all set for 7.2 to hit core.

I don't have 7.2 yet, but I can confirm the kernel-7.2.patch continues to build fine with the 7.11 and LTS kernels. (no side effects)

I can also report success with the patch. I'm running the 7.2 kernel now on my openSUSE laptop with the patch incorporated. Works like a champ!

SUCCESS up and running on Arch 7.2.2 - flawless build, uneventful reboot.

I've just pushed a patch for Linux 7.2, based on Joan Bruguera's ones. I also checked my work against megvadulthangya's repo, this was not easy !

7.2 is in core-testing now.

noice drankinatty

Good to hear someone actually try to use what i working on.

Just a heads up when i shared my work in this place looks like was not finished the work yet(Not built on some kernels)yet... but now its finished and build on any manjaro kernel what currently have in manjaro repos RT as well. 61 66 612 618 71 72 tested... BTW i ported all of this to 340 as well. plus manage to fork and modify mhwd-db and all of the packages that need to autodetect drivers ... and now i have awesome, and xfce iso's which has legacy 340 support out of the box.

I passed the patch along to the openSUSE packager and I received confirmation it builds with their driver package on the 7.2 kernel. So @megvadulthangya's patch has my vote to be incorporated and pushed. We have a bit of time, the 7.2 kernel isn't even in core-testing yet. Not sure why, but I'm in no hurry, makes no difference for my hardware :)

@megvadulthangya - perfect. That satisfies my curiosity and my bad for not thinking about the source being in kernel-driver land instead of user-land. Coffee had long since worn off by then. If you are happy with the build, then I have no other questions. It looks ready to push unless we want the comments included. As said in my last comment -- I'll leave that to the consensus here, they certainly won't change the build behavior.

Thank you again for your help and testing. When 7.2 hits core-testing, it's time to push regardless of any consensus on the comments.

@drankinatty thanks for the questions, let me clarify.

1. os-interface.c: In Linux 7.2 strncpy() was removed from the kernel entirely, so building with strncpy() would fail (implicit declaration error). The kernel’s standard replacement for this use case is strscpy(), which has been available since Linux 4.3 and guarantees NUL-termination. The previous code was:

   strncpy(buf, current->comm, len - 1); buf[len - 1] = '\0';

For this use, strscpy(buf, current->comm, len) does the same thing: it copies at most len - 1 bytes and always NUL-terminates. strscpy() is declared in include/linux/string.h, so no extra definition is needed.

1. nvidia-modeset-linux.c: nvkms_strncpy() is a driver-internal function that is expected to behave exactly like strncpy(), i.e. copy up to n bytes and zero-fill the remaining bytes if the source is shorter. strscpy() does not zero-fill the tail, so it would not be a drop-in replacement for the existing callers.

Because strncpy() no longer exists on Linux 7.2, I added the manual loop:

for (i = 0; i < n && src[i] != '\0'; i++)
    dest[i] = src[i];
for (; i < n; i++)
    dest[i] = '\0';

This is exactly the traditional strncpy() semantics. On older kernels the #else branch still calls the real strncpy().

The condition src[i] != '\0' is indeed equivalent to src[i]; I used the explicit form only to make the null-terminator check more obvious.

Good point about the braces. The loops each contain only a single statement, so braces are not required by the C standard, but we can add them if you think it improves readability.

Thanks again for reviewing!