| 1 |
Frank Peters posted on Tue, 20 Jan 2015 18:17:26 -0500 as excerpted: |
| 2 |
|
| 3 |
> On Tue, 20 Jan 2015 12:47:36 -0500 Drake Donahue <donahue95@×××××××.net> |
| 4 |
> wrote: |
| 5 |
> |
| 6 |
> |
| 7 |
>> IMHO, whoever is assigned to maintain the eselect-opengl ebuild has |
| 8 |
>> been having trouble for about 3 months now. Your solution to your |
| 9 |
>> problem is lovely. |
| 10 |
>> |
| 11 |
>> |
| 12 |
> I really don't know why it works. I just tried it on a lark and it |
| 13 |
> succeeded. |
| 14 |
> |
| 15 |
> I'm also not sure that it even _should_ work. The module path order |
| 16 |
> should not make a difference as long as all the appropriate paths are |
| 17 |
> specified. |
| 18 |
> |
| 19 |
> There seems to have been changes made somewhere to either xorg-server or |
| 20 |
> nvidia-drivers but as long as things work for me I'll just move on and |
| 21 |
> not investigate further. |
| 22 |
|
| 23 |
The changes were to eselect-opengl and how it deals with multiple library |
| 24 |
providers of the same general functionality. |
| 25 |
|
| 26 |
Previously, eselect-opengl handled it with symlinks, eselecting one or |
| 27 |
the other opengl provider would adjust the symlinks appropriately, and |
| 28 |
the xorg configuration remained fixed. |
| 29 |
|
| 30 |
With xorg.conf.d directories now being the preferred configuration |
| 31 |
method, eselect-opengl now uses that, changing the 20-opengl.conf or |
| 32 |
whatever file it drops into the xorg.conf.d dir, instead of changing |
| 33 |
symlinks. |
| 34 |
|
| 35 |
Which in general works, for people with either relatively new |
| 36 |
installations without the old cruft, and for people with older |
| 37 |
installations who have kept their configuration updated and weeded out |
| 38 |
the old cruft as they went. |
| 39 |
|
| 40 |
But some people, generally with older configurations that haven't been |
| 41 |
kept updated in accordance with the latest xorg configuration state-of- |
| 42 |
the-art, are finding the new eselect-opengl "configlet file" method isn't |
| 43 |
quite compatible with their old configuration. |
| 44 |
|
| 45 |
On top of the usual configuration changes that would come with the |
| 46 |
update, there appears to be a bug, something to do with multiple files |
| 47 |
section entries but with certain other conditions that aren't yet fully |
| 48 |
sorted, that's keeping xorg from properly parsing these multiple file |
| 49 |
section entries. Which of course adds to the confusion. |
| 50 |
|
| 51 |
But the bottom line remains pretty basic, ensure that your desired |
| 52 |
functionality providers (in this case the servantware nvidia providers) |
| 53 |
are loaded first, either by screwing with the modules path order, or by |
| 54 |
deleting no longer needed bits of the config, until it works. |
| 55 |
|
| 56 |
And thru all the confusion you've obviously found something that's |
| 57 |
working for you ATM, so consider yourself lucky and go with it... until |
| 58 |
the next time the configuration format changes up and you find something |
| 59 |
broken, at least. =:^) |
| 60 |
|
| 61 |
-- |
| 62 |
Duncan - List replies preferred. No HTML msgs. |
| 63 |
"Every nonfree program has a lord, a master -- |
| 64 |
and if you use the program, he is your master." Richard Stallman |
Archives