[gentoo-amd64] Nvidia or Xorg Problem with GLX

[gentoo-amd64] Nvidia or Xorg Problem with GLX

[Frank Peters]

Hello,

My system has been running well but just by chance I noticed a strange
error in my xorg-server log:

(EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X
(EE) NVIDIA(0): log file that the GLX module has been loaded in your X
(EE) NVIDIA(0): server, and that the module is the NVIDIA GLX module.

The X log indeed indicates that the loaded GLX module is *not* the nvidia
GLX module:

(II) LoadModule: "glx"
(II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
(II) Module glx: vendor="X.Org Foundation"

As a consequence, the nvidia glx module fails to initialize and I suppose
that opengl has fallen back to software rendering.

I cannot pinpoint this error to any specific change in my system because,
as I mentioned, my system has been running well and there has been no need
to check the logs or to check anything else.

After doing some searching, I did find that others have reported the same
problem and the solution is to delete the Xorg glx module, which is located
at /usr/lib64/xorg/modules/extensions/libglx.so.  After deleting (or renaming)
this file and then restarting X the problem vanishes.

However, this solution is far from ideal.  There must be a proper way to
fix this issue.

Does anyone have any insight or suggestions?

My xorg.conf has the necessary module paths set:

ModulePath "/usr/lib64/xorg/modules"
ModulePath "/usr/lib64/opengl/nvidia"

My eselect is set to opengl nvidia:

eselect opengl list
Available OpenGL implementations:
  [1]   nvidia *
  [2]   xorg-x11

Also, re-installing the nvidia-drivers, as the X log file suggests,
did not solve the problem.

Until I find a proper fix, I'll have to keep the xorg glx module
deleted.

Frank Peters

Re: [gentoo-amd64] Nvidia or Xorg Problem with GLX

[Brandon Vincent]

On Mon, Jan 19, 2015 at 11:56 AM, Frank Peters <frank.peters@comcast.net> wrote:
> Does anyone have any insight or suggestions?

Looks like a known bug [1].

[1] https://bugs.gentoo.org/show_bug.cgi?id=534128

Brandon Vincent

Re: [gentoo-amd64] Nvidia or Xorg Problem with GLX

[Frank Peters]

On Mon, 19 Jan 2015 12:37:49 -0700
Brandon Vincent <Brandon.Vincent@asu.edu> wrote:

> 
> Looks like a known bug [1].
> 

A few of the reports on this issue that I've found date back
to 2010 and even earlier:

https://forums.geforce.com/default/topic/369385/geforce-drivers/failed-to-initialize-the-glx-module-can-39-t-init-glx-driver-on-fedoracore-6/

I would doubt that this problem is really new, but it has never
affected me before.

Frank Peters

Re: [gentoo-amd64] Nvidia or Xorg Problem with GLX [Solved]

[Frank Peters]

On Mon, 19 Jan 2015 13:56:40 -0500
Frank Peters <frank.peters@comcast.net> wrote:

>
> NVIDIA(0): Failed to initialize the GLX module;
>

It seems that the order of the module paths in xorg.conf
makes all the difference.

By placing the nvidia GLX directory before the xorg GLX
directory the problem disappears and the nvidia GLX drivers
are loaded correctly.

Before (in xorg.conf):

ModulePath "/usr/lib64/xorg/modules"
ModulePath "/usr/lib64/opengl/nvidia"
 
After:

ModulePath "/usr/lib64/opengl/nvidia"
ModulePath "/usr/lib64/xorg/modules"

Now things work as expected.

Apparently this path ordering was not necessary before some
change was made either to either to xorg-server or nvidia-drivers.
I had not experienced the problem until very recently even though
my xorg.conf contained the reverse ordering.

This is the proper solution that I was seeking.  Now there is no
need for deleting/renaming files as a workaround.

Frank Peters

Re: [gentoo-amd64] Nvidia or Xorg Problem with GLX [Solved]

[Drake Donahue]

On Tue, 2015-01-20 at 12:27 -0500, Frank Peters wrote:
> On Mon, 19 Jan 2015 13:56:40 -0500
> Frank Peters <frank.peters@comcast.net> wrote:
> 
> >
> > NVIDIA(0): Failed to initialize the GLX module;
> >
> 
> It seems that the order of the module paths in xorg.conf
> makes all the difference.
> 
> By placing the nvidia GLX directory before the xorg GLX
> directory the problem disappears and the nvidia GLX drivers
> are loaded correctly.
> 
> Before (in xorg.conf):
> 
> ModulePath "/usr/lib64/xorg/modules"
> ModulePath "/usr/lib64/opengl/nvidia"
>  
> After:
> 
> ModulePath "/usr/lib64/opengl/nvidia"
> ModulePath "/usr/lib64/xorg/modules"
> 
> Now things work as expected.
> 
> Apparently this path ordering was not necessary before some
> change was made either to either to xorg-server or nvidia-drivers.
> I had not experienced the problem until very recently even though
> my xorg.conf contained the reverse ordering.
> 
> This is the proper solution that I was seeking.  Now there is no
> need for deleting/renaming files as a workaround.
> 
> Frank Peters
> 
> 
IMHO, whoever is assigned to maintain the eselect-opengl ebuild has been
having trouble for about 3 months now. Your solution to your problem is
lovely. 

Re: [gentoo-amd64] Nvidia or Xorg Problem with GLX [Solved]

[Frank Peters]

On Tue, 20 Jan 2015 12:47:36 -0500
Drake Donahue <donahue95@comcast.net> wrote:

> 
> IMHO, whoever is assigned to maintain the eselect-opengl ebuild has been
> having trouble for about 3 months now. Your solution to your problem is
> lovely. 
> 

I really don't know why it works.  I just tried it on a lark and it
succeeded.

I'm also not sure that it even _should_ work.  The module path order
should not make a difference as long as all the appropriate paths
are specified.

There seems to have been changes made somewhere to either xorg-server
or nvidia-drivers but as long as things work for me I'll just move on
and not investigate further.

Frank Peters

[gentoo-amd64] Re: Nvidia or Xorg Problem with GLX [Solved]

[Duncan]

Frank Peters posted on Tue, 20 Jan 2015 18:17:26 -0500 as excerpted:

> On Tue, 20 Jan 2015 12:47:36 -0500 Drake Donahue <donahue95@comcast.net>
> wrote:
> 
> 
>> IMHO, whoever is assigned to maintain the eselect-opengl ebuild has
>> been having trouble for about 3 months now. Your solution to your
>> problem is lovely.
>> 
>> 
> I really don't know why it works.  I just tried it on a lark and it
> succeeded.
> 
> I'm also not sure that it even _should_ work.  The module path order
> should not make a difference as long as all the appropriate paths are
> specified.
> 
> There seems to have been changes made somewhere to either xorg-server or
> nvidia-drivers but as long as things work for me I'll just move on and
> not investigate further.

The changes were to eselect-opengl and how it deals with multiple library 
providers of the same general functionality.

Previously, eselect-opengl handled it with symlinks, eselecting one or 
the other opengl provider would adjust the symlinks appropriately, and 
the xorg configuration remained fixed.

With xorg.conf.d directories now being the preferred configuration 
method, eselect-opengl now uses that, changing the 20-opengl.conf or 
whatever file it drops into the xorg.conf.d dir, instead of changing 
symlinks.

Which in general works, for people with either relatively new 
installations without the old cruft, and for people with older 
installations who have kept their configuration updated and weeded out 
the old cruft as they went.

But some people, generally with older configurations that haven't been 
kept updated in accordance with the latest xorg configuration state-of-
the-art, are finding the new eselect-opengl "configlet file" method isn't 
quite compatible with their old configuration.

On top of the usual configuration changes that would come with the 
update, there appears to be a bug, something to do with multiple files 
section entries but with certain other conditions that aren't yet fully 
sorted, that's keeping xorg from properly parsing these multiple file 
section entries.  Which of course adds to the confusion.

But the bottom line remains pretty basic, ensure that your desired 
functionality providers (in this case the servantware nvidia providers) 
are loaded first, either by screwing with the modules path order, or by 
deleting no longer needed bits of the config, until it works.

And thru all the confusion you've obviously found something that's 
working for you ATM, so consider yourself lucky and go with it... until 
the next time the configuration format changes up and you find something 
broken, at least. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: Nvidia or Xorg Problem with GLX [Solved]

[Frank Peters]

On Wed, 21 Jan 2015 02:29:41 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> 
> With xorg.conf.d directories now being the preferred configuration 
> method, eselect-opengl now uses that, changing the 20-opengl.conf or 
> whatever file it drops into the xorg.conf.d dir, instead of changing 
> symlinks.
> 

I would hesitate to use the term "preferred configuration."

Although I am venturing into philosophical areas with this comment,
Xorg has taken the stance of being very versatile in its configuration
scheme, and that is how it should be.

According to the xorg.conf man page:

"Xorg supports several mechanisms for supplying/obtaining configuration
and run-time parameters: command line options,  environment  variables,
the  xorg.conf and xorg.conf.d configuration files, auto-detection, and
fallback defaults ..."

IMO it is an excellent design to allow the user so much choice in handling
how his X server is configured.  To suddenly single out a "preferred" method
from this versatile approach is a definite injustice.

But I certainly appreciate the background information on eselect.  I haven't
paid much attention to it because my system has been performing quite well
over the years (in spite of my deliberate flaunting of convention in many
areas).  Ordinarily I would prefer to avoid such contrivances and rely on
manual tweaking, but sometimes I just cannot do it all.

Frank Peters

[gentoo-amd64] Re: Nvidia or Xorg Problem with GLX [Solved]

[Duncan]

Frank Peters posted on Wed, 21 Jan 2015 10:54:35 -0500 as excerpted:

> On Wed, 21 Jan 2015 02:29:41 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> With xorg.conf.d directories now being the preferred configuration
>> method, eselect-opengl now uses that, changing the 20-opengl.conf or
>> whatever file it drops into the xorg.conf.d dir, instead of changing
>> symlinks.
>> 
> I would hesitate to use the term "preferred configuration."
> 
> Although I am venturing into philosophical areas with this comment,
> Xorg has taken the stance of being very versatile in its configuration
> scheme, and that is how it should be.
> 
> According to the xorg.conf man page:
> 
> "Xorg supports several mechanisms for supplying/obtaining configuration
> and run-time parameters: command line options,  environment  variables,
> the  xorg.conf and xorg.conf.d configuration files, auto-detection, and
> fallback defaults ..."
> 
> IMO it is an excellent design to allow the user so much choice in
> handling how his X server is configured.  To suddenly single out a
> "preferred" method from this versatile approach is a definite injustice.

The user may, of course, use whatever configuration method _they_ prefer, 
including dynamic via commandline, likely via script.

However, in the context I was using it above, that is, in regard to 
eselect, "preferred" applies as much to the distribution's normal default 
config, as variance from the upstream-shipped builtins, as much as to the 
user's config, as variance from the distro-shipped configuration.

... Tho of course with a meta-distro such as gentoo, there's a distinct 
blurring of the lines, because gentoo-user/admins build their own using 
ebuilds, which expose many of the traditionally upstream and distro level 
build-time choices directly to the user/admin.  But the general upstream/
distro/user level config roles still apply to /some/ extent, and as such, 
remain useful characterizations. ...

Anyway...

The distro-level flexibility (and thus preferred status) of the *.d drop-
in-directory approach is that it's dynamic and largely automated -- and 
upstream too has been tilting toward dynamic/automated configuration, 
thus expanding support for this sort of thing dramatically over the 
years, see the hotplug dynamics of inputclass sections as opposed to 
(legacy) individually configured input device sections, for instance, as 
well as the whole *.d dropin-directory thing, etc.

At the distro level, then, what we see is that if someone for instance 
has a touchpad, and the synaptics driver is installed (either by the user 
or in some automated fashion, say due to detection at installation 
pulling in the driver), that driver drops a config file in the 
appropriate xorg.conf.d dropin-dir, that has an inputclass section, that 
automatically switches any touchpad style devices, touch-screens, etc, to 
the synaptics driver, instead of the otherwise default evdev.

Tho of course that pre-supposes udev, etc, which the distros generally 
ship, tho of course particularly on a meta-distro like gentoo, users are 
free to uninstall and avoid if they like...

Similarly, video drivers dropin their configlet file, with an appropriate 
device section file, and any graphics chips now are automatically handled 
by that driver.

User/admin perspective now, they plugin a mouse and the evdev driver 
handles it, but the resolution is off and they need to either speed it up 
so it doesn't take 20 moves to get across the screen or they need to slow 
it down as it's far too jumpy.  Instead of having to look at the entire 
config file and potentially destroy an otherwise working config with a 
wrong edit, they add one little device-class section, and if they make a 
mistake, it's just one bit of the config that's bad and they can safely 
delete the entire file they just added to get back to where they were.

Similarly, I just added a logitech t650 touchpad, and after trying the 
synaptics driver I decided to go with the mtrack driver instead.  But now 
I have 20 different gestures, interpreted by the mtrack driver as 
"buttons", to configure.  Still, while that one deviceclass section to 
configure all that gets a bit complex, it's a file all its own, and I 
don't have to worry about the rest of the xorg config.

Similarly again, my graphics card has three outputs and I have them 
attached to three different monitors, but I have them stacked, while the 
default config has them side-by-side.  A single file with monitor 
sections configuring the position of each, and I'm good to go.

In each case, neither the distro's driver packages nor me as admin/user 
are editing a monolithic file with all sorts of unrelated X settings in 
it.  If the driver doesn't work or when the device is upgraded and that 
driver uninstalled and a different one installed, the dropin automagic 
config file gets uninstalled and a new one installed at the same time.  
If I screw up my config, I can delete the entire file I created, and be 
back to the otherwise generally working, just needing a few tweaks, 
configuration I had before.

That's the sense in which I meant "preferred".  Preferred by the distros 
as the various packages can ship their own dropin configs, without 
worrying about editing a monolithic file containing unrelated settings.  
Preferred by the distros AND the users because now the configuration 
exposed to user edits is more modularized and edits less likely to damage 
the config of unrelated modules.  Preferred by the users because now they 
don't have to worry about everything at once, and because most things 
"just work" without much more than minor tweaks.  Preferred by support, 
whether it be professional distro support, or peer user support via irc/
forums/lists/newsgroups, again because of the modularity, because now 
they can have the user they're supporting create a new file with a few 
lines, all directly related to what they're trying to configure, instead 
of dealing with a much larger file with unrelated settings, so, again, 
worst-case, simply delete the file and start over.

But that's *NOT* to say that individual users can't choose to do the 
monolithic xorg.conf file, or even scripted commandline config, if 
they're used to it and prefer all the settings in one place where they 
can see and edit them all at once.

That's an entirely /different/ level of "preferred"! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman