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