nvidia-drivers-340.108

Shibotto · Posted: Fri Jan 29, 2021 7:59 pm Post subject:

I'm sorry I haven't been around, I totally forgot about this thread, my bad :roll:

I updated a few things:

Patches up to linux 5.10
Restored nvidia-uvm module: it compiles, I don't know if it works though cause I don't use CUDA
Script to correctly VT switch after resuming from suspend when using elogind
Removed the udev rule to call nvidia-smi on boot because it kills TTYs on my laptop; if you need /dev/nvidia* to be initialized before Xorg starts, enable the nvidia-smi service

dmpogo · Advocate Joined: 02 Sep 2004 Posts: 3414 Location: Canada

psycho · Guru Joined: 22 Jun 2007 Posts: 542 Location: New Zealand

I think I've built a relatively *recent* nvidia kernel module with drm (I'm remember thinking "huh, isn't that only for nouveau?" but then the nvidia-drivers worked nicely with drm in the kernel)...but it also looks like it was around nvidia 364 that the proprietary driver added drm support, so requiring it for 340 does look like it could be a mistake.

Ionen · Developer Joined: 06 Dec 2018 Posts: 2849

Unless you use nvidia-drm.modeset=1 I don't think these options matter no matter the driver version. Originally the kernel config check was added to all ebuilds as a forced requirement but it made me open a bug so it'd (at least) be optional, and so it is and I ignore the message every time.

I don't use 340 anymore (I use nouveau on my old boxes) but I don't even install/load the nvidia_drm module on 360.39 either.

Would reconsider if I wanted to use wayland, but that's not something on the table for me at the moment with things I use.

Shibotto · Posted: Sat Jan 30, 2021 12:15 am Post subject:

Yes, I just found Ionen report. Prior to this change the options checked where:

Ionen · Developer Joined: 06 Dec 2018 Posts: 2849

Yeah that makes sense, probably safer to also keep that ZONE_DMA I see (was dropped near those updates).

It's "optional" (I have it disabled with 360.39) but only if you use IOMMU instead (does that even work with 340? odds are old hardware wouldn't have good support either way).

dmpogo · Advocate Joined: 02 Sep 2004 Posts: 3414 Location: Canada

Shibotto · Posted: Sat Jan 30, 2021 1:20 pm Post subject:

dmpogo · Advocate Joined: 02 Sep 2004 Posts: 3414 Location: Canada

Poopman · n00b Joined: 13 Jan 2021 Posts: 2

Shibotto · Posted: Sun Feb 14, 2021 7:46 pm Post subject:

A couple of updates:

Gentoo fixed their libglvnd USE flag situation for x11-base/xorg-server, so I can finally drop it myself. FINALLY.
As you may have heard, GTK+2 went EOL with GTK4 release, so Gentoo is proceeding to phase it out. It probably won't be a problem for quite a bit, but if you are eager to jump into the inevitable "future" (LOL) I added nvidia-settings-343.36 (currently masked for testing) which more or less only added initial GTK+3 support compared to 340. Unless someone reports regressions, I'll make it stable in a couple of weeks. nvidia-settings-340.108 won't go away until the removal of GTK+2, so rest assured.

As usual if I managed to break you installation let me know here or on GitLab. :lol:

Ionen · Developer Joined: 06 Dec 2018 Posts: 2849

Yeah, gentoo started cleaning up the situation thanks to new maintainer. So nvidia-drivers lost libglvnd flag plus the FreeBSD ancestral stuff (like your ebuild already did). There's plans to split off nvidia-settings in gentoo as well, but that'll wait for later given versions bumps were getting urgent (security issues too). Those new bumps also all work with kernel 5.10.x without patches (390.xx included), but 340.xx will remain out of the loop

Shibotto · Posted: Mon Feb 15, 2021 1:36 am Post subject:

psycho · Guru Joined: 22 Jun 2007 Posts: 542 Location: New Zealand

dmpogo · Advocate Joined: 02 Sep 2004 Posts: 3414 Location: Canada

Ionen · Developer Joined: 06 Dec 2018 Posts: 2849

Shibotto · Posted: Thu Sep 02, 2021 11:19 pm Post subject:

