In D53987#1233523, @adrian wrote:

I'm ok with for now just enabling all symbol exports to unblock things and then figure out how to clean things up in post.

In D53987#1233515, @emaste wrote:

It is better to provide an explicit list of symbols than just EXPORT_SYMS=YESunless we are sure that all symbols should be exported. But, this enough to preserve the status quo at least.

In D53987#1233511, @imp wrote:

So why can't the coonsumers of these symbols just depend on the module? Why do we have to export the symbols from these modules to everybody?

If nvidia.ko hesitates to load due to the absense of linux*.ko, maybe src (main branch) would be needed to catch up with commit base e00a781c216cb12603a0a71c9ca293dde3e06250.

Sorry, uploaded wrong broken version of patch.
Replaced with actual one.

Apply the same fix as review D53136.
(Drop BUILD_DEPENDS line as per request from bapt.)

Alright. Let's wait for @bapt.
One (hope it unlikely) possibility is that graphics/nvidia-drm-kmod metaport RUN_DEPENDS on x11/nvidia-driver${PKGNAMESUFFIX} to pull it in at the first install.

LGTM now. Thanks!

It would be better unifying the terms to "Direct Rendering Manager" instead of "DRM" and "Direct Rendering interface".
I have no intention to reject (if so, as I'm assigned as reviewer, I would have rejected).
Just thought it would be clearer.

Additional note:

Thanks!

Can this be committed before new quarterly 2025Q4 is branched so that upcoming pre-built pkgs for 15.0-Release surely have this at its beginning?

Rebase after commit ports 971606f3493fbbc77c156ab84243ab952d89a81b.

As graphics/drm-[61|66]-kmod are updated and corresponding graphics/nvidia-drm-[61|66]-kmod[-devel] are bumped, this need to be rebased to land sanely.

Found new Production Branch of driver set 580.82.09 upstream.
Should I update ports for it? If so, patch in this review would need rebasing.

Rebase for upgrading to 580.82.07 at commit ports 2b2519a398fa84d21af69c8dc88c25f92aaa2d5f.

Opened another review to upgrade to 580.82.07 as D52352, which is the latest Production Branch of drivers.

For which context? This review itselr? Or for treatment about UPDATING?

Should I include UPDATING part into this, or opening separate review is wanted?

Related PR: Bug 288848

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288848

Thanks!
Using sed is not to worry when upstream (nvidia) incorporates fix in the future.

Upgraded to new NFB 575.64.

Rebase (again) after
commit ports 408bc22ceb8f1971abdb5271decf4275a7af9d8f
for graphics/drm-510-kmod.

Rebase after
commit 2648f5b3b996ac77536a60f2a6012db1eb5a4349,
commit 275846acd725a3e0240e07ae88773158c4d5f29c, and
commit 8ebe065203495c6c246d0ce3c29619a11c9cf910
for graphics/drm-515-kmod, graphics/drm-61-kmod and graphics/drm-66-kmod respectively.

Found latest NFB 575.64 is released.
As I'm now running new Production Branch of driver 570.169 (filed PR 287641 and corresponding review D50915) to see whether any new problem occurs or not, update would be worked on (hopefully) after a couple of days.

Rebase after upgrading of graphics/drm-515-kmod to drm_v5.15.160_4 at commit d7a1f45acaef32b98399a28ab5be5307d1186026.

Maybe we need to decide whether waiting until before the end of June or wait more.
This means in which quarterly this appears.

Precisely, CONFLICTS_INSTALL for x11/nvidia-secondary-driver* can be removed, too, for main branch.

Simplify CONFLICTS_INSTALL lines.
While here, add missing CONFLICT_INSTALL for x11/linux-nvidia-libs.

Should I split out line 7 and 11 of graphics/nvidia-drm-kmod/Makefile.common, which renames drm-*-kmod part of distfiles to match graphics/drm-*-kmod, to be a separate review and make this (D50282) to depend on it?

In D50282#1149188, @manu wrote:

I'm ok for this but keep in mind that we will still need to bump PORTREVISION on nvidia kmod when we update drm-*-kmod so I'm not sure it's worth doing all that tbh

Rebase after commit 940ca091de52.
Keeping concept until manu@ pops in as the de-facto maintainer of graphics/drm-*-kmod.

Thanks for the idea!

Rebase after commit 3adb70282914 and commit 8495963ac01c.
Stopped bumping PORTREVISION as pointed out by kbowling@.

Stop updating PORTREVISION as pointed out by arrowd@.

Why bump PORTREVISIONs? There should be no visible changes in the resulting package.

Rebase after upgrading to 570.144.
Split out auto-distinfo part (for graphics/nvidia-drm*-kmod).

I'm fine with splitting out "auto-merged distinfo" part for graphics/nvidia-drm-*-kmod into another review.
But as it strongly depends on the remaining part of this review (splitting distinfos for legacy versions), I've opened this as a "merged" one.
Putting "Depends on" line pointing to this review in the summary newly splitted out one does the right thing, right?
Or should I wait for the remaining-here part in this review to be approved and landed prior to opening another review?

Some notes for the future:
If new legacy branch is created upstream from pre-570.144, we would need to add back conditionals for it.
And once we add -devel for New Feature Branch of drivers (to support cutting edge GPUs), we would or wouldn't need to add conditionals (depending on whether the additions/upgrades are trivial or not).

This is basically a refactor to ease maintainances.

Rebase after commit 637e9e68f1a2ce587e5107b0fd296abd16f061a0 "x11/nvidia-driver: Fix too aggressive disabling of GSP firmware".

Because egl-wayland can be installed separately I think that's a good case for why keeping intermediate versions around is not worth it.

For x11/nvidia-driver, yes.

Turned out that use-cases requiring intermediate versions exists.

https://forums.freebsd.org/threads/how-to-install-the-nvidia-drm-kmod-for-the-driver-nvidia-525-78-01-on-freebsd-14-2-to-be-able-to-run-comfyui.97741/

Pending rebase after D50048 landed as commit 13636d8b58f662e12d1513333d1e981a59620109 for now, as D50053 should land first. Would rebase after it lands.

Rebase after D50048 landed as commit 13636d8b58f662e12d1513333d1e981a59620109.

If you feel the value 1 for hw.nvidia.registry.EnableGpuFirmware is OK, please commit this.
(I cannot test whether 17 works for anyone affected or not, as I don't have GPUs with GSP.)

Even though I've left inline comment about PORTREVISION, others looks good to me.
So accepting now.
Modifying PORTREVISION to match reality at the time committed shouldn't matter,
but if you want on commit, I'll accept this again ASAP.

Thanks!
Macro is good to ease and clarify codes "for anyone already thoroughy know it", but for anyone others, it can easily become kinda... hell to track. ;-) So I've left my previous comment for records.

For the record:
Some findings on tracking macros handling registry hw.nvidia.registry.EnableGpuFirmware and the reason why I've chosen this way.

Re-title.
Fix to allow overriding hw.nvidia.registry.EnableGpuFirmware via /boot/loader.conf again, which stopped working after D49828 landed.

In D50053#1141815, @kbowling wrote:

In D50053#1141698, @junchoon_dec.sakura.ne.jp wrote:

In D50053#1141632, @kbowling wrote:

In D50053#1141606, @ashafer wrote:

I think a better idea would be to adjust the patch I made for disabling GSP. That patch was pretty heavy handed and turned off a global which enabled GSP. I think instead we could make the patch default only the sysctl value to zero, disabling GSP by default but allowing users to enable it by setting the tunable in loader.conf. That would prevent us from having to have a build option and prevent users from having to compile things themselves.

I agree with this recommendation. This should be a tunable kind of thing since we need package users to be able to try both settings.

So OPTIONify is not needed, unless any case which need global disabling of GSP.
If such a case exists, keeping OPTIONifying but enable by default, with flipping the default for the tunable.
3 entries of OPTIONS_SINGLE would be wanted in that case.

Enable GSP firmware support
Disable GSP firmware support via tunable (default)

and

Globally disable GSP firmware support

to avoid confusions.

If not, simply changing patch to flip the tunable and edit pkg-message (actually, files/pkg-message.in) to tell anyone having problem with the ports default to flip it via tunable is sufficient.
In this case, if we can't edit summary of this revier, I need to abandon this and open a new review. Not sure at this moment.

I don't think the option is worth carrying. Instead, editing extra-gsp-patch-src-nvidia_subr.c (or whatever file instead) to provide the correct tunable) is the proposal from @ashafer.

We will hope that the default can become durable and do the right thing almost all the time, but it still seems like tricky business with all the cards and driver right now.

In D50053#1141632, @kbowling wrote:

In D50053#1141606, @ashafer wrote:

I think a better idea would be to adjust the patch I made for disabling GSP. That patch was pretty heavy handed and turned off a global which enabled GSP. I think instead we could make the patch default only the sysctl value to zero, disabling GSP by default but allowing users to enable it by setting the tunable in loader.conf. That would prevent us from having to have a build option and prevent users from having to compile things themselves.

I agree with this recommendation. This should be a tunable kind of thing since we need package users to be able to try both settings.

Looking into x11/nvidia-driver/Makefile and x11/linux-nvidia-libs/Makefile thoroughly, there seems to be no more candidates for conditionals to be pruned, if I'm not overlooking something.

On headsup for pruning intermediate versions, we should clarify:

*Keeping conditionals only the top of master port and each slave (legacy, currently) ports
  and initial version of each conditionals as a record, or

Rebase to chase graphics/drm-[61|66]-kmod upgrades.

In D49982#1140140, @jkim wrote:

In D49982#1140088, @junchoon_dec.sakura.ne.jp wrote:

In D49982#1140083, @ziaee wrote:

Can we have an updated version string in the dmesg? On current with nvidia-drm-66-kmod, I get:

Initialized nvidia-drm 0.0.0 20160202 for nvidia0 on minor 1

Cannot find related codes in nvidia side of src in quick glance, but found in drm-*-kmod part.
(I'm working on stable/14, so cannot test graphics/*drm-66-kmod. But string in dmesg looks same.

It is defined in the NVIDIA driver, i.e., src/nvidia-drm/nvidia-drm-drv.c. Just search 20160202.

Related discussions at Bug 285803, starting from comment 7.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285803#c7

In D49982#1140083, @ziaee wrote:

Can we have an updated version string in the dmesg? On current with nvidia-drm-66-kmod, I get:

Initialized nvidia-drm 0.0.0 20160202 for nvidia0 on minor 1

Fixed PORTREVISION in graphics/nvidia-drm-kmod/Makefile.common.

Anyway, whichever builds fine. So accepted.

Looks good to me.
Built/packaged both on bare-metal and poudriere, installed and ran fine using pkg built with poudriere.
Tested on stable/14, amd64 at commit f9afcbff02a230af85e646ef3ae166ae61b04ca1.

Looks good to me.
Built/packaged both on bare-metal and poudriere, installed and ran fine using pkg built with poudriere.
Tested on stable/14, amd64 at commit f9afcbff02a230af85e646ef3ae166ae61b04ca1.

Thanks!