| View previous topic :: View next topic |
| Author |
Message |
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3462
Location: Canada
|
 Posted: Sat Oct 17, 2020 5:17 pm Post subject: |
 |
|
| 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. |
|
| Back to top |
|
 |
ff11
l33t
Joined: 10 Mar 2014
Posts: 664
|
| Posted: Sat Oct 17, 2020 5:34 pm Post subject: |
|
|
| 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.
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. |
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.
_________________
| Proverbs 26:12 |
| There is more hope for a fool than for a wise man that are wise in his own eyes. |
* AlphaGo - The Movie - Full Documentary "I want to apologize for being so powerless" - Lee |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2887
|
| Posted: Sat Oct 17, 2020 5:49 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
lefsha
Veteran
Joined: 30 Aug 2004
Posts: 1235
Location: Burgas, Bulgaria
|
| Posted: Tue Oct 20, 2020 1:17 pm Post subject: |
|
|
| 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???
... |
The problem with Gentoo Linux is that even old users apparently haven't yet learned how to use it.
|
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 |
|
| Back to top |
|
|
lefsha
Veteran
Joined: 30 Aug 2004
Posts: 1235
Location: Burgas, Bulgaria
|
| Posted: Tue Oct 20, 2020 1:29 pm Post subject: |
|
|
| 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.
_________________
Lefsha |
|
| Back to top |
|
|
ff11
l33t
Joined: 10 Mar 2014
Posts: 664
|
| Posted: Tue Oct 20, 2020 3:47 pm Post subject: |
|
|
@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.
_________________
| Proverbs 26:12 |
| There is more hope for a fool than for a wise man that are wise in his own eyes. |
* AlphaGo - The Movie - Full Documentary "I want to apologize for being so powerless" - Lee |
|
| Back to top |
|
|
Tom_
Guru
Joined: 20 May 2004
Posts: 448
Location: France
|
| Posted: Sun Nov 01, 2020 12:59 pm Post subject: |
|
|
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 ? |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3462
Location: Canada
|
| Posted: Sun Nov 01, 2020 4:13 pm Post subject: |
|
|
| 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
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) |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2887
|
| Posted: Sun Nov 01, 2020 8:50 pm Post subject: |
|
|
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  |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3462
Location: Canada
|
| Posted: Mon Nov 02, 2020 7:09 am Post subject: |
|
|
| 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 ? |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2887
|
| Posted: Mon Nov 02, 2020 7:18 am Post subject: |
|
|
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: | Code: | $ 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: | Code: | $ 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. |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3462
Location: Canada
|
| Posted: Mon Nov 02, 2020 7:41 am Post subject: |
|
|
| 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: | Code: | $ 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: | Code: | $ 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. |
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 ? |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2887
|
| Posted: Mon Nov 02, 2020 7:45 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2887
|
| Posted: Mon Nov 02, 2020 7:53 am Post subject: |
|
|
Tried to install nvidia-drivers-340 just to see, tried the test program again: | Code: | $ 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. |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3462
Location: Canada
|
| Posted: Mon Nov 02, 2020 7:55 am Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1778
Location: South America
|
| Posted: Mon Nov 02, 2020 3:10 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3462
Location: Canada
|
| Posted: Mon Nov 02, 2020 4:54 pm Post subject: |
|
|
| 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. |
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. |
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, |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1778
Location: South America
|
| Posted: Mon Nov 02, 2020 5:12 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3462
Location: Canada
|
| Posted: Tue Nov 03, 2020 4:17 am Post subject: |
|
|
| 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] |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2548
|
| Posted: Fri Dec 25, 2020 10:27 am Post subject: |
|
|
| 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
- 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  |
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. |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2887
|
| Posted: Fri Dec 25, 2020 10:47 am Post subject: |
|
|
| 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: | Code: | $ 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. |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2548
|
| Posted: Fri Dec 25, 2020 1:54 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2548
|
| Posted: Fri Dec 25, 2020 7:43 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Poopman
n00b
Joined: 13 Jan 2021
Posts: 2
|
| Posted: Thu Jan 14, 2021 9:17 pm Post subject: |
|
|
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:
| Code: | | 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
| Code: | 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). |
|
| Back to top |
|
|
KosmiK
n00b
Joined: 28 Dec 2006
Posts: 31
Location: Республика Крым. Р.Ф.
|
| Posted: Wed Jan 20, 2021 12:16 pm Post subject: -=:=- |
|
|
Check this plz
https://github.com/achurch/noglvnd/issues/2
This compiles![/url]
_________________
- ....но если ты обманешь нас, дитя, МЫ РАЗОРВЁМ ТВОЮ ДУШУ НА ЧАСТИ! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
