Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 713546 - x11-drivers/nvidia-drivers-390.132-r2 USE=libglvnd - (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X log file that the GLX module has been loaded ...
Summary: x11-drivers/nvidia-drivers-390.132-r2 USE=libglvnd - (EE) NVIDIA(0): Failed t...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Jeroen Roovers
URL:
Whiteboard:
Keywords: NeedPatch, PullRequest
Depends on:
Blocks: 728288
  Show dependency tree
 
Reported: 2020-03-19 22:24 UTC by Nathan Zachary
Modified: 2020-08-26 16:55 UTC (History)
12 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emerge-info.tar.gz,3.65 KB, application/gzip)
2020-03-19 22:52 UTC, imatiimba
Details
Xorg.0.tar.gz (Xorg.0.tar.gz,7.30 KB, application/gzip)
2020-03-19 22:53 UTC, imatiimba
Details
Write Xorg configuration snippet adding missing path to ModulePath (nvidia-glx.patch,1.07 KB, patch)
2020-03-22 09:23 UTC, Philippe Valembois
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Zachary gentoo-dev 2020-03-19 22:24:26 UTC
As mentioned in bug 711942, The driver builds properly, but the nvidia GLX module doesn't initialise, so GLX falls back to llvmpipe:

# glxinfo | grep -i render
direct rendering: Yes
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
    GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer,
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: llvmpipe (LLVM 9.0.1, 128 bits)
    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth,
    GL_MESA_ycbcr_texture, GL_NV_conditional_render, GL_NV_depth_clamp,
    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth,
    GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_fog_distance,
    GL_EXT_polygon_offset_clamp, GL_EXT_read_format_bgra, GL_EXT_render_snorm,
    GL_MESA_shader_integer_functions, GL_NV_conditional_render,
    GL_OES_element_index_uint, GL_OES_fbo_render_mipmap, 