Long time no see!
I finally took some time to tidy up this overlay a bit, which is now ~99% based on the very neat work Ionen did in the main tree (thank you, it was MUCH needed). It's still in its dedicated branch as a safety measure, but unless some major regression shows up, I plan to go stable and merge it to master by next week. So I won't break you systems for a few days at least :lol:

As I previously said, I really wanted to split nvidia-drivers further, so it now comes in 3 ebuilds: nvidia-kmod, nvidia-drivers and nvidia-settings. If I put the blockers correctly, when the time comes upgrading should be as smooth as adding "x11-drivers/nvidia-kmod NVIDIA-r2" to your package.license .

↓ The following is an explanatory changelog if you want to know why I did things the way I did them ↓

x11-drivers/nvidia-kmod: the Nvidia kernel module.

New package
Since this will get rebuilt very often, just do the bare minimum required. This is what I was aiming for when I split nvidia-drivers and nvidia-settings in the beginning, but I did things in a rush and focused on the wrong aspect of the problem.
Drop nvidia-uvm and related patches
After a night stroll on Wikipedia it became clear that none of the cards supported only by 340.xx is compatible with Unified Memory anyway.
Still only support kernels up to 5.10.x
I only use LTS kernels, so even if I add patches for interim versions, I won't be testing them. As usual, user patches can be added to /etc/portage/patches/ .

x11-drivers/nvidia-drivers: Nvidia libs and tools.

Rebased on Gentoo's ebuild
Some of the changes that happened there also apply here, for example: utilities like nvidia-modprobe and nvidia-persistenced being built from source, obsolete USE flags being dropped, ecc.
Drop IUSE=driver
Unconditionally depend on x11-drivers/nvidia-kmod. If for some reason you need the USE=-driver behavior, add nvidia-kmod to your package.provided.
Build libXNVCtrl.a
Moved here from nvidia-settings-340.108 .

media-video/nvidia-settings: ...well, nvidia-settings

.

Default to 343.36 (using GTK+ 3)
340.108 (GTK+ 2) is still in the overlay and will stay there as long as x11-libs/gtk+:2 is in Gentoo. This situation is the main reason why I'm keeping nvidia-settings split.

Ionen · Developer Joined: 06 Dec 2018 Posts: 2849

Shibotto · Posted: Wed Sep 08, 2021 1:44 pm Post subject:

Ionen · Developer Joined: 06 Dec 2018 Posts: 2849

Tom_ · Guru Joined: 20 May 2004 Posts: 448 Location: France

I've been using Andrew Church's overlay for quite a while. Even if it works, I'm getting more and more blockers and I have to maintain more and more ebuilds manually in my own overlay.

I would like to use a simpler solution. Shibotto's overlay looks promising. I'll give it a try! Thank you for your work

Ionen · Developer Joined: 06 Dec 2018 Posts: 2849

Yeah, in my opinion trying to keep old eselect-opengl is a lost cause that deviates far too much from where gentoo is going.

::nvidia-legacy keeps this only specific to nvidia without touching the rest and can live with modern Gentoo just fine (or at least for as long as a new Xorg doesn't a break it).

Shibotto · Posted: Sat Dec 18, 2021 2:12 pm Post subject:

Some updates:

nvidia-kmod can now be built against anything from 4.4 to 5.15. At runtime though I only tested 4.4.290 (as a safety measure), 5.4.156, 5.10.76 and 5.15.7 but I think there should be no problem with the releases in between. If you decide to upgrade to 5.15 keep in mind that as per the recent trend new LTS kernels are supported for 2 years only (until further notice).

xorg-server 21.1, which was my biggest concern long term, luckily seems to still play nice at least with my hardware (OpenGL, HDMI/VGA output, resume from suspension, vdpau, ecc). I'm now relying on Xorg's "IgnoreABI" though, which essentially means that everything is fine... until it isn't... someday, usually when you are swamped with work

I've been running 5.15 + 21.1 for a week and I didn't notice any regression, so this time I'm confident enough to push this right away.
I hope

Ionen · Developer Joined: 06 Dec 2018 Posts: 2849

Good to know that IgnoreABI works, still hoping for nvidia to update 390.xx for xorg-21 at least (still hope unlike 340) but if it comes down to it I'll have it pass IgnoreABI too

xorg-1.20 is still supported for now fwiw (1.20.14 was added not long ago with security fixes).

Update: nvidia updated 390 to xorg-21 and kernel-5.15 with >=390.147.. so no worries for that one for now

Randy Andy · Posted: Fri Jul 08, 2022 9:14 pm Post subject: Short story long ;-)

