# nvidia-drivers-340.108

## dmpogo

When one removes a hardware support for still rather widely deployed hardware,  one at least, in my opinion,  should not insult user intelligence by given rationale such as

```
- x11-drivers/nvidia-drivers-340.108::gentoo (masked by: package.mask)

/usr/portage/profiles/package.mask:

# Matt Turner <mattst88@gentoo.org> (2020-08-11)

# NVIDIA declared this branch to have reached end of life about six months ago.

# Blocks removal of app-eselect/eselect-opengl and app-eselect/eselect-opencl.

# Masked for removal in 30 days. Bug #728290

```

Blocks removal of eselect ?? seriously, this is a reason ?

[Moderator edit: added [code] tags to preserve output layout. -Hu]

----------

## rogge

I'm confused about the "solution", too. Using a Quadro FX 3800 and nvidia.com tells me I still need nvidia-drivers-340.108 to proceed.

Is the "solution" by removing this driver to buy a new gfx card? Or keeping my system outdated?

Greets, rogge

----------

## Hu

What about removing that version of the nVidia proprietary driver and switching to a newer maintained one, or switching to the open-source Nouveau driver?  Does nVidia no longer maintain drivers that support your still-working card?

----------

## Ionen

 *Hu wrote:*   

> What about removing that version of the nVidia proprietary driver and switching to a newer maintained one, or switching to the open-source Nouveau driver?  Does nVidia no longer maintain drivers that support your still-working card?

 nvidia removes support for older cards in newer drivers and then keeps those older drivers supported for a while as a LTS branch. Meaning there are plenty of cards that only works with 340, and nvidia never had any intention to add libglvnd support to this older branch.. while gentoo (read: matt) is adamant about no longer supporting non-libglvnd setups, so it got removed even if it still works with eselect-opengl using nvidia's lack of support as an excuse (support did end around end of 2019).

As for nouveau, it's good enough to get a display but it offers worse performance and no vdpau support (which is often needed on old laptops to get decent video playback). On a desktop with a decent cpu I'm mostly fine using it over dealing with those old drivers though.

390 support will also end around end of 2022, but that one has somewhat-working libglvnd support so it'll probably stay past that date for as long as it works with current xorg and LTS kernels.

----------

## Ionen

If nouveau or using new hardware is not an option, there is an overlay aimed at supporting eselect-opengl that still has nvidia-drivers-340. But I have no idea how well/long that will be supported so rely on this at your own risks.

See: https://github.com/achurch/noglvnd

----------

## dmpogo

 *Ionen wrote:*   

> If nouveau or using new hardware is not an option, there is an overlay aimed at supporting eselect-opengl that still has nvidia-drivers-340. But I have no idea how well/long that will be supported so rely on this at your own risks.
> 
> See: https://github.com/achurch/noglvnd

 

Thanks for the info !   You know how long is needed - until hardware dies   :Very Happy: 

----------

## Tom_

I'm quite disappointed by the removal of the nvidia-drivers 340 and the related packages. 

I got my graphic card years ago when AMD drivers weren't as good as they're today. This card just works and I don't need more gpu performance for the moment. 

Is maintaing app-eselect/eselect-opengl such a burden for Gentoo devs?  I thought Gentoo was about choice ... removing such a common driver is rather unilateral. 

@ Andrew, thank you a lot for the overlay.

----------

## rogge

 *Ionen wrote:*   

> https://github.com/achurch/noglvnd

 

But the overlay isn't support nvidia-drivers-340.108, too. Isn't it?

----------

## Ionen

 *rogge wrote:*   

> But the overlay isn't support nvidia-drivers-340.108, too. Isn't it?

 Hm? As I said it's included in it (not that I've tried it), I guess gentoo's last-rite mask may get in the way right now but you can clear it on your end (overlay already does so for eselect-opengl). I doubt it'll get removed because gentoo does, and if something doesn't work can always try to open an issue there (preferably with fixes included given not sure if they have the hardware to test those).

On another note, looks like the overlay did some updating work since last checked so I guess it's doing its job  :Smile: 

----------

## rogge

Here, both are hard masked.

```
[?] x11-drivers/nvidia-drivers

     Verfügbare Versionen:   304.137(0/304)^md[1] [M]340.108-r1(0/340)^mtd [M]340.108-r1(0/340)^mtd[2] [m]~390.132-r4(0/390)^mtd [m]~390.132-r4(0/390)^mtd[2] [m]390.138-r4(0/390)^mtd [m]390.138-r4(0/390)^mtd[2] [m]435.21-r6(0/435)^mtd [m]435.21-r6(0/435)^mtd[2] [m]440.100-r2(0/440)^mtd [m]440.100-r2(0/440)^mtd[2] [m]450.66(0/450)^mtd [m]450.66(0/450)^mtd[2] {+X acpi compat (+)driver gtk3 +kms (+)libglvnd multilib pax_kernel static-libs +tools uvm wayland ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64 lp64d" ABI_S390="32 64" ABI_X86="32 64 x32" KERNEL="FreeBSD linux"}

     Installierte Versionen: 340.108(0/340)^mtd(14:26:01 17.06.2020)(X multilib tools -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64" ABI_X86="32 64 -x32" KERNEL="linux -FreeBSD")

     Startseite:             https://www.nvidia.com/Download/Find.aspx

     Beschreibung:           NVIDIA Accelerated Graphics Driver

[1] "host" /usr/local/portage

[2] "noglvnd" /var/lib/layman/noglvnd

```

----------

## Ionen

 *rogge wrote:*   

> Here, both are hard masked.

 Like I said just had to unmask it on your side, but now it won't matter given it's removed from ::gentoo and last rite mask won't interfere with the overlay anymore.

Edit: That aside, had forgotten 340 still hard depended on eselect-opencl too, the ebuild may need updating on the overlay. Formerly it was supposed to be migrated along with the rest (see gentoo-dev post), but got ignored likely because maintainer didn't have the hardware to test it and was looking forward to getting it removed instead.

Edit2: Opened an issue about this. It'd probably help if someone actually using 340 got involved with keeping 340 working there.Last edited by Ionen on Sat Sep 12, 2020 10:48 pm; edited 3 times in total

----------

## Shibotto

If anyone is interested I'm trying to fight this in https://bugs.gentoo.org/741556

I opted to do what eselect-opengl did directly inside the nvidia ebuild, so the transition should be seamless even without eselect-opengl. I'm not having much luck on Gentoo's side however, as they simply don't seem to care.   :Rolling Eyes: 

