:: Re: [DNG] An alternative to renamin…
Page principale
Supprimer ce message
Répondre à ce message
Auteur: Adam Borowski
Date:  
À: dng
Sujet: Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]
On Mon, Aug 21, 2017 at 05:01:13PM -0700, Rick Moen wrote:
> 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.


There are cases when the old way had its merit -- but here, we have an
equivalent of a car that needs to be started with a hand-crank.

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


Then write just your desired resolution (or what else is wrong in your
EDID). Or, better, set it at runtime.

> 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


Now this is getting ridiculous. I borrow one of the monitors for a quick
task elsewhere quite often. Why would I need to shut down X, configure
things manually, then start it again, if it can -- and does -- handle
monitor hotplug correctly? Worst case, I'd need to use xrandr (or a
clicky-clicky equivalent) to turn off that blasted mirrored mode some smelly
laptop-lover invented (although this particular bug seems to be gone).

Same with input devices. If I change the keyboard or the mouse, why would I
need to drop all my state, rewrite the config, then restart X? Input
devices are handled by the kernel in an unified way for a decade.

(BTW, you'd want to purge gpm and replace it with consolation -- it's a
clean rewrite without the 90's baggage, with less than 10% code size.)

> 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 prefer 0 seconds to 60 seconds. And it's never 60 seconds in practice --
in the bad old days it was a matter of hours digging through the
documentation. Assuming the user knew where to find the documentation in
the first place.

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


It's neither simple nor necessary. If mdev fails to provide X with required
information, that's a defect of mdev. But really, it's not the duty of
userland to do such things these days -- unless you happen to have a decade
old graphics card no one bothered to write a KMS and DRM driver for, there's
no configuration to be done.

Per the other thread, the only thing you need udev/mdev for anymore is
setting permissions and calling hooks. Don't tell me that udev is a "big
price" on any machine bigger than a microcontroller these days.

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


But why? mdev is not meant to be used beyond an initramfs, it can't do
hotplug, and on modern Linux coldplug is almost entirely done via hotplug --
with shit happening if your software can't take a device which took a while
to start.

Could you please tell me what's your use case for micromanaging a machine
that has an X-capable display attached?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀                                        -- Genghis Ht'rok'din
⠈⠳⣄⠀⠀⠀⠀