# glxinfo | grep -i opengl
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: llvmpipe (LLVM 9.0.1, 128 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 20.0.1
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.1 Mesa 20.0.1
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 20.0.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
# glxinfo | grep -i nvidia
# 

When starting X, I see the following error in the log:

[ 91296.570] (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X
[ 91296.570] (EE) NVIDIA(0):     log file that the GLX module has been loaded in your X
[ 91296.570] (EE) NVIDIA(0):     server, and that the module is the NVIDIA GLX module.  If
[ 91296.570] (EE) NVIDIA(0):     you continue to encounter problems, Please try
[ 91296.570] (EE) NVIDIA(0):     reinstalling the NVIDIA driver. 

I cannot see any other way to ascertain troubleshooting information regarding the GLX module failing to initialise.
Comment 1 imatiimba 2020-03-19 22:52:09 UTC
Created attachment 622914 [details]
emerge --info
Comment 2 imatiimba 2020-03-19 22:53:23 UTC
Created attachment 622916 [details]
Xorg.0.tar.gz
Comment 3 imatiimba 2020-03-19 22:55:53 UTC
Same issue as Nathan with x11-drivers/nvidia-drivers-390.132-r2 and the new libglvnd use flag.

# glxinfo | grep -i render

direct rendering: Yes
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
    GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, 
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: llvmpipe (LLVM 9.0.1, 128 bits)
    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 
    GL_MESA_ycbcr_texture, GL_NV_conditional_render, GL_NV_depth_clamp, 
    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 
    GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_fog_distance, 
    GL_EXT_polygon_offset_clamp, GL_EXT_read_format_bgra, GL_EXT_render_snorm, 
    GL_MESA_shader_integer_functions, GL_NV_conditional_render, 
    GL_OES_element_index_uint, GL_OES_fbo_render_mipmap, 

# glxinfo | grep -i opengl

OpenGL vendor string: VMware, Inc.
OpenGL renderer string: llvmpipe (LLVM 9.0.1, 128 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 20.0.2
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.1 Mesa 20.0.2
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 20.0.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
Comment 4 Nathan Zachary gentoo-dev 2020-03-20 02:30:16 UTC
Just to validate that there wasn't some other update that caused this problem on my system, I reverted the relevant packages via the following procedure:

1. Set "-libglvnd" in /etc/portage/make.conf
2. emerge -C mesa xorg-server nvidia-drivers libglvnd
  * Yes, there was probably a safer method here, but it easily avoided blocks
3. emerge -av mesa xorg-server nvidia-drivers
4. emerge -av @x11-module-rebuild
5. eselect opengl set nvidia

Resulting in the same package versions:

=media-libs/mesa-20.0.1-r1
=x11-base/xorg-server-1.20.7
=x11-drivers/nvidia-drivers-390.132-r2

and trading out =media-libs/libglvnd-1.3.1 for =app-eselect/eselect-opengl-1.3.1-r4

Now, X seems to be using the nvidia GLX module:

# glxinfo | grep -i render
direct rendering: Yes
OpenGL renderer string: GeForce GTX 470/PCIe/SSE2
    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 
    GL_KHR_robustness, GL_KTX_buffer_region, GL_NVX_conditional_render, 
    GL_NV_conditional_render, GL_NV_copy_depth_to_color, GL_NV_copy_image, 
    GL_NV_path_rendering, GL_NV_pixel_data_range, GL_NV_point_sprite, 
    GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted, 
    GL_KHR_robustness, GL_KTX_buffer_region, GL_NVX_conditional_render, 
    GL_NV_conditional_render, GL_NV_copy_depth_to_color, GL_NV_copy_image, 
    GL_NV_path_rendering, GL_NV_pixel_data_range, GL_NV_point_sprite, 
    GL_EXT_multisampled_render_to_texture, 
    GL_EXT_multisampled_render_to_texture2, GL_EXT_occlusion_query_boolean, 
    GL_EXT_render_snorm, GL_EXT_robustness, GL_EXT_sRGB, 
    GL_NV_blend_equation_advanced, GL_NV_conditional_render, 
    GL_NV_packed_float_linear, GL_NV_path_rendering, 
    GL_OES_fbo_render_mipmap, GL_OES_geometry_point_size, 

# glxinfo | grep -i opengl
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 470/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 390.132
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6.0 NVIDIA 390.132
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 390.132
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

# glxinfo | grep -i nvidia
server glx vendor string: NVIDIA Corporation
client glx vendor string: NVIDIA Corporation
OpenGL vendor string: NVIDIA Corporation
OpenGL core profile version string: 4.6.0 NVIDIA 390.132
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL version string: 4.6.0 NVIDIA 390.132
OpenGL shading language version string: 4.60 NVIDIA
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 390.132

So it does seem related to libglvnd.

Cheers,
Nathan Zachary
Comment 5 Jeroen Roovers gentoo-dev 2020-03-21 08:49:32 UTC
Comment on attachment 622916 [details]
Xorg.0.tar.gz

You stored a single file in a tar archive? Why not compress it directly?
Comment 6 Jeroen Roovers gentoo-dev 2020-03-21 09:03:03 UTC
This difference between 390 and newer branches with USE=libglvnd might be relevant.

--- nvidia-drivers-390.132-r2.ebuild    2020-03-15 21:35:29.555564068 +0100
+++ nvidia-drivers-435.21-r1.ebuild     2020-03-10 09:22:44.185664097 +0100
@@ -302,13 +292,8 @@
                doins ${NV_X11}/nvidia_drv.so

                # Xorg GLX driver
-               if use libglvnd; then
-                       local extensions_dir="/usr/$(get_libdir)/extensions/nvidia"
-               else
-                       local extensions_dir="/usr/$(get_libdir)/opengl/nvidia/extensions/"
-               fi
-               donvidia ${NV_X11}/libglx.so.${NV_SOVER} \
-                       "${extensions_dir}"
+               donvidia ${NV_X11}/libglxserver_nvidia.so.${NV_SOVER} \
+                       /usr/$(get_libdir)/xorg/modules/extensions

                # Xorg nvidia.conf
                if has_version '>=x11-base/xorg-server-1.16'; then
Comment 7 Philippe Valembois 2020-03-22 09:22:22 UTC
Main problem here is that 390 version isn't modular enough and still uses a full proprietary version of libglx on server side.
Newest versions of nvidia-drivers use a libglxserver_nvidia module on server side that avoids to override the loaded libglx.

I attach a patch to the current ebuild which adds NVidia libglx path to the Xorg module search path.
Comment 8 Philippe Valembois 2020-03-22 09:23:30 UTC
Created attachment 624156 [details, diff]
Write Xorg configuration snippet adding missing path to ModulePath
Comment 9 Marek Duranik 2020-04-09 12:50:06 UTC
Hello,

When I tried apply patch from above, I got an error:


  * Applying nvidia-glx.patch ...
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- /usr/portage/x11-drivers/nvidia-drivers/nvidia-drivers-390.132-r2.ebuild   2020-03-17 18:31:12.426447691 +0100
|+++ nvidia-drivers-390.132-r2.ebuild   2020-03-22 09:48:09.399574792 +0100
--------------------------
No file to patch.  Skipping patch.
2 out of 2 hunks ignored                                                                                               [ !! ]
 * ERROR: x11-drivers/nvidia-drivers-390.132-r2::gentoo failed (prepare phase):
 *   patch -p1  failed with /etc/portage/patches/x11-drivers/nvidia-drivers-390.132-r2/nvidia-glx.patch
 * 
 * Call stack:
 *               ebuild.sh, line  125:  Called src_prepare
 *             environment, line 4152:  Called default
 *      phase-functions.sh, line  855:  Called default_src_prepare
 *      phase-functions.sh, line  920:  Called __eapi6_src_prepare
 *             environment, line  422:  Called eapply_user
 *             environment, line 1312:  Called eapply '/etc/portage/patches/x11-drivers/nvidia-drivers-390.132-r2/nvidia-glx.patch'
 *             environment, line 1282:  Called _eapply_patch '/etc/portage/patches/x11-drivers/nvidia-drivers-390.132-r2/nvidia-glx.patch'
Comment 10 Philippe Valembois 2020-04-12 09:40:38 UTC
The patch must be applied on the ebuild not through epatch_user mechanism
Comment 11 Ralf Elmering 2020-04-17 11:14:14 UTC
@Phillipe,
your patch (creating a nvidia-glx.conf which overwrites the "ModulePath") doesn't work with hybrid graphic systems like my Thingpad W520 with a build in intel and a discrete nvidia card. 

In my case i left the x11-drivers/nvidia-drivers-390.132-r2 as is and modified only the bumblebee.conf file in order to resolve the glx-problem.

Cheers, Ralf
Comment 12 Jeroen Roovers gentoo-dev 2020-05-21 07:05:26 UTC
(In reply to Ralf Elmering from comment #11)
> @Phillipe,
> your patch (creating a nvidia-glx.conf which overwrites the "ModulePath")
> doesn't work with hybrid graphic systems like my Thingpad W520 with a build
> in intel and a discrete nvidia card. 
> 
> In my case i left the x11-drivers/nvidia-drivers-390.132-r2 as is and
> modified only the bumblebee.conf file in order to resolve the glx-problem.

Is it safe to conclude that this is this a problem that cannot be fixed in the 390 branch at all (until Nvidia fix it in the libraries)? I.e. USE=libglvnd is broken in general for 390?
Comment 13 Philippe Valembois 2020-05-21 14:24:34 UTC
I would say so.

In post-390 drivers NVidia provides a Xorg server extension which is loaded aside Xorg libglx.so.
In 390 and before, NVidia provides a replacement libglx.so which doesn't work with any non-NVidia implementations (namely Mesa).
My patch just overrides the loading of the GLX extension like eselect does (without messing with symlinks though).

I think that, for 390 branch, NVidia stopped halfway and provide a glvnd implementation with works client side but miss the part server side to be really useful.
As 390 branch is in maintenance, I suppose it won't get a better support for this.
Comment 14 lg188 2020-06-17 19:21:01 UTC
(In reply to Philippe Valembois from comment #8)
> Created attachment 624156 [details, diff] [details, diff]
> Patch fixing the loading of NVidia libglx.so

This patch has fixed the problem for me currently. Would greatly appreciate if this became in some capacity part of the main repo or could be applied outside of the repo.
Comment 15 Ștefan Talpalaru 2020-07-16 22:33:43 UTC
Patch applied to nvidia-drivers-390.138-r100 in my overlay: https://github.com/stefantalpalaru/gentoo-overlay
Comment 16 Matt Turner gentoo-dev 2020-08-12 21:32:47 UTC
I asked the libglvnd maintainer for guidance, and he suggested that nvidia-drivers should install an xorg.conf.d file. See https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/208#note_596647

Could someone give that a shot?
Comment 17 Nathan Zachary gentoo-dev 2020-08-12 23:05:37 UTC
(In reply to Matt Turner from comment #16)
> I asked the libglvnd maintainer for guidance, and he suggested that
> nvidia-drivers should install an xorg.conf.d file. See
> https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/208#note_596647
> 
> Could someone give that a shot?

I got rid of eselect-opengl and mesa in order to try installing the current 390.x driver with libglvnd.  I then added the mentioned section to the end of my /etc/X11/xorg.conf.d/nvidia.conf file:


# cat /etc/X11/xorg.conf.d/nvidia.conf 
Section "Files"
#	ModulePath	"/usr/lib64/xorg/modules/"
#	ModulePath	"/usr/lib64/extensions/nvidia/"
EndSection

Section "Device"
	Identifier	"nvidia"
	Driver		"nvidia"
	VendorName	"NVIDIA Corporation"
	BoardName	"GeForce GTX 470"
	Option		"TripleBuffer" "0"
	Option		"Coolbits" "12"
#	Option 		"AllowUnofficialGLXProtocol" "1"
	Option		"RegistryDwords" "PowerMizerEnable=0x1; PowerMizerDefaultAC=0x3"
EndSection

Section "OutputClass"
    Identifier "nvidia"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowEmptyInitialConfiguration"
    ModulePath "/usr/lib64/extensions/nvidia/"
EndSection



Thereafter, it seems to be working:


# glxinfo | grep -i render
direct rendering: Yes
OpenGL renderer string: GeForce GTX 470/PCIe/SSE2
    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 
    GL_KHR_robustness, GL_KTX_buffer_region, GL_NVX_conditional_render, 
    GL_NV_conditional_render, GL_NV_copy_depth_to_color, GL_NV_copy_image, 
    GL_NV_path_rendering, GL_NV_pixel_data_range, GL_NV_point_sprite, 
    GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted, 
    GL_KHR_robustness, GL_KTX_buffer_region, GL_NVX_conditional_render, 
    GL_NV_conditional_render, GL_NV_copy_depth_to_color, GL_NV_copy_image, 
    GL_NV_path_rendering, GL_NV_pixel_data_range, GL_NV_point_sprite, 
    GL_EXT_multisampled_render_to_texture, 
    GL_EXT_multisampled_render_to_texture2, GL_EXT_occlusion_query_boolean, 
    GL_EXT_render_snorm, GL_EXT_robustness, GL_EXT_sRGB, 
    GL_NV_blend_equation_advanced, GL_NV_conditional_render, 
    GL_NV_packed_float_linear, GL_NV_path_rendering, 
    GL_OES_fbo_render_mipmap, GL_OES_geometry_point_size, 
# glxinfo | grep -i opengl
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 470/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 390.138
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6.0 NVIDIA 390.138
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 390.138
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:


Thanks for the update and proposed fix!

Cheers,
Nathan Zachary
Comment 18 Jeroen Roovers gentoo-dev 2020-08-13 07:41:16 UTC
Comment on attachment 624156 [details, diff]
Write Xorg configuration snippet adding missing path to ModulePath

>--- /usr/portage/x11-drivers/nvidia-drivers/nvidia-drivers-390.132-r2.ebuild	2020-03-17 18:31:12.426447691 +0100
>+++ nvidia-drivers-390.132-r2.ebuild	2020-03-22 09:48:09.399574792 +0100
>@@ -171,10 +171,14 @@
> 
> 	if ! [ -f nvidia_icd.json ]; then
> 		cp nvidia_icd.json.template nvidia_icd.json || die
> 		sed -i -e 's:__NV_VK_ICD__:libGLX_nvidia.so.0:g' nvidia_icd.json || die
> 	fi
>+
>+	echo 'Section "Files"' > nvidia-glx.conf
>+	echo "	ModulePath \"/usr/$(get_libdir)/extensions/nvidia,/usr/$(get_libdir)/xorg/modules\"" >> nvidia-glx.conf

What is /usr/$(get_libdir)/extensions/nvidia ? Looks like a typo or like it serves no purpose.


>+		if use libglvnd; then
>+			newins {,10-}nvidia-glx.conf
>+		fi

I wonder if it matters whether USE=libglvnd. Shouldn't it also work without the Nvidia Xorg module being actively used? All that the configuration snippet did was to add two paths to ModulePath, right?
Comment 19 Matt Turner gentoo-dev 2020-08-13 17:26:45 UTC
(In reply to Jeroen Roovers from comment #18)
> I wonder if it matters whether USE=libglvnd. Shouldn't it also work without
> the Nvidia Xorg module being actively used? All that the configuration
> snippet did was to add two paths to ModulePath, right?

Yes, I think we want to ignore that proposed solution and go with what's referenced in comments 16 and 17.
Comment 20 Philippe Valembois 2020-08-15 08:30:49 UTC
Just FYI, the approach in the path is from Ubuntu packages.
I may have just copied paths and adapted them without further thinking.

IMO approach in comments #16/#17 and in #8 are similar, it's just a matter of adding a module path to the server.

For the glvnd USE flag, I think it should be kept as hybrid graphics (comment #11) can't work with -390 and libglvnd because we have to replace libglx in Xorg server to make NVidia implementation work. In this case, libGLX (client-side) from Mesa doesn't work anymore because it can't find its matching server implementation (provided by glvnd).
Comment 21 Matt Turner gentoo-dev 2020-08-22 22:50:44 UTC
(In reply to Philippe Valembois from comment #20)
> Just FYI, the approach in the path is from Ubuntu packages.
> I may have just copied paths and adapted them without further thinking.
> 
> IMO approach in comments #16/#17 and in #8 are similar, it's just a matter
> of adding a module path to the server.
> 
> For the glvnd USE flag, I think it should be kept as hybrid graphics
> (comment #11) can't work with -390 and libglvnd because we have to replace
> libglx in Xorg server to make NVidia implementation work. In this case,
> libGLX (client-side) from Mesa doesn't work anymore because it can't find
> its matching server implementation (provided by glvnd).

Please suggest a config file that will allow that to work.
Comment 22 Philippe Valembois 2020-08-23 10:02:44 UTC
I don't think there is one. Hence, the need to keep libglvnd USE flag around.
Unsetting it let user choose the implementation he wants to use through eselect opengl.
Comment 23 Matt Turner gentoo-dev 2020-08-23 18:18:16 UTC
The recommendation from upstream is to use primusrun.
Comment 24 Larry the Git Cow gentoo-dev 2020-08-25 17:44:22 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cb335d5d9efcb79e99a8c8fc2fbce91610050bcd

commit cb335d5d9efcb79e99a8c8fc2fbce91610050bcd
Author:     Matt Turner <mattst88@gentoo.org>
AuthorDate: 2020-08-25 17:12:58 +0000
Commit:     Matt Turner <mattst88@gentoo.org>
CommitDate: 2020-08-25 17:42:45 +0000

    x11-drivers/nvidia-drivers: Add xorg.conf file to set ModulePath
    
    Closes: https://bugs.gentoo.org/713546
    Signed-off-by: Matt Turner <mattst88@gentoo.org>

 x11-drivers/nvidia-drivers/files/nvidia-390.conf                   | 7 +++++++
 ...-drivers-390.138-r1.ebuild => nvidia-drivers-390.138-r2.ebuild} | 3 +++
 2 files changed, 10 insertions(+)
Comment 25 Ionen Wolkens 2020-08-26 01:57:56 UTC
I don't think the fix is right. It points to "/usr/lib/nvidia/xorg" but I installed 390 and that directory doesn't exist.

Formerly suggested path was "/usr/lib64/extensions/nvidia" although probably also needs consideration for non-lib64 users.
Comment 26 Ionen Wolkens 2020-08-26 02:31:24 UTC
(In reply to Ionen Wolkens from comment #25)
> although probably also needs consideration for non-lib64 users.
Well, I think the old comment #8 had the right direction, generated a simple file with $(get_libdir) rather than a static one (minus not needing to specify both paths).

Alternatively I guess the libglx.so{,.390.138} could be installed somewhere else if that's preferable. Currently defined by:
        if use libglvnd; then
            local extensions_dir="/usr/$(get_libdir)/extensions/nvidia"
        else
            local extensions_dir="/usr/$(get_libdir)/opengl/nvidia/extensions/"
        fi
Comment 27 Larry the Git Cow gentoo-dev 2020-08-26 05:32:19 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4b39ac5d997c6201aa3f3441f3a3dab040b9c281

commit 4b39ac5d997c6201aa3f3441f3a3dab040b9c281
Author:     Matt Turner <mattst88@gentoo.org>
AuthorDate: 2020-08-26 05:31:05 +0000
Commit:     Matt Turner <mattst88@gentoo.org>
CommitDate: 2020-08-26 05:32:11 +0000

    x11-drivers/nvidia-drivers: Fix libdir
    
    Thanks to Ionen Wolkens for noticing the mistake.
    
    Bug: https://bugs.gentoo.org/show_bug.cgi?id=713546
    Signed-off-by: Matt Turner <mattst88@gentoo.org>

 x11-drivers/nvidia-drivers/files/nvidia-390.conf                     | 2 +-
 ...ia-drivers-390.138-r2.ebuild => nvidia-drivers-390.138-r3.ebuild} | 5 ++++-
 2 files changed, 5 insertions(+), 2 deletions(-)
Comment 28 Ionen Wolkens 2020-08-26 06:35:15 UTC
That's still wrong. Sorry maybe I should've put more emphasis on that the entire path was wrong, the libdir was just was an additional issue.

It's installing the libglx.so module in /usr/<libdir>/extensions/nvidia/ as the ebuild snipplet from comment #26 shows. not /usr/<libdir>/nvidia/opengl/
Comment 29 Ionen Wolkens 2020-08-26 06:49:37 UTC
I do think /usr/<libdir>/nvidia/xorg from the .conf file is a better location than extensions/nvidia, so changing where it installs could be considered as well.
Comment 30 Matt Turner gentoo-dev 2020-08-26 06:51:17 UTC
I give up.

Someone with hardware, please write a damn patch that satisfies you.
Comment 31 Ionen Wolkens 2020-08-26 06:52:15 UTC
Well I don't either, I just built the thing and checked where it installed things. I don't think it's sorcery.
Comment 32 Jan Seeger 2020-08-26 07:27:37 UTC
I'm working on it.
Comment 33 Larry the Git Cow gentoo-dev 2020-08-26 16:55:06 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=16721b5ac2192d993b6d9c743ce8244f1e90055e

commit 16721b5ac2192d993b6d9c743ce8244f1e90055e
Author:     Stephan Hartmann <stha09@googlemail.com>
AuthorDate: 2020-08-26 10:12:29 +0000
Commit:     Matt Turner <mattst88@gentoo.org>
CommitDate: 2020-08-26 16:54:58 +0000

    x11-drivers/nvidia-drivers: fix path to GLX module
    
    Tested with GeForce GTX 560 Ti
    
    Bug: https://bugs.gentoo.org/713546
    Closes: https://github.com/gentoo/gentoo/pull/17267
    Signed-off-by: Stephan Hartmann <stha09@googlemail.com>
    Signed-off-by: Matt Turner <mattst88@gentoo.org>

 x11-drivers/nvidia-drivers/files/nvidia-390.conf                        | 2 +-
 ...vidia-drivers-390.138-r3.ebuild => nvidia-drivers-390.138-r4.ebuild} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)