----------

## Ionen

 *Ionen wrote:*   

> Edit2: Opened an issue about this.

 Got good response from maintainer, hopefully 340 on that overlay will be kept and work fine for as long as it can (let the maintainer know if there's problems given neither I nor the maintainer use 340).

Guess opened issue at a good time too given what the last sync did around same time  :Shocked: 

Edit: on a side-note, if don't want to install ruby for likely unused opencl, virtual/opencl's alternative (dev-libs/opencl-icd-loader) doesn't need it. If want to avoid dependency nonsense likely be easier to uninstall nvidia-drivers+eselect-opengl/cl first (keep binpkgs if worried), and then `emerge -1 dev-libs/opencl-icd-loader` and finally build nvidia-drivers-340 from the overlay.

----------

## dmpogo

 *Ionen wrote:*   

>  *Ionen wrote:*   Edit2: Opened an issue about this. Got good response from maintainer, hopefully 340 on that overlay will be kept and work fine for as long as it can (let the maintainer know if there's problems given neither I nor the maintainer use 340).
> 
> Guess opened issue at a good time too given what the last sync did around same time 
> 
> Edit: on a side-note, if don't want to install ruby for likely unused opencl, virtual/opencl's alternative (dev-libs/opencl-icd-loader) doesn't need it. If want to avoid dependency nonsense likely be easier to uninstall nvidia-drivers+eselect-opengl/cl first (keep binpkgs if worried), and then `emerge -1 dev-libs/opencl-icd-loader` and finally build nvidia-drivers-340 from the overlay.

 

That's good news, and goot hint about ruby !

----------

## molletts

 *Ionen wrote:*   

> on a side-note, if don't want to install ruby for likely unused opencl, virtual/opencl's alternative (dev-libs/opencl-icd-loader) doesn't need it. If want to avoid dependency nonsense likely be easier to uninstall nvidia-drivers+eselect-opengl/cl first (keep binpkgs if worried), and then `emerge -1 dev-libs/opencl-icd-loader` and finally build nvidia-drivers-340 from the overlay.

 

I just tried that, given that I've got "-opencl -cuda" in my global USE flags as I have no use for compute on my GTX260, but when I 'emerge -1 x11-drivers/nvidia-drivers::noglvnd' it just uninstalls opencl-icd-loader and opencl-headers and reinstalls eselect-opencl.

I'll live with it for now, though. I'm not going to be using this PC for the next few few weeks anyway.

----------

## Ionen

 *molletts wrote:*   

> when I 'emerge -1 x11-drivers/nvidia-drivers::noglvnd' it just uninstalls opencl-icd-loader and opencl-headers and reinstalls eselect-opencl.

 That sounds strange, the dependency isn't in it at all, if anything it shouldn't even be possible to install eselect-opencl anymore given it was removed in ::gentoo yesterday, unless added it to a local repo anyway.

Perhaps you have an outdated copy of the overlay, or some mask? It was depending on eselect-opencl until 11 hours ago, and 304.108-r2 revbump is the new one.

Edit:

```
# emerge -1av opencl-icd-loader nvidia-drivers:0/340

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N     ] dev-util/opencl-headers-2020.06.16::gentoo  0 KiB

[ebuild  N     ] dev-libs/opencl-icd-loader-2020.06.16::gentoo  USE="-test" ABI_X86="(64) -32 (-x32)" 0 KiB

[ebuild  N     ] virtual/opencl-3-r1::gentoo  ABI_X86="(64) -32 (-x32)" 0 KiB

[ebuild  N     ] x11-drivers/nvidia-drivers-340.108-r2:0/340::noglvnd  USE="X driver multilib tools -static-libs" ABI_X86="32 (64) (-x32)" 0 KiB
```

No hardware to use it but it built for what it's worth  :Smile:  Had already updated the test system to use ::noglvnd's xorg-server/mesa. The opencl packages are also very small/quick, not that different than eselect-opencl (no idea why the ruby one is default, but I know too little about using opencl to say anything about it.. I'd like to think the one from KhronosGroup, of all people, is fine).

----------

## dmpogo

 *Ionen wrote:*   

> [No hardware to use it but it built for what it's worth  Had already updated the test system to use ::noglvnd's xorg-server/mesa. The opencl packages are also very small/quick, not that different than eselect-opencl (no idea why the ruby one is default, but I know too little about using opencl to say anything about it.. I'd like to think the one from KhronosGroup, of all people, is fine).

 

I have a hardware, just installed,   works fine (well, I do not use opencl itself).   Indeed it is -r2 which has been migrated to virtual/opencl just yesterday.

----------

## gienah

I was running =x11-drivers/nvidia-drivers-340* before it was removed.  Since I had to switch to nouveau (switching to the overlay was not a good option for me since I prefer to follow the tree), I switched from x11-wm/xmonad on X11 to the wayland tiling window manager gui-wm/sway.  nouveau seems to run better on wayland.  The video playback performance of mpv seems fine on the old Nvida Quadro FX 2800M.

----------

## jarro_2783

I tried the -r2 patch and it works fine, although using that overlay might be the way to go.

I still don't understand why we need libglvnd. I have an Nvidia card and I want to use the official drivers because they are fast, so why do I need all this multiple vendor driver switching stuff that glvnd provides?

I've also never used opencl, so I don't really even care whether any of that works.

I also don't understand why people make it hard to support old hardware, isn't that half the point of Linux? I bought a 9800GT 12 years ago because it was awesome, and it's still better than some of the cheap cards now, so why would I want to spend another $250 to upgrade?

----------

## Shibotto

In case you don't care about eselect-opengl, I made my overlay targeting 340 specifically: https://gitlab.com/shibotto/nvidia-legacy

The main differences from Gentoo's previous implementation are:

Drop the FreeBSD bits

nvidia-settings has its own ebuild (I don't know how someone in their right mind ever thought it was a good idea to merge it with the driver)

Do inside the ebuild what eselect-opengl used to do

If you are fine with the other overlay blacklisting libglvnd you can safely ignore this message   :Wink: 

----------

## dmpogo

 *Shibotto wrote:*   

> In case you don't care about eselect-opengl, I made my overlay targeting 340 specifically: https://gitlab.com/shibotto/nvidia-legacy
> 
> The main differences from Gentoo's previous implementation are:
> 
> Drop the FreeBSD bits
> ...

 

That is interesting !   and I fully agree with you on nvidia-settings,  especially since they causes quite a few 32-bit dependencies.

----------

## lefsha

 *Hu wrote:*   

> What about removing that version of the nVidia proprietary driver and switching to a newer maintained one, or switching to the open-source Nouveau driver?  Does nVidia no longer maintain drivers that support your still-working card?

 

What about to stop saying nonsense and push people to use crap software instead of working and available one?

Nouveau is crap, if wasn't clear initially. Even Arch Linux keep 340-108 version available to install. So does NVIDIA.

What is the problem with GENTOO???

There is no one who ask you to use that driver. It's a well spread disease among Gentoo developers to delete ebuilds

for no reason.

 :Evil or Very Mad: 

----------

## ff11

 *lefsha wrote:*   

> ...
> 
> Nouveau is crap, if wasn't clear initially. Even Arch Linux keep 340-108 version available to install. So does NVIDIA.
> 
> What is the problem with GENTOO???
> ...

 

The problem with Gentoo Linux is that even old users apparently haven't yet learned how to use it.

ArchLinux in the official repository, there is only the latest version of the driver, and older versions only in the AUR (Arch User Repository) which would be the equivalent of Gentoo Linux overlays. And if we look in the zugaina:

https://gpo.zugaina.org/x11-drivers/nvidia-drivers

we can find old versions like the nvidia-drivers-340.108

Overlays are part of Gentoo Linux experience. And I believe that every user should have at least one personal overlay.

----------

## Ionen

Yeah, unfortunate official support is gone but there is two notable alternatives now. One which keeps eselect-opengl and another that works without it (see post above).

The latter sounds far preferable at this point and much easier to maintain in the long run (or at least until a new xorg version breaks old drivers as it happened for pre-340 drivers). I also second that nvidia-settings is much better separated  :Neutral:  I'm pretty tired of rebuilding it everytime I just want to rebuild the modules for the kernel, and I can't use -tools because I need libXNVCtrl.a provided by it. Not to mention it makes the ebuild needlessly more complex.

----------

## Hu

 *lefsha wrote:*   

>  *Hu wrote:*   What about removing that version of the nVidia proprietary driver and switching to a newer maintained one, or switching to the open-source Nouveau driver?  Does nVidia no longer maintain drivers that support your still-working card? What about to stop saying nonsense and push people to use crap software instead of working and available one?

 That is exactly what I am doing.  nVidia has a history of removing support in the current branch for cards that are still working, and then refusing to maintain the older branches that support those cards.  That is why we keep seeing people trying to freeze on old driver versions, because they can't use their card with the new driver.  Then they come and report problems when other components change in a way that requires them to update their drivers, which is what happened here.  Usually, their problem is that the old driver does not work with a new kernel, rather than that it conflicts with a userspace change.

Users can choose to have an nVidia driver version that supports old nVidia cards, but conflicts with the glvnd work which, as I understand it, was championed by nVidia (and indeed, is Copyright (c) 2013, NVIDIA CORPORATION.) or they can choose to use a new version that does not support their old nVidia cards, but is compatible with glvnd.  Users could also choose to use Nouveau, which works with glvnd, or to get frustrated and stop using nVidia cards.  Finally, nVidia could choose to backport glvnd support to older driver branches, including those that are otherwise end-of-life, since they caused the problem in the first place by pushing glvnd.  Users are not objecting to the inability to stay on exactly the driver version they have now.  They are objecting to the fact that they must choose among freezing updates, replacing working hardware, or abandoning use of the nVidia proprietary driver.  All those options are bad.  I suggested the one that is (1) free and (2) less likely to cause more problems as time goes on. *lefsha wrote:*   

> What is the problem with GENTOO???
> 
> There is no one who ask you to use that driver. It's a well spread disease among Gentoo developers to delete ebuilds
> 
> for no reason.

 As shown up thread, libglvnd and eselect-opengl conflict.  For good or ill, libglvnd has been declared the way of the future, so eselect-opengl must be dropped.  Old nVidia drivers block that, so they must be dropped unless they are patched to be compatible with it.  No one who can patch them has stepped up to do so, so they are being dropped.

----------

## dmpogo

 *ff11 wrote:*   

> 
> 
> Overlays are part of Gentoo Linux experience. And I believe that every user should have at least one personal overlay.

 

That is not how it used to be.  In the beginning Gentoo mark among distros  was a wider availability of software in the tree relative to other distros.

I came to Gentoo in 2004 from Fedore because Gentoo had 64-bit kernel available (and in stable, was it 2.6.2 ?) and Fedora hasn't it, and I just got my new Opterons with 32 GB RAM.

For quite a few years my expectation was that if hear about some software from colleagues, it will be in the Gentoo tree (not necessarily in stable, of course).

Actually I made my first personal overlay just over a year ago.  Did not have a need for one for 14 years.

----------

## ff11

 *dmpogo wrote:*   

> ...
> 
> That is not how it used to be.  In the beginning Gentoo mark among distros  was a wider availability of software in the tree relative to other distros.
> 
> I came to Gentoo in 2004 from Fedore because Gentoo had 64-bit kernel available (and in stable, was it 2.6.2 ?) and Fedora hasn't it, and I just got my new Opterons with 32 GB RAM.
> ...

 

Well, I'm in the same situation too. But that's how things work now.

I myself have already expressed my opinion on the lack of attractiveness that the current contribution system causes. But I was not taken too seriously. Because the developers of Gentoo Linux do not see this as a problem. So, I embraced the idea of ​​overlays.

If all the individual developers of the overlays could use a more friendly contribution system, then we would have a lot more packages being supported in the main tree. But, with this current system, I myself prefer to keep my ebuilds in my overlay instead of the main tree. And I believe that other overlays developers think the same way too, but you can see this as just my personal opinion.

----------

## Ionen

I'd like this thread to remain informative for people trying to use 340.xx rather than turn into a debate where people will have a hard time to find anything in.

----------

## lefsha

 *ff11 wrote:*   

>  *lefsha wrote:*   ...
> 
> Nouveau is crap, if wasn't clear initially. Even Arch Linux keep 340-108 version available to install. So does NVIDIA.
> 
> What is the problem with GENTOO???
> ...

 

Wrong. I am pretty well aware of overlays and I am using them a lot. They are here for packages, which are not worth

to _create_ for public. Once created ebuild is already there. There is no need to do anything with it, specially in the case, where it is

just a blob.

Try to see work difference - create an ebuild vs delete an ebuild.

Deleting ebuild doesn't require any intellect, rather the opposite is required.

What is the problem with keeping ebuild where it is?

If some one will claim, they want to keep portage tree slim and compact, then it is even bigger lie.

Earlier with rsync I was able to exclude 2/3 of portage tree from storing on disc and from updates.

Now with git I see no such an option. I use no games, nor packages written in stupid languages besides python, no KDE

no many other things taking space.

So single ebuild of 10kb won't change anything!

By the way noglvnd overlay is NOT available as the standard overlay!!! One need really look after it, spending hours.

The last trend of Gentoo removing usefull packages is simply bad.

Comparing to Arch Gentoo has much less packages available to install. And many of them are not working.

Instead of spending time deleting useful packages one can make other packages working...

Since long time I build FreeCAD, Opencascade, OpenFOAM etc myself from sources, because Gentoo ebuild

are either not available or crap. Arch instead has really working packages in that area.

To me it looks like Gentoo developers are painting grass with green color, instead of doing something useful.

I left Arch only because of systemd shit.

Sorry, but I am pretty well aware how to use linux, therefore your argument doesn't work.

Reporting bugs at Gentoo is pretty much useless. The developers tend to make you guilty and

tell you how to solve my local problem, instead of repairing Gentoo. Also the vision of current

generation of Gentoo developers is pretty kinky. They haven't learned what is responsibility

reproducibility and stability.  Something like localhost admins.

I personally can live with that, but for newbies its a nightmare. The system can be made broken

from outside by a single update.

That is what it is all about. Not about nvidia drivers at all. As I said nvidia drivers can be downloaded

and installed directly from nvidia home page in 3 clicks. That is how responsibility looks like!

----------

## lefsha

 *Ionen wrote:*   

> I'd like this thread to remain informative for people trying to use 340.xx rather than turn into a debate where people will have a hard time to find anything in.

 

???

1. People already have hard time to find it. Even before that thread was created.

2. Don't mix ebuild and nvidia drivers. Those can be still downloaded and installed directly from Nvidia home page with 3 clicks.

This way or another if you discuss anything related to Gentoo you talk about ebuilds.

The availability of real binary or source-based packages is independent from Gentoo.

Gentoo is your middleman and not the source of anything you are using at your system,

excluding some scripts where Gentoo developers are the upstream.

If the upsteam, in this case Nividia, will remove corresponding driver from their web page, then yes

Gentoo can do the same. Gentoo cannot be made responsible to keep old drivers on their servers.

P.S. From other point of view, the more troubles Gentoo users will have the more they will push

the developers to change something. People have to suffer, otherwise no changes are possible.

----------

## ff11

@lefsha,

I'm not talking about technical skills, but about using the Gentoo Linux Project. It being a set of people who are helping us by sharing the work they are doing, plus what they are doing and sharing, not because we are paying or enslaving them. So whatever is offered for free to us, should be accepted with gratitude and not with complaints.

I myself, would like to express again to all members of the Gentoo Linux Project: Thank you very much for the excellent work.

----------

## Tom_

I haven't updated my system since my last post in this thread. I'm still really unhappy about the old nvidia-drivers being removed. I wonder how many systems will end up being broken  :Sad: 

If I choose to use Andrew Church's overlay, what about the ebuilds depending on media-libs/libglvnd? I suppose that all these ebuilds must be modified to depend on virtual/opengl instead of media-libs/libglvnd. Right ? 

What about Shibotto's overlay? Does it require similar modifications ?

----------

## dmpogo

 *Tom_ wrote:*   

> I haven't updated my system since my last post in this thread. I'm still really unhappy about the old nvidia-drivers being removed. I wonder how many systems will end up being broken 
> 
> If I choose to use Andrew Church's overlay, what about the ebuilds depending on media-libs/libglvnd? I suppose that all these ebuilds must be modified to depend on virtual/opengl instead of media-libs/libglvnd. Right ? 
> 
> What about Shibotto's overlay? Does it require similar modifications ?

 

Affected systems:    two out of three here  :Sad: 

I am using Andrew Church overlay, and I think you are right,  ebuilds directly dependening on libglvnd  may become a problem.   Currently virtualbox is one of that. unless you compile it without opengl support.

I plan to, but haven't tried yet Shibotto's overlay.  It seems less intrusive in principle, but I don't yet understand what packages dependent on libglvnd will do, if libglvnd is present but does nothing.

As I see, applications with libglvnd  support,  may call libGLX, libGL, and libOpenGL .    libGLX will be provided by nvidia-drivers,  but what about the two wrappers,  libGL and libOpenGL ? What is the app calls functions from there ?

(well, libGL is for compatibility and mesa provides it, perhaps if compiled witn -libglvnd,  but here we go)

----------

## Ionen

With shibotto's overlay packages will link against libglvnd, use its headers, etc... but at runtime nvidia's libraries will be loaded directly rather than go through libglvnd at all (thanks to configuration files with a similar idea as eselect-opengl, except it's integrated with the ebuild). You can think of it like using apulse to replace pulseaudio, packages were built against pulseaudio libraries yet aren't being used and outputting to alsa without the daemon.

For as long as it works I personally recommend it over the noglvnd one unless you really want the old setup which "could" be useful if you have multiple in-use GPUs, but if just want your single old nvidia card to work then modifying mesa/xorg-server and even ebuilds that depend on libglvnd is overkill.

Not that I tried it myself (I don't need 340 anymore), I assume it does work. I don't see a problem with the setup idea anyway  :Smile: 

----------

## dmpogo

 *Ionen wrote:*   

> With shibotto's overlay packages will link against libglvnd, use its headers, etc... but at runtime nvidia's libraries will be loaded directly rather than go through libglvnd 

 

I am here just demonstrating my lack of understanding how does that work.   So I link against libglvnd and lets say during runtime call one of the functions in libOpenGL  (provided by libglvnd).  What happens next ?

----------

## Ionen

It's shared libraries, not static. So you can change what is actually loaded at run time if ABI compatible.

Here I'll link this test executable against the system's libGL, which is from libglvnd:

```
$ gcc -o test test.c -lGL

$ ldd test | grep GL

   libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007ffff7f29000)

   libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0 (0x00007ffff7ce9000)

   libGLX.so.0 => /usr/lib64/libGLX.so.0 (0x00007ffff7cb5000)
```

ldd shows it along with things it's linked against (like GLdispatch).

Let's make us a dummy libGL.so.1 and check ldd again on the same unmodified test executable by setting LD_LIBRARY_PATH to current directory:

```
$ gcc -shared -o libGL.so.1 dummygl.c

$ LD_LIBRARY_PATH=. ldd test | grep GL

   libGL.so.1 => ./libGL.so.1 (0x00007ffff7fc0000)
```

So now it's using the libGL in current directory and doesn't have anything to do with libglvnd anymore (entirely unused). It's gonna call functions from it without knowing, which can be nvidia's libGL.

The standalone ebuild basically replicate that.

----------

## dmpogo

 *Ionen wrote:*   

> It's shared libraries, not static. So you can change what is actually loaded at run time if ABI compatible.
> 
> Here I'll link this test executable against the system's libGL, which is from libglvnd:
> 
> ```
> ...

 

Ok, I understand that.   My concern was that   libglvnd provides both libOpenGL and libGL  while old nvidia - only libGL.  both are wrappers,  but libGL is for 'backward compatibility for applications which link against old ABI'  (I am citing libglnvd README).   Moreover libGL gives access to both dispatcher, and libGLX directly, while libOpenGL only to libGLdispatch.  So I see a potential for applications not to go libGL route at all ?

----------

## Ionen

I don't have anything on my system linked against libOpenGL so I'm not even sure what it's for, pretty sure it doesn't matter for normal usage.

GLdispatch is only used by libglvnd itself and is irrelevant when not in use, applications don't use it directly, they should only care for what they linked against which is normally -lGL

Edit: I might add that what you're doing right now with eselect-opengl isn't really different except that applications linked against mesa instead of libglvnd, then use nvidia's at runtime.

----------

## Ionen

Tried to install nvidia-drivers-340 just to see, tried the test program again:

```
$ gcc -o test test.c -lGL

$ ldd test

   linux-vdso.so.1 (0x00007ffff7fd0000)

   libGL.so.1 => /usr/lib64/opengl/nvidia/lib/libGL.so.1 (0x00007ffff7c64000)

   libc.so.6 => /lib64/libc.so.6 (0x00007ffff7adc000)

   libnvidia-tls.so.340.108 => /usr/lib64/libnvidia-tls.so.340.108 (0x00007ffff78d9000)

   libnvidia-glcore.so.340.108 => /usr/lib64/libnvidia-glcore.so.340.108 (0x00007ffff4cc5000)

[...]
```

And that's with libglvnd installed and no eselect-opengl, seem to be doing as advertised. Not that I can try runtime given I'm not running those drivers.

----------

## dmpogo

 *Ionen wrote:*   

> I don't have anything on my system linked against libOpenGL so I'm not even sure what it's for, pretty sure it doesn't matter for normal usage.
> 
> GLdispatch is only used by libglvnd itself and is irrelevant when not in use, applications don't use it directly, they should only care for what they linked against which is normally -lGL
> 
> Edit: I might add that what you're doing right now with eselect-opengl isn't really different except that applications linked against mesa instead of libglvnd, then use nvidia's at runtime.

 

I have  kwin_x11 linked against libOpenGL  on my intel laptop with libglvnd.  It is also linked against libGL though

GLdispatch  indeed is exposed to applications only via libGL or libOpenGL

----------

## GDH-gentoo

 *Ionen wrote:*   

> I don't have anything on my system linked against libOpenGL so I'm not even sure what it's for

 

I was curious about libOpenGL as well. There is this:

 *Kyle Brenneman wrote:*   

> In addition, there's a new library, libOpenGL.so. It's basically the same as libGL.so, except that it only exports the OpenGL functions, not GLX. It also doesn't depend on libGLX, so it could also be used with an EGL or GLX application. The hope is that future applications will link against libOpenGL.so and either libGLX.so or libEGL.so. This makes for a cleaner separation of OpenGL from the window system binding. But, libGL.so will be kept around indefinitely for backwards compatibility.

 

A diff between libglvnd-v1.3.2/src/GL/gl.symbols and libglvnd-v1.3.2/src/OpenGL/ogl.symbols, and between libglvnd-v1.3.2/src/GL/gl.symbols and libglvnd-v1.3.2/src/GLX/glx.symbols, seems to confirm that libGLX and libOpenGL contain a subset of libGL's symbols. And some others seem to have been just dropped instead of being moved to one of the other libraries.

----------

## dmpogo

 *GDH-gentoo wrote:*   

>  *Ionen wrote:*   I don't have anything on my system linked against libOpenGL so I'm not even sure what it's for 
> 
> I was curious about libOpenGL as well. There is this:
> 
>  *Kyle Brenneman wrote:*   In addition, there's a new library, libOpenGL.so. It's basically the same as libGL.so, except that it only exports the OpenGL functions, not GLX. It also doesn't depend on libGLX, so it could also be used with an EGL or GLX application. The hope is that future applications will link against libOpenGL.so and either libGLX.so or libEGL.so. This makes for a cleaner separation of OpenGL from the window system binding. But, libGL.so will be kept around indefinitely for backwards compatibility. 
> ...

 

Since you have sources to libglvnd unpacked,   have a look at README,  it has a graph of library organization,  which indeed says that libGL is a wrapper to both libGLX and libGLdispatch,

while libOpenGL is a wrapper only to libGLdispatch,

----------

## GDH-gentoo

 *dmpogo wrote:*   

> Since you have sources to libglvnd unpacked,   have a look at README,  it has a graph of library organization,  which indeed says that libGL is a wrapper to both libGLX and libGLdispatch,
> 
> while libOpenGL is a wrapper only to libGLdispatch,

 

Uh-huh, I did read the REAME.md file, but I felt that it did not explain very clearly what was the difference between libGL and libOpenGL (as in why do they both exist), other than that brief mention of some "old ABI" that you quoted in a previous post, and the mention about how they are implemented.

----------

## dmpogo

 *GDH-gentoo wrote:*   

>  *dmpogo wrote:*   Since you have sources to libglvnd unpacked,   have a look at README,  it has a graph of library organization,  which indeed says that libGL is a wrapper to both libGLX and libGLdispatch,
> 
> while libOpenGL is a wrapper only to libGLdispatch, 
> 
> Uh-huh, I did read the REAME.md file, but I felt that it did not explain very clearly what was the difference between libGL and libOpenGL (as in why do they both exist), other than that brief mention of some "old ABI" that you quoted in a previous post, and the mention about how they are implemented.

 

As I understood, libOpenGL is an effort to separate libGLX symbols from OpenGL ones, which are bundled in libGL.  Back in 2016 there was a lively discussion what it should contain

[url]

https://github.com/NVIDIA/libglvnd/issues/63

[/url]

----------

## logrusx

 *Shibotto wrote:*   

> In case you don't care about eselect-opengl, I made my overlay targeting 340 specifically: https://gitlab.com/shibotto/nvidia-legacy
> 
> The main differences from Gentoo's previous implementation are:
> 
> Drop the FreeBSD bits
> ...

 

Unfortunately somebody has "fixed" #711780 with this commit, which has broken this approach, except if you don't revert it manually in a local overlay.

----------

## Ionen

 *logrusx wrote:*   

> Unfortunately somebody has "fixed" #711780 with this commit, which has broken this approach, except if you don't revert it manually in a local overlay.

 This isn't new, this commit is months older than the ebuild from the overlay, and the ebuild provides a dummy "libglvnd" USE to satisfy old dependencies, although I think it should be removed now (flag being missing vs disabled has a different meaning).

That aside, are you getting conflicts? Just tried and still looks fine for me on ~amd64:

```
$ emerge -1av opencl-icd-loader nvidia-drivers:0/340

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N     ] dev-util/opencl-headers-2020.06.16::gentoo  0 KiB

[ebuild  N     ] dev-libs/opencl-icd-loader-2020.06.16::gentoo  USE="-test" ABI_X86="(64) -32 (-x32)" 0 KiB

[ebuild  N     ] media-video/nvidia-settings-340.108:0/340::nvidia-legacy  USE="static-libs -examples" 0 KiB

[ebuild  N     ] virtual/opencl-3-r1::gentoo  ABI_X86="(64) -32 (-x32)" 0 KiB

[ebuild  N     ] x11-drivers/nvidia-drivers-340.108-r3:0/340::nvidia-legacy  USE="X driver (libglvnd) multilib static-libs tools -elogind" ABI_X86="32 (64) (-x32)" 0 KiB

Total: 5 packages (5 new), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] Yes if I needed it :)
```

Not that it builds with my 5.10.x kernel but that's to be expected, I'd use a older LTS branch if needed.

Edit: Have you been doing something like force disabling libglvnd? The point of this approach is to not conflict with gentoo's defaults, so you shouldn't do that.

----------

## logrusx

 *Ionen wrote:*   

>  *logrusx wrote:*   Unfortunately somebody has "fixed" #711780 with this commit, which has broken this approach, except if you don't revert it manually in a local overlay. 
> 
> Edit: Have you been doing something like force disabling libglvnd? The point of this approach is to not conflict with gentoo's defaults, so you shouldn't do that.

 

Indeed I was doing it and it had created a more complicated issue, thanks for the hint!

Regards,

Georgi

----------

## logrusx

However, I resolved the issue, the same way as they solved the original issue before the "fix". I had to rebuild the drivers separately, prior to rebuilding xorg. I'm not sure if this needs follow-up in the bug and even if it's appropriate, when is about a third party ebuild. But in my opinion, the original issue still persists.

----------

## Poopman

Hello! New here.

Thanks Shiba for that overlay because I want to use that driver with my old laptop which obviously has  a Geforce 8400GS.

I'm here to ask for help because I'm running out of ideas because when I install that nvidia-driver overlay, running nvidia-settings gives me this error, don't know what I'm doing wrong:

```
ERROR: The control display is undefined; please run 'nvidia-settings --help' for usage information
```

Can't run xrandr, test my card according to this https://wiki.gentoo.org/wiki/NVIDIA/nvidia-drivers#Testing_the_card, and so on, cuz can't find the display.

Also I give this extra info so if you know what the problem is (?)

cat /usr/src/linux/.config

https://pastebin.com/n2K1nfpL

lspci -k

https://pastebin.com/Hm5rATd1

lsmod

```
Module                  Size  Used by

nvidia              10551296  0
```

Don't know if posting here is correct if not, please move/delete the subject.

If posting any other information is necessary just tell me or help me where to look in the right direction.

Thanks in advanced.

Edit:

Gave up using this driver because of that problem, if someone knows how to figure it out, would be nice to know (using nouveau now).

----------

## KosmiK

Check this plz

https://github.com/achurch/noglvnd/issues/2

This compiles![/url]

----------

## Shibotto

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

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

 *Poopman wrote:*   

> lspci -k
> 
> https://pastebin.com/Hm5rATd1

 

Seeing nvidia_drm as an available module for your card is really suspicious.  Did you mask nvidia-drivers versions other than 340?

----------

## dmpogo

 *Shibotto wrote:*   

> I'm sorry I haven't been around, I totally forgot about this thread, my bad  
> 
> I updated a few things:
> 
> Patches up to linux 5.10
> ...

 

Thanks a lot for your effort !    I have one question, which  comes from even before nvidia-drivers-340  ebuild was forked

when I run it (successfully)  it gives

```

>>> Running pre-merge checks for x11-drivers/nvidia-drivers-340.108-r3

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found sources for kernel version:

 *     4.14.209-gentoo

 * Checking for suitable kernel configuration options...

 *   CONFIG_DRM:         is not set when it should be.

 *   CONFIG_DRM_KMS_HELPER:      is not set when it should be.

 * Please check to make sure these options are set correctly.

 * Failure to do so may cause unexpected problems.

```

I never had these options set as far as I was using my GFORCE 8500 card, through generations of nvidia-drivers  and kernels  since 2007.   Moreover, intially it was recommended to disable DRM in kernel if nvidia-drivers are used.

So do you know, is this warning actually applicable ?     Should I enable them ?  It all runs fine without these kernel options.   I am currently on   4.14.209-gentoo   kernel.

----------

## psycho

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

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

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

```
CONFIG_CHECK="!DEBUG_MUTEXES ~!LOCKDEP ~MTRR ~SYSVIPC ~ZONE_DMA"
```

Since I'm not exactly sure of what is really needed and what is not (and I doubt lazy Nvidia made significant changes since 340 hit legacy) I think I will restore that line.

----------

## Ionen

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

 *Shibotto wrote:*   

> I'm sorry I haven't been around, I totally forgot about this thread, my bad  
> 
> I updated a few things:
> 
> Patches up to linux 5.10
> ...

 

Sadly, actually an update  r2 to r3   did not compile at the end (and r2 was installed for the same kernel just two days ago with no problems).    uvm USE flag is disabled

I got [url]  https://pastebin.com/embed_js/pqCmNZuJ [/url]

one difference that happened in last two days since -r2 was installed was an update to mesa-20.2.6

EDIT:   reinstall r2,   it compiles cleanly even with mesa-20.2.6

(well, cleanly - it produces all that long list of warnings about  ./include/linux/cpumask.h:215:9: warning: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Wsign-compare]

that fills my failed pastebin, now I see this is irrelevant, but then finishes all right)

I wonder if there is something in buildfix_kernel_4.11.patch,  which would apply to my 4.14 kernel

----------

## Shibotto

 *Ionen wrote:*   

> 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).

 

I guess I'm keeping it then, better safe than sorry.  :Razz: 

 *dmpogo wrote:*   

> Sadly, actually an update r2 to r3 did not compile at the end

 

It turns out that the enormous patch for 5.7 broke a couple of things for older kernels, which I didn't notice because I only tested 5.4 and 5.10. It should now build successfully (with and without uvm) from 4.4 to 5.10, although at runtime I only tested 5.4 and 5.10 (since I don't want to spend half a day building kernels   :Laughing:  ).

----------

## dmpogo

 *Shibotto wrote:*   

>  *Ionen wrote:*   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). 
> 
> I guess I'm keeping it then, better safe than sorry. 
> ...

 

Thanks, it compiles just fine now for 4.14.   I'll be watching the runtime

----------

## Poopman

 *Shibotto wrote:*   

> I'm sorry I haven't been around, I totally forgot about this thread, my bad  
> 
> I updated a few things:
> 
> Patches up to linux 5.10
> ...

 

Yep, I masked all of them except 340, but well, i don't have the laptop anymore  :Crying or Very sad:  (died suddenly). I'll try that and more if it happens in another time.

Thanks for your help.

----------

## Shibotto

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.   :Laughing: 

----------

## Ionen

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  :Sad: 

----------

## Shibotto

 *Ionen wrote:*   

> 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).

 

This is wonderful news! The second compromise I hate the most is having those "tools" and "static-libs" USE flag in x11-drivers/nvidia-drivers in order not to break ebuilds depending on libXNVCtrl, so I can't wait to be able to get rid of them too. It would also be very welcome if they end up splitting libXNVCtrl from nvidia-settings for obvious reasons, but now I feel like I'm being too greedy   :Embarassed: 

 *Ionen wrote:*   

> 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 

 

That's what we get for having chosen Nvidia   :Twisted Evil: 

Not that I actually regret it in this particular scenario, since back then the alternatives were ATI, also known as more broken driver than Nvidia, and Intel which was barely able to play a 1080p movie. I'm really glad today the situation is incredibly better if you plan to use a GPU long term, and since I don't need CUDA Nvidia is not seeing a penny from me ever again   :Mad: 

----------

## psycho

 *Shibotto wrote:*   

> since I don't need CUDA Nvidia is not seeing a penny from me ever again  

 

If I hadn't needed CUDA they wouldn't have got a penny out of me in the first place, but sadly I invested in Nvidia cards for that reason, and so have stuck with them despite the fact that I could easily live without CUDA now, and that...well, Linus put it best. I continue to hope that they'll open up their drivers and these cards will suddenly sparkle with a whole new aura of reasonableness...but it's not a rational hope.

----------

## dmpogo

 *Shibotto wrote:*   

> 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.
> ...

 

Well,  they need to get gimp off gtk2  first for sure  :Smile: 

----------

## Ionen

 *Shibotto wrote:*   

> This is wonderful news! The second compromise I hate the most is having those "tools" and "static-libs" USE flag in x11-drivers/nvidia-drivers in order not to break ebuilds depending on libXNVCtrl, so I can't wait to be able to get rid of them too. It would also be very welcome if they end up splitting libXNVCtrl from nvidia-settings for obvious reasons, but now I feel like I'm being too greedy   

 There's chances I may end up maintaining nvidia-drivers myself eventually (I authored the previous 460.56 bump, trivial as it may be), so starting to debate my options now.

Not entirely sure I want to split off nvidia-settings after all (or at least not for now, maybe later), but I do want at least want to make USE=tools optional to get libXNVCtrl.a (haven't check yet but likely easy to build individually). I actually don't use nvidia-settings myself but I have a fan control daemon I wrote that needs the library, and I'd be happy to -tools

Planning to remove virtual/opencl dep as well, as far as I can tell it doesn't make much sense on the drivers until something needs it and they'll depend on opencl themselves. Also debating removing USE=uvm entirely and just installing the module unconditionally (it's always built either way, and would spare things from having to depend on nvidia-drivers[uvm]). USE=kms feels similarly silly (does nothing beside prevent 2 modules install), at most I guess it's convenient not to have the modules get auto-loaded, mostly makes sense on cuda servers.

Will try to make it more viable to install the drivers with -X too (by separating libraries that don't need it, but some hard need GLX), will have to test how this goes on wayland and servers.

Suggestions/oppositions welcome anyway  :Smile:  Nothing set in stone.

Edit: unfortunately re-adding 340.xx is not the table, I'm not "entirely" against it but given old nvidia-drivers have known vulnerabilities it makes it hard to re-add to official ::gentoo

----------

## Shibotto

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  :Laughing: 

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  :Razz: .

 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

 *Shibotto wrote:*   

> 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.

 It's also barely usable even with 390.xx, a lot of the libraries/tools don't easily support old cuda (need gcc8 for that too), ffmpeg needs newer nv-codec-headers, despite 390.xx has x86 support uvm doesn't anymore, etc... OpenCL should still work okay with 390.xx though.

Nice to see some updates anyhow  :Smile:  I do suggest the overlay when I see people want to use 340 still (happens now and then on #gentoo IRC).

I did originally think to reduce amount of things rebuilt as well, but concluded nvidia-settings didn't really take that long.. or at least on non-340-using hardware (and combined with versions typically needing to match, and how the .run normally gives this together, felt it was fine that way). Not that I think splitting it is wrong either, it's just another way to go about it -- plus 340 has its own issues where may need to further drop support for things.

----------

## Shibotto

 *Ionen wrote:*   

> Nice to see some updates anyhow  I do suggest the overlay when I see people want to use 340 still (happens now and then on #gentoo IRC).

 

That's good to hear. Knowing someone other than me could be relying on this is what keeps me motivated to not just scatter the files around in my installation and call it a day   :Laughing: 

 *Ionen wrote:*   

> I did originally think to reduce amount of things rebuilt as well, but concluded nvidia-settings didn't really take that long.. or at least on non-340-using hardware (and combined with versions typically needing to match, and how the .run normally gives this together, felt it was fine that way). Not that I think splitting it is wrong either, it's just another way to go about it -- plus 340 has its own issues where may need to further drop support for things.

 

Yes, even on my 11 years old i3 it takes less than 5 minutes, not exactly an intensive task, especially when things like a webkit implementation join the party... I can't imagine it would make a noticeable difference on a modern system   :Smile: 

Speaking of this, I was wondering about the packages depending on x11-drivers/nvidia-drivers[static-libs,tools] : do they really need the nvidia-settings executable or is it just a remnant of when "static-libs" needed "tools"? These are the ones I found:

```
shiba ~ > find /var/db/repos/gentoo/ -type f -name "*.ebuild" -exec grep "x11-drivers/nvidia-drivers.*\[.*tools" {} +

/var/db/repos/gentoo/xfce-extra/xfce4-sensors-plugin/xfce4-sensors-plugin-1.4.1.ebuild:   video_cards_nvidia? ( x11-drivers/nvidia-drivers[tools,static-libs] )"

/var/db/repos/gentoo/sys-apps/hwloc/hwloc-2.3.0.ebuild:   gl?      ( x11-drivers/nvidia-drivers[static-libs,tools] )

/var/db/repos/gentoo/sys-apps/hwloc/hwloc-1.11.13.ebuild:   gl? ( x11-drivers/nvidia-drivers[static-libs,tools] )

/var/db/repos/gentoo/sys-apps/hwloc/hwloc-2.5.0.ebuild:   gl?      ( x11-drivers/nvidia-drivers[static-libs,tools] )

/var/db/repos/gentoo/app-admin/conky/conky-1.12.2.ebuild:   nvidia? ( x11-drivers/nvidia-drivers[tools,static-libs] )

/var/db/repos/gentoo/app-admin/conky/conky-1.12.1-r1.ebuild:   nvidia? ( x11-drivers/nvidia-drivers[tools,static-libs] )

/var/db/repos/gentoo/media-video/bino/bino-1.6.7.ebuild:   video_cards_nvidia? ( x11-drivers/nvidia-drivers[tools,static-libs] )"

/var/db/repos/gentoo/sci-libs/vtk/vtk-8.2.0-r4.ebuild:   video_cards_nvidia? ( x11-drivers/nvidia-drivers[tools,static-libs] )

/var/db/repos/gentoo/sci-libs/vtk/vtk-9.0.3.ebuild:   video_cards_nvidia? ( x11-drivers/nvidia-drivers[tools,static-libs] )

/var/db/repos/gentoo/mate-extra/mate-sensors-applet/mate-sensors-applet-1.24.1.ebuild:   video_cards_nvidia? ( >=x11-drivers/nvidia-drivers-100.14.09:0[static-libs,tools] )
```

I'm quite sure the MATE/Xfce plugin don't need it, but I don't know about the others.

----------

## Ionen

 *Shibotto wrote:*   

> Speaking of this, I was wondering about the packages depending on x11-drivers/nvidia-drivers[static-libs,tools] : do they really need the nvidia-settings executable or is it just a remnant of when "static-libs" needed "tools"?

 Technically they didn't need to depend tools back then either given the REQUIRED_USE="static-libs? ( tools )" enforcing it. Didn't look but further back in history I imagine this used to not have IUSE=static-libs and tools /was/ the flag to use, then they added static-libs on top.

Since I don't really use nvidia-settings myself but do use the library a bit with my own C code, felt wouldn't hurt to split off the requirement due to less deps.

I doubt anything is using the nvidia-settings binary anyhow, not that I investigated.

Edit: Still waiting to see what nvidia will do with these so it's usable on wayland, may need to refactor a bit eventually (hopefully they give a shared library without having to consider hacking one in like debian did).

----------

## Tom_

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.  :Sad: 

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

----------

## Ionen

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

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  :Very Happy: 

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

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  :Confused: 

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

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.

----------

## Brumi-2021

Hi  Shibotto and Ionen, and Randy Andy , 

Recently I opened a thread about general  Opengl problems , with an old  recycled  laptop, with GPU :  NVIDIA Geforce 9300M GS . 

https://forums.gentoo.org/viewtopic-p-8735719.html#8735719

But after checking re  recently  ,  sudo dsmesg output , I think it is directly related to all this  previous threat . (apologize for it) 

I could read that in that link , I can find my needed NVIDIA driver  (nvidia-drivers-340.108-r4.ebuild)  , 

https://github.com/achurch/noglvnd

I already masked the , >=x11-drivers/nvidia-drivers-390.154   (to block the supported current  gentoo NVIDIA drivers) 

[TXT] nvidia-drivers-390.1..> 12-Jun-2022 19:10   14K  

[TXT] nvidia-drivers-390.1..> 02-Aug-2022 20:40   14K  

[TXT] nvidia-drivers-470.1..> 12-Jun-2022 19:10   15K  

[TXT] nvidia-drivers-470.1..> 02-Aug-2022 20:40   15K  

[TXT] nvidia-drivers-510.7..> 12-Jun-2022 19:10   15K  

[TXT] nvidia-drivers-510.8..> 02-Aug-2022 20:40   15K  

[TXT] nvidia-drivers-515.4..> 21-Jul-2022 08:10   17K  

[TXT] nvidia-drivers-515.5..> 28-Jun-2022 19:40   17K  

[TXT] nvidia-drivers-515.6..> 02-Aug-2022 20:40   17K  

But I am not sure , the commands that I need to do 

for installing  the old   nvidia-drivers-340.108-r4   ,  

and to  integrate it correctly to the my kernel version , inux-5.18.13-pentoo

I could also read on above posts,  that shiboto created and excellent new nvidia legacy 340  repo

https://gitlab.com/shibotto/nvidia-legacy

I read the instructions , and seems clear ,  but I think it would not work with my kernel linux 5.18. 13 .

Congratulations for your great job and strong support to the community! 

Any help or guide  will be highly appreciated, 

Cheers,

----------