Hi Shibotto and Ionen.

first of all I would like to thank Shibotto for his excellent work in the form of his manual and his repository!
I've only been using it since today, but it looks like it has now saved me and finally brought me back to calmer waters, after a far too long ordeal.

I had already switched to the Nouveau drivers many years ago, when I was still using another graphics card and another PC, and had actually had quite good experiences with them.
Especially because at the time I was still on the ~amd64 arch and at the time the nvidia drivers could not yet be built against the latest kernels without an IgnoreABI patch.

In 2014 I bought a used Dell Precision T3500 with a Nvidia Quadro FX4800 graphics card.
I would still consider it up to date, thanks to 6 physical cores or 12 with hyperthreading and a still quite powerful graphics card.
https://www.techpowerup.com/gpu-specs/quadro-fx-4800.c1320
https://en.wikipedia.org/wiki/Tesla_(microarchitecture)

Finally, it manages a resolution of up to 2880x1620 px at 60 Hz and has one DVI and two display port outputs.
Since I'm not interested in video games, but rather in more constructive 3D and office applications, I absolutely don't see the point in discarding this graphics card. Even if Nvidia tries to discard it as outdated with constantly decreasing support.

Even with the Nouveau drivers I got along for a long time, at least on the DVI output. But after I got myself a 32 inch monitor, I noticed that the picture quality on the DVI output was significantly worse than on the DP output.
From that point on, December 2019, my problems began and they have continued ever since, because the Power Management of the Nouveau driver for this card have been so bad for years that the monitor usually cannot be woken up again after a shutdown.
With kernels up to version 5.4.143 this still worked in about 80% of the cases, but with newer kernels this reversed in about proportion. So here it was necessary to reboot the computer all the time, because all nouveau.<parameters> could not help.
Turning off the screen saver or power management did not help to prevent ghosting. Turning off the monitor didn't help either, because after that the video card didn't wake up either, with errors along the lines of:
nouveau 0000:02:00.0: DRM: core notifier timeout
kernel: nouveau 0000:02:00.0: DRM: base-0: timeout

So at some point within the last two years I tried to switch back to the proprietary nvidia-drivers, which failed thanks to the lack of support from the Gentoo maintainers and became hell for me as a result.
Ionen, it's not just you - in general I find that many packages are removed from the tree far too quickly just because Upstream or someone else discontinues support - it really fucks me off.
GRUB legacy also comes to mind, I still prefer it!

The few additional ebuilds, i.e. text files, won't take up so much space that they can't still be made available to the users. What about the much vaunted and much appreciated "it's all about choice" philosophy.
It's clear that the mantainers want to make their work easier, but from my point of view they are allowed to have a few more instances of the ebuilds. How often I had to experience that a stable version had a bug and I couldn't go back to the previous version, because it was already removed from the tree. Then the huddle with archives, overlays or local overlays starts - not nice from the user's point of view.
The more annoyed I was, to return to the nvidia-driver, when I found out that the version nvidia-drivers-340.x was not even in the Layman overlays or the ones from Zugaina.

Fortunately, thanks to Shibotto's commitment, I found the solution I had hoped for and, thanks to an excellent and simpler description, the solution I had longed for. It's nice to see how all the old dependency problems could be solved in the meantime and how easy the installation can be now.
Finally I can send my PC into standby mode to wake it up again quickly and finally have a picture afterwards.

It's good that the topic of sustainability and planned obsolescence has been brought to people's attention a bit more. Years ago I had to listen to myself all the time - why don't you just buy a new graphics card that is better supported by Linux, but I think that would not have been the right way here in particular.

It's good that the topic of sustainability and planned obsolescence has now been brought to people's attention a bit more. Years ago I had to listen to myself all the time - why don't you just buy a new graphics card that is better supported by Linux, but I think that would not have been the right way here in particular.

Hopefully the situation remains so functional, because as you already mentioned - you never know which of the next changes will break the whole thing again.

Shibotto, in any case, now you see that another user also benefits from your work and appreciates it and is very grateful to you. And so I hope that this will give you a little motivation to continue.

Best regards,
Andy.
_________________
If you want to see a Distro done right, compile it yourself!