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