:: Re: [DNG] An alternative to renamin…
Página Inicial
Delete this message
Reply to this message
Autor: Rick Moen
Data:  
Para: dng
Assunto: Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]
Quoting Adam Borowski (kilobyte@???):

> Manually creating the configuration -- or even manually triggering its
> creation -- is a pretty bad idea. It just guarantees you won't have
> working X when you make any change to your hardware -- and sometimes
> software as well.


Gosh, what you call a bad idea was utterly routine and what everyone was
used to for decades. You simply knew that, if you changed your video chipset
or changed to a radically different pointing device, or if you wanted to
do something very different like Xinerama, you'd need to generate a new
one.

Also, having an /etc/X11/Xorg.conf file means _you_, rather than Xorg
autoprobing, were in charge of what X would do and what it would be
willing to try. Like, maybe you have a monitor for which the built-in
EDID information is slightly wrong and you know what it should be, so
you tweak Xorg.conf to use the correct information.

Moreover, 'won't have working X' is a melodramatic exaggeration of the
situation where, if you changed to a new video chipset, or a new
monitor, or a very different mouse, you could always re-run 'Xorg
-configure', test the output, put it in place, and have a tested new
configuration in about 60 seconds. Or, if you no longer wanted that,
just mv /etc/X11/Xorg.conf /etc/X11/Xorg.conf.save , and you're right
back to the automagical thing.

I personally think a udev dependency is far too big a price to pay for
Xorg autoconfiguration when generating what you want is so simple.
However, as usual, I'm deciding that only for myself.

> Save for good-for-nothing Nvidia proprietary drivers, I haven't seen a case
> where mucking with this file was needed to get working X for over a decade.


You might have missed the context. We were talking about how to ensure
that Xorg works with mdev, rather than udev.