[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@×××.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