nVidia has provided a new driver for the new RTX 20XX line of GPUs. Are there any chances to get those drivers online soon? Thanks in advance, oh
One important notice. Starting from version 396 (Short Lived Branch), support for a bunch of old GPUs are dropped and 390.* became legacy GPU version. :-( [1] So with updating MASTER nvidia-driver, new legacy port nvidia-driver-390 SHALL be created at the same time (or earlier). See the list between terms "The 390.xx driver supports the following set of GPUs:" and "The 367.xx driver supports the following set of GPUs:" on [2] and [3] for detailed affected GPUs. [1] https://www.nvidia.com/object/unix.html [2] http://us.download.nvidia.com/XFree86/FreeBSD-x86_64/410.73/README/supportedchips.html [3] http://us.download.nvidia.com/XFree86/FreeBSD-x86_64/396.54/README/supportedchips.html Also, users of GRID K340, GRID K1 and GRID K2 needs nvidia-driver-367, but there's no legacy branch upstream.
Created attachment 201533 [details] 410.93 update Note that this patch includes glvnd libs, although it would be much better to package them separately from nvidia-driver. How should we proceed?
(In reply to Alex S from comment #2) > How should we proceed? I'm currently working on the update, given a chance to test it on RXT 2080, weighting different approaches; these new 410 series had indeed brought many disruptions to the driver. Recent Linux-related updates had further complicated the logic, so I'm also considering offloading Linux-related bits to a separate port before updating the driver itself. Sorry for the delay. :-(
I should probably cc dumbbell regarding glvnd (per https://devtalk.nvidia.com/default/topic/1035923/freebsd/do-freebsd-drivers-have-libglvnd-support-/). (In reply to Alexey Dokuchaev from comment #3) By the way, I'm also interested in your opinion on my (rather crude) glibc shim: https://forums.freebsd.org/threads/unreal-engine-4-20-4-21.66785/#post-397179. Currently, it is pretty much the only way get Vulkan (and 32-bit OpenGL with 410+ driver) working. I'm not quite sure what should I do with that thing.
libglvnd is indeed supported on FreeBSD: https://github.com/NVIDIA/libglvnd/releases/tag/v1.1.0 Thinking about creating a port of this as a test.
Created attachment 203770 [details] [new port] graphics/libglvnd-1.1.1 Hi all, The most recent version of the nvidia driver is now 418.56 and I'd love to see the port catch up. I know that the libglvnd changes have complicated supporting the 410* drivers, so I took a crack at creating a new port for it: QA Performed: portlint -a : "looks fine." poudriere (amd64, i386) : OK libglvnd tests (make check) : OK (all passing, but needed to modify tests/testglxmcthreads.sh to use libpthread.so instead of libpthread.so.0. Will file an issue with libglvnd to fix this) QUESTIONS: libEGL/libGL/libGLES libs were changed to lib*-GLVND.so to prevent conflicts with mesa-libs. I assume this is fine since the nvidia-driver port does a similar thing. Should they be changed to lib*-NVIDIA.so to keep consistent with nvidia-driver? I also have myself as maintainer in the patch. I'm happy to maintain it if no one else wants to. I hope this is useful and I'm more than happy to take a shot at fixing up nvidia-driver if you would like me to. Please let me know if there is anything I need to change.
> libEGL/libGL/libGLES libs were changed to lib*-GLVND.so to prevent conflicts with mesa-libs. I assume this is fine since the nvidia-driver port does a similar thing. Looks like I didn't explain myself clearly. The whole point of libglvnd is to provide seamless switching between Mesa and Nvidia OpenGL implementations, which is mostly useful for Optimus laptops. That, however, requires compiling Mesa with whatever necessary settings which would presumably make Mesa depend on libglvnd by default (I don't use Mesa drivers, so no idea) and that is the bit that necessitates a separate libglvnd port.
(In reply to Alex S from comment #7) Ah that makes more sense. I'm not very knowledgable on mesa either, last I heard libglvnd support wasn't stable. I had misunderstood and thought the intention was to just replace the libs currently installed by nvidia-driver with the libglvnd ones. It would pretty much defeat the purpose of libglvnd but would let us update nvidia-driver without changing mesa to use libglvnd.
Hi The driver with the initial patch (410.93 update) fails to provide opengl over here. Xorg.log contains these: > [ 1265.696] (EE) NVIDIA: Failed to load module "glxserver_nvidia" (module does not exist, 0) > [ 1265.696] (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X > [ 1265.696] (EE) NVIDIA(0): log file that the GLX module has been loaded in your X > [ 1265.696] (EE) NVIDIA(0): server, and that the module is the NVIDIA GLX module. If > [ 1265.696] (EE) NVIDIA(0): you continue to encounter problems, Please try > [ 1265.696] (EE) NVIDIA(0): reinstalling the NVIDIA driver.
Created attachment 203837 [details] 418.56 update (In reply to Schaich, Alonso from comment #9) > The driver with the initial patch (410.93 update) fails to provide opengl Fixed.
This patch set works for me with a 2070. [ 25.411] (II) NVIDIA GLX Module 418.56 Fri Mar 15 12:31:45 CDT 2019 [ 26.303] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:1:0:0 [ 26.303] (--) NVIDIA(0): DFP-0 [ 26.303] (--) NVIDIA(0): DFP-1 [ 26.303] (--) NVIDIA(0): DFP-2 [ 26.303] (--) NVIDIA(0): DFP-3 (boot) [ 26.303] (--) NVIDIA(0): DFP-4 [ 26.303] (--) NVIDIA(0): DFP-5 [ 26.304] (II) NVIDIA(0): NVIDIA GPU GeForce RTX 2070 (TU106-B) at PCI:1:0:0 (GPU-0) [ 26.304] (--) NVIDIA(0): Memory: 8388608 kBytes [ 26.304] (--) NVIDIA(0): VideoBIOS: 90.06.2d.00.c9 [ 26.304] (II) NVIDIA(0): Detected PCI Express Link width: 16X
Created attachment 204442 [details] 430.14 update
Updated patch doesn't apply for me. Manually applying also resulted in failure.
(In reply to amvandemore from comment #13) That's a really unflattering choice of words. There have been changes to port in the meantime, so yes, the patch doesn't apply after revision 503722.
Created attachment 205050 [details] 430.26 update
Created attachment 205098 [details] 430.26 update (with 390.87 to 390.116) 390 branch is now 390.116 until Feb.22. Updated related parts. As it runs fine without updating ports (just setting DISTVERSION=390.116 -DNO_CHECKSUM) for me, only updated version and distinfo. stable/12, amd64. I cannot test 430.26 as I don't have devices supported. Legacy 390 branch is the latest for me. :-(
(In reply to Alexey Dokuchaev from comment #3) > weighting different approaches So, have you decided anything?
(In reply to Alex S from comment #17) For the record, I don't remember adding maintainer-feedback flag, empty or otherwise.
Sorry, I got distracted by the big OCaml update which took longer than originally anticipated. I'll switch my attention to nVidia driver ports(s) later this week.
*** Bug 236768 has been marked as a duplicate of this bug. ***
Hello. I am getting EQ overflow errors in my Xorg log. These correspond to my system freezing-up (or at least my mouse and keyboard stop working). The mouse and keyboard work for about 10 seconds before this happens. I'm Running FreeBSD 12.0 with generic kernel (also tried custom, without option VESA). I have switched off my on-board graphics in my AsRock AB350 bios. My primary display is on an nVidia 1660Ti with HDMI. The 430 driver was installed from a patched version of nvidia-driver in the /usr/ports tree. The patch was taken from this bug report page: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232645 I'm running nvidia_modeset and nvidia kernel modules (specified in /boot/loader.conf) and dbus and hald (specified in rc.conf). Also, I am using the xorg.conf generated automatically by nvidia-xconfig (430). I'm using vga textmode (in loader.conf) but it doesn't make any difference with/without. Can someone offer advice on how to resolve this, please? I would be grateful. Thanks, Rob. Various configs / logs can be viewed in this reddit post (where a forum member recommended posting my request for help here): https://www.reddit.com/r/freebsd/comments/c6ay1n/eq_overflow_freebsd_120_nvidia_430_driver_ryzen/
(In reply to robs0419 from comment #21) Would you mind posting that on https://forums.freebsd.org/?
I have done so: https://forums.freebsd.org/threads/eq-overflow-freebsd-12-0-nvidia-430-driver-ryzen-2400g.71281/ Thanks.
(In reply to robs0419 from comment #23) Awaiting approval to be shown publicly...
I confirm 430.26 update patches work for me (GTX850M), however 430.34 is already out. I'm working on an optimus port and I need these updates to be merged before I can make any PR.
(In reply to Alexey Dokuchaev from comment #19) Alexey, if you keep being distracted, would you at least then consider reviewing and possibly merging attached patch before your planned Linux bits refactor?
What is needed for this to move forward?
Is the 430.26 update the latest and is that patch ready to go in. If alexy is to busy this is past the two week window for maintainer timeout with no real large objections or issues with what people want to or how they want to do it. This has been open for 9 months over. So even if more works is needed as long as it doesn't hurt anyone I propose we submit the 432.26/390.116 patch.
Hi niko The 430.26 is *not* the latest driver any more. nVidia released two further versions for the 430 series and one for the 390 one. The patch also doesn't apply to the current ports: applying it to an old ports checkout and copy-pasting the resulted x11/nvidia-driver into a new ports checkout results in a usable driver though. The 430.26 drivers work over here with my quadro k2000 and p620 cards. They massively improve KDE usability over the ports version of the driver even on the 5 year old k2000, as the move to wayland we did last year exposed lots of regressions to nvidia users, most of which are handled by the 400 series updates. We also have FreeBSD-12 now which is not (officially) supported by the ports version of the driver. ... And because noone else mentioned it before: the attached driver ports also address CVE‑2018‑6260, see https://nvidia.custhelp.com/app/answers/detail/a_id/4772 for details.
Created attachment 206228 [details] 430.40 update
(In reply to Schaich, Alonso from comment #29) > The 430.26 is *not* the latest driver any more. > nVidia released two further versions for the 430 series > and one for the 390 one. I don't see the point in updating the patch for every minor driver version, hashes aren't the interesting part there. > The patch also doesn't apply to the current ports Oh, but it does. At least with git.
Thanks Alex for the quick patch to update. I'm trying to ping some other port committers to get this in as a maintainer timeout. If I have time I might also try to add the latest version of 390 to your patch like Tomoaki AOKI did above or if you have time to do this also great.
There are several things needed to be done here before actually bumping the version. I've accumulated some technical debt here, admittedly, but would appreciate if you guys could give me several more days to finally start moving this forward, thank you.
Created attachment 206272 [details] 430.40 update (with 390.87 to 390.129) Updade 390 bits for 430.40 update patch to latest 390.129. Not tested 430.40 bits as I currently don't have hardwares to try with.
Created attachment 206516 [details] 430.40 update v2 Forgot about libnvidia-cbl.so.
Ok, where are we now?
See also bug 241307. I should have added patch here, but for some reason this bug didn't pop up with search "nvidia-driver update".
Hi danfe@, How are you going with this work? I have been running something similar to this attached patch for a month or so now, and since it cuts a new nvidia-driver-390 port it really has very little risk in my mind (people can fall back to the 390 pkg if the newest does not work for them). Would you like me to finalise / polish it this weekend and commit the update? Regards, Ben
Hi, just 2c to comment I have been running this driver without any direct issue... Except that it has to be noted that since there's not equivalent 32bit driver, we can't get any 32bit opengl compat right now. Maybe there should be also a warning regarding that? The ideal would be for nvidia to provide 32bit libraries in this driver now, but I'm under the impression they don't really care nowadays (like with vulkan support in freebsd...). Thanks for continuing to update this driver!
Hi danfe, Sorry to hassle you, but could you please give me an indication on whether you have time to progress this nvidia-driver port update? If you would like, I could test and commit the update? Or do you have something in the works that just needs a bit more time? Regards, Ben
I'm working on it right now. The first part is to move Linux libraries to a separate port (the main reason behind the delay), which is ready and I plan to commit it later tonight once I'm confident things won't break.
Great news - thanks in advance for your efforts :)
(In reply to Matthieu Volat from comment #39) > Maybe there should be also a warning regarding that? Not really, the current 390.x package doesn't install any 32-bit drivers either. > The ideal would be for nvidia to provide 32bit libraries in this driver now, > but I'm under the impression they don't really care nowadays > (like with vulkan support in freebsd...). They don't care because you don't care to complain to them. Also, please Ctrl + F for "Vulkan" on this page.
(In reply to Alex S from comment #43) > Not really, the current 390.x package doesn't install any 32-bit drivers either. Yet they were available and mentionned in packages like i386-wine > They don't care because you don't care to complain to them. Also, please Ctrl + F for "Vulkan" on this page. I did care enough to formaly complain to their customer service which directed me to their support forums, and here is the thread that followed: https://devtalk.nvidia.com/default/topic/1042108/vulkan/vulkan-support-missing-from-freebsd-driver/ And regarding your "search" comment suggesting a solution, I would hardly call hijacking gnu-linux libraries with those stubs companions libs a definitive solution worthy of being packaged alongside the official driver...
(In reply to Matthieu Volat from comment #44) > Yet they were available and mentioned in packages like i386-wine Now, please ask yourself why they aren't available in nvidia-driver instead. Or, more specifically, why one maintainer is working around another maintainer. > hijacking gnu-linux libraries That was uncalled for. "Hijacking" isn't any different from whatever Wine is doing, which is incidentally the only serious Vulkan consumer. It's hacks all the way down. No GNU code is used in the process either. > with those stubs companions libs a definitive solution > worthy of being packaged alongside the official driver... Nobody suggested that.
(In reply to Matthieu Volat from comment #44) > I would hardly call hijacking gnu-linux libraries with those stubs companions libs a definitive solution worthy of being packaged alongside the official driver... If using Nvidia's code outside of what they intended (call it hijacking if you will) is enabling people to use FreeBSD where it would otherwise not meet their requirements, then that is good for the Project. When something goes wrong, the users can complain to Nvidia even though it is an unsupported configuration, which lets Nvidia know that there is the demand.
Just a heads-up, with GTX 1660 S launch tomorrow, there should be a corresponding driver update either to 430 or 440 branch in a few days. It makes more sense to update to 440 now, even if 440.26 is beta release.
(In reply to Alex S from comment #47) > It makes more sense to update to 440 now, even if 440.26 is beta release. If it's beta, shouldn't that be a slave port, nvidia-driver-next? The master port can change as needed to support the structuring of files in the beta as long as the resulting non-beta nvidia-driver package remains unchanged.
(In reply to Alex S from comment #47) Why do we need it if 430 is sufficient?
(In reply to Theron Tarigo from comment #48) > shouldn't that be a slave port, nvidia-driver-next? It's a beta of "long-lived branch release". There will be a non-beta release in a month at worst. Might be even tomorrow. > Why do we need it if 430 is sufficient? We are supposed to track long-lived branch, so why not?
(In reply to Theron Tarigo from comment #48) > If it's beta, shouldn't that be a slave port, nvidia-driver-next? "Beta/Next" slave ports were considered in the past, but given their inherent volatility, this idea was dropped. Instead, the port is constructed in such a way that users should be able to build any version they like with "make DISTVERSION=... -DNO_CHECKSUM". That's the reason behind careful maintaining of those NVVERSION checks.
A commit references this bug: Author: danfe Date: Tue Oct 29 13:44:58 UTC 2019 New revision: 515978 URL: https://svnweb.freebsd.org/changeset/ports/515978 Log: - Update NVidia mainline driver to version 410.104, the latest in the 410.xx series and the last without full Wayland support - Move 390.xx to corresponding legacy slave port and update to the latest version 390.129 PR: 232645 Changes: head/x11/Makefile head/x11/nvidia-driver/Makefile head/x11/nvidia-driver/Makefile.common head/x11/nvidia-driver/distinfo head/x11/nvidia-driver/pkg-plist head/x11/nvidia-driver-390/ head/x11/nvidia-driver-390/Makefile
So what's going on so far: in ports r515584, all the Linuxish libraries and programs were moved to their own ports, untangled from the NVidia driver itself. While the LINUX option was kept (because it affects the build), RUN_DEPENDS on `x11/linux-nvidia-libs' is not being enforced because presumably a bit of slack is fine when versions mismatch slightly. In ports r515978, the mainline driver was updated to 410.104. This is an intermediate step and a base for the upcoming commits. Please check it out and report of any problems or issues. I still need to review `graphics/libglvnd' port submission to see if it's warranted.
(In reply to Alexey Dokuchaev from comment #53) > I still need to review `graphics/libglvnd' port submission to see if it's warranted. This port is needed for Nvidia Optimus to work.
Not sure if this is a bug or a misconfiguration on my part, but... After `startx` /var/log/messages has: Oct 29 14:21:53 eddie kernel: ACPI Error: Field [TBF3] at bit offset/length 356352/32768 exceeds size of target Buffer (368640 bits) (20181003/dsopcode-355) Oct 29 14:21:53 eddie kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.PEG.VID.GETB, AE_AML_BUFFER_LIMIT (20181003/psparse-677) Oct 29 14:21:53 eddie kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.PEG.VID._ROM, AE_AML_BUFFER_LIMIT (20181003/psparse-677) Environment information: `freebsd-version -kru`: 12.0-RELEASE-p10 12.0-RELEASE-p10 12.0-RELEASE-p11 Installed package: nvidia-driver-410.104 Package options: ACPI_PM LINUX I tried it both with and without ACPI_PM, but got the same thing. I use Poudriere to build, so I wondered if the kernel sources within the jail(s) would be an issue. I updated the jail & checked the kernel source tree, and it appeared ok. I tried both ways, with nvidia & nvidia-modeset kmods, and still got the same thing. Let me know if more information is needed. Thank you!
(In reply to P Singh from comment #55) Nevermind, it might be an issue on my end. I realized that those ACPI error messages are probably more like warnings. I was starting KDE with "exec ck-launch-session startkde" in my ~/.xinitrc. I decided to try twm instead, and it started up fine. If I run into any issues with the driver, I'll be sure to post here :)
(In reply to Alexey Dokuchaev from comment #53) > While the LINUX option was kept (because it affects the build), > RUN_DEPENDS on `x11/linux-nvidia-libs' is not being enforced because In my opinion, that dependency should be other way around. > presumably a bit of slack is fine when versions mismatch slightly. Just how much slack is fine? I've never seen OpenGL to work with mismatched kernel/userspace drivers, there is supposedly a version check somewhere.
(In reply to Charlie Li from comment #54) > This port is needed for Nvidia Optimus to work. Optimus (PRIME Render Offload) won't work anytime soon. Right now, libglvnd port is needed simply so _Mesa_ can depend on it. That should be quite a bit better than the current libmap.d/nvidia.conf solution.
(In reply to Charlie Li from comment #54) > > I still need to review `graphics/libglvnd' port submission to see if it's warranted. > This port is needed for Nvidia Optimus to work. This is incorrect. VirtualGL as a technology predates GLVND and is already packaged and working for FreeBSD, and solves the problem that GLVND doesn't address: displaying Nvidia-rendered frames on the integrated GPU. "Primus" would also work; someone says it would need to be ported to FreeBSD, but I think that's just because it requires a GNU toolchain. As for real PRIME offloading, that requires more than just GLVND libraries, and is not currently known to be usable on FreeBSD until Nvidia chooses to provide this support. GLVND does solve some interesting "problems" - I'm not trying to spread FUD on it. I just want to clear the misconception that it is a sticking point for progress with Optimus support. As someone running FreeBSD on systems with various combinations of Intel, AMD, and Nvidia GPU (sometimes all three) I do _NOT_ want Mesa GL depending on GLVND unless there is a very good reason for that (which I will accept once the Mesa project officially adopts GLVND. Is there some movement in that direction?)
(In reply to Theron Tarigo from comment #59) VirtualGL/primus was very buggy on my machines, even back when I still used Linux. Some programs required a delicate LD_PRELOAD in addition to launching with virtualgl/primus in order to have the Nvidia drive things. Thus I am only focusing (my) discussion on PRIME offloading. And even using PRIME offloading requires that program(s) use Nvidia's libGL.so; mesa's will not activate the Nvidia card. Hence why glvnd is brought up now, as it was much uglier pre-glvnd.
(In reply to Theron Tarigo from comment #59) > which I will accept once the Mesa project officially adopts GLVND. > Is there some movement in that direction? What are you talking about? It's a supported configuration: https://bugs.freedesktop.org/show_bug.cgi?id=92877. If you mean that Mesa (the project) should maintain libglvnd itself, that isn't going to happen.
(In reply to Charlie Li from comment #60) > VirtualGL/primus was very buggy on my machines, even back when I still used Linux. It works in many cases and is better than having nothing at all while we wait indefinitely for Nvidia or some third-party to make progress on PRIME. > Some programs required a delicate LD_PRELOAD in addition to launching with virtualgl/primus in order to have the Nvidia drive things. Bug to be filed as of when it becomes a concern. > Thus I am only focusing (my) discussion on PRIME offloading. And even using PRIME offloading requires that program(s) use Nvidia's libGL.so; mesa's will not activate the Nvidia card. Hence why glvnd is brought up now, as it was much uglier pre-glvnd. All options currently on the table, even PRIME on Linux, require environment variable fiddling. Those environment changes can also handle the libGL switchover, which is how VirtualGL normally works when the app is not so bugged that preload hacks are required. >Thus I am only focusing (my) discussion on PRIME offloading. Waiting patiently may work for you but some of us ([1],[2]) want to have something in ports that works for most but not all apps, even if it must be based on older technologies. We've already proven it can work as a FreeBSD port, and in that arrangement, libGLVND is merely an implementation detail of nvidia-driver, not an integral component of VirtualGL-mediated access to the GPU. I have absolutely no objections to splitting libglvnd off into a separate port from nvidia-driver, I just want to reiterate that this isn't blocking progress on "optimus support" achieved through VirtualGL. [1] https://forums.freebsd.org/threads/nvidia-optimus-driver-for-freebsd.71504 [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192617
A commit references this bug: Author: danfe Date: Thu Oct 31 08:51:07 UTC 2019 New revision: 516138 URL: https://svnweb.freebsd.org/changeset/ports/516138 Log: Update NVidia driver to the latest long lived branch version 430.50. PR: 232645, 241307 Changes: head/x11/nvidia-driver/Makefile head/x11/nvidia-driver/distinfo head/x11/nvidia-driver/pkg-plist
*** Bug 241307 has been marked as a duplicate of this bug. ***
danfe, can you please include libnvidia-glvkspirv.so (shader compiler), libnvidia-rtcore.so, libnvidia-cbl.so (ray tracing extension for Vulkan) in linux-nvidia-libs? Those definitely should work under Linuxulator just fine. (In reply to Alex S from comment #43) > They don't care because you don't care to complain to them. Case in point: https://devtalk.nvidia.com/default/topic/1065886/freebsd-solaris/request-include-32-bit-libraries-with-64-bit-drivers/.
Created attachment 214545 [details] Patch Patch for the last Alex request. Tested on i386/amd64 with linux-nvidia-libs{,-390,-340} ports. @danfe, OK to commit this?
(In reply to Gleb Popov from comment #66) > OK to commit this? I have one question: why do you check against 396.024? I think it should be 396.018, no? Otherwise looks good (the check against 410.057 seems correct).
(In reply to Alexey Dokuchaev from comment #67) Likely because libnvidia-glvkspirv.so is not mentioned at http://us.download.nvidia.com/XFree86/Linux-x86_64/396.18/README/installedcomponents.html vs http://us.download.nvidia.com/XFree86/Linux-x86_64/396.24/README/installedcomponents.html. Which indeed looks like an oversight.
(In reply to Alexey Dokuchaev from comment #67) Changelog for 396.024 [1] says > libnvidia-glvkspirv.so, the new Vulkan SPIR-V compiler added in 396.24, cannot be found at run time. I can't find the same page for 018, though. [1]: https://www.nvidia.ru/Download/driverResults.aspx/133876
(In reply to Gleb Popov from comment #69) > I can't find the same page for 018, though. Those libraries, however, are in the distfile, hence I asked. Anyway, I'd leave it at your discretion. Personally I'd go the first version which had these files, but if you prefer to follow official documentation and 024, I won't object.
A commit references this bug: Author: arrowd Date: Mon May 18 08:51:28 UTC 2020 New revision: 535731 URL: https://svnweb.freebsd.org/changeset/ports/535731 Log: x11/linux-nvidia-libs: Install libnvidia-glvkspirv.so, libnvidia-rtcore.so, libnvidia-cbl.so. PR: 232645 Approved by: danfe Changes: head/x11/linux-nvidia-libs/Makefile head/x11/linux-nvidia-libs/pkg-plist
This can be finally closed now?
(In reply to Gleb Popov from comment #72) > This can be finally closed now? It seems so.
With ports r535731 committed, closing per interested parties' agreement. Feel free to reopen if anything's still missing.