Jan 21, 2015, 10:42 PM
Post #6 of 6
(4196 views)
Permalink
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