Follow up to #4053: fix(hardware): bring nvidia driver installation in line with packaging changes#4053

[gmykiln11]

Creating this follow up issue as I didn't see any resolution under 4053. I will delete my comments there and past them below instead.

Comment 1:
What ever became of this? The head repo was randomly closed by a ghost 2 weeks ago but it doesn't seem like anything concrete was made from this or the other threads around nvidia-open and nvidia-open-dkms.

If I may propose a solution if still needed.

Maybe for now, asking the user for their GPU model instead of trying to enumerate it would be a better option. At least for now. If you have the option of entering when prompted for example RTX5090, RTX 5090 or, 5090 and the script knows to default to nvidia-open in this instance then it could work. You could even just make ask if the user has an RTX card (RTX2000 onwards) and default to nvidia-open in that case.

Alternatively, maybe there is some way to check how many cuda cores the GPU has or some other arbitrary figure and then enumerate the model from that?

Comment 2:
Also what is the current workaround for this? If we were to install using archinstall and allow it to get the current drivers as we see fit, can we then just install nvidia-open after we boot into the OS on top of the nvidia-open-dkms and it will switch over to nvidia-open or is further configuration needed/recommended in addition to that?

[h8d13]

This was followed up in another pull request by @sigreturn who seems to have deleted their github account :(

I believe there is no more need for a distinction/ nvidia-open / -dkms (only if the user has non standard kernel selected) This would mean faster installs if you are on mainline.

Altho you wouldn't support any card pre 16xx series which would need the AUR regardless, if I understand correctly

[gmykiln11]

'Tis a shame for their deletion.

I might be reading your statement wrong so please correct me if I am wrong but wouldn't it make more sense for the default behavior not default to nvidia-open to reduce install time and rebuilding every time as long as the user picked the standard kernel? Maybe just move the kernel up the options list to be selected first and then just if-else default into nvidia-open based on that?

If that is not the case, would the end user be find to install nvidia-open after first boot and allow it to remove the conflicts or would this undo configurations and/or break something?

[h8d13]

So the main issue is

archinstall/archinstall/lib/profile/profiles_handler.py

Line 226 in 2d18b55

if driver in [GfxDriver.NvidiaOpenKernel, GfxDriver.NvidiaProprietary]:

That would install headers regardless and obiously hardware.py (amongst other issues there like installing xorg libs always)

And always -dkms too.

Related: #3830 #4019

Menu order is already done for this: ac984b7

And so is vulkan-driver fix: f736b8c

[gmykiln11]

Thanks for your reply @h8d13,

I am slightly confused as I am more user inclined than developer. Are you saying that I can remove the nvidia-open-dkms package with -dkms command using Konsole for example after I boot and then I will be safe to install the nvidia-open package and all the configuration thaat is usually done with nvidia-open-dkms will carry over because it is done by different functions of archinstall already?

[h8d13]

My pleasure.

To clarify: I'm saying that archinstall always installs headers + dkms (which slows down installs and is not strictly necessary, this build your drivers vs headers).

This is seen here:

archinstall/archinstall/lib/hardware.py

Lines 129 to 134 in a9c939c

	case GfxDriver.NvidiaProprietary:
	packages += [
	GfxPackage.NvidiaDkms,
	GfxPackage.Dkms,
	GfxPackage.LibvaNvidiaDriver,
	]

But with nvidia-open and normal linux kernel (not -zen or -lts) this isn't needed at all.

In my fork the logic is adapted for this
https://github.com/h8d13/archinstoo/blob/1d7b3b046d179a07f1f06f487bf890eaa8d1860c/archinstoo/archinstoo/lib/hardware.py#L131-L138

To avoid this ^^

This checks:

	def use_dkms(self, kernels: list[str] | None) -> bool:
		if not self.has_dkms_variant():
			return False
		return kernels is not None and any('-' in k for k in kernels)

Basically if there is no - in the kernel name, we can avoid dkms and speed up installs/ less compute needed.

[gmykiln11]

Ah, right. I understand. So are you planning to push this part of your fork into archinstall so that the same behavior will happen there as well?

[h8d13]

I do not think so no. Unfortunately contributing here is difficult for reasons I will not go into

But you are free to check out the work being done daily / help with with testing/recommendations :)

[gmykiln11]

@Torxed Would there be any way to add this in a more official capacity by using the provided repo?