>It's because X's config files were asking you questions that there was no good way of knowing the answers to other than trial-and-error.
You didn't have to guess, you just had to read the specs in the manual that came with your equipment.
You didn't have to guess, you just had to read the specs in the manual that came with your equipment.
Examples:
http://www.neilvandyke.org/linux-thinkpad-560e/XF86Config-tp...
For a trip down memory lane, read through the XFree86 Video Timings HOWTO (https://tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.htm...). Getting stuff to work in the Good Old Days was _not_ easy.
I still remember that.
And xf86cfg, and how much Debian was improved when Sarge arrived.
I think this started around the 90ies that devices turned into magic black box consumables that are expected to "just work" while being undiagnosable when they don't.
To a degree. At least from my experience, something like a monitor and video card manual would provide you with enough information to filter through a list of example modelines to figure out which ones may work. Yet they did not provide enough information to create your own modelines.
> devices turned into magic black box consumables that are expected to "just work" while being undiagnosable when they don't.
"Just work" and being diagnosable are not mutually exclusive concepts. For the most part, the Linux ecosystem reflected that and still reflects that. I suspect the shift in behavior actually came from end users. They were less willing to look through the diagnostic messages and far less willing to jump through hurdles for things that they thought should just work.
I would say that it's more that the architectures where a manual created by the integrator could tell you anything useful, became irrelevant/obviated by architectures where it wouldn't.
Including a manual with a printed wiring block diagram of the hardware, made sense in the 1970s, when you (or the repair guy you called) needed something to guide your multimeter-probe-points for repair of a board consisting of a bunch of analogue parts.
And such a manual still made sense in the 1980s, now for guiding your oscilloscope signal-probing of jellybean digital-logic parts ("three NOT gates in a DIP package" kind of things) to figure out which ones have blown their magic smoke.
But once you get to the 90s, you get complex ICs that merge (integrate!) 90% of the stuff that was previously sitting out as separate components on the board; and what's remaining on the board at that point, besides those few ICs, just becomes about supporting those complex ICs.
At that point, all of the breakage modes that matter, start to happen inside the ICs. And if it's the ICs that are broken, then you none of the information from a wiring block diagram is going to be helpful; no problem you encounter is likely to be solved by probing across the board. Rather, you'll only ever be probing the pins of an individual IC.
Which means that what really helps, in the 90s and still today, are pin-out diagrams for each individual IC.
Providing that information isn't really the responsibility of the board manufacturer, though; they didn't make the ICs they're using. Rather, it's the responsibility of the IC company — who you don't have any direct relationship with, and therefore who don't have cause to be sending you you data-sheets.
Thankfully, these IC companies do sell these parts; and so they mostly have their IC data-sheets online. (No idea how you would have figured any of this out in the 90s, though. Maybe the 90s equivalent of Digikey kept phonebook-thick binders containing all the datasheets they receive along with the parts they order, and maybe repair people could order [photo]copies of that binder from them?)
In the 2000s you had to email the manufacturer to get that on a pdf.
Here's a more modern incarnation and more background (the non-stippled kind):
https://www.mythtv.org/wiki/Modeline_Database
https://tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/
https://nyanpasu64.gitlab.io/blog/crt-modeline-cvt-interlaci...
I think, for at least the first 30 years of my life, every Linux system I've ever built was with "hand-me-down" hardware. First hardware from my parents, then from various friends, then finally from my own expired projects.
When I was young (eleven!), this meant that we'd get a new computer, and now the very old computer it replaced could be repurposed as a "playground" for me to try various things — like installing Linux on — rather than throwing it out. (My first Linux install was Slackware 3.4 on a Pentium 166 machine. Not the best hardware for 1998!) Nary a manual in sight; of course my parents didn't keep those, especially for something like a monitor.
When I was a teenager, this meant getting hand-me-down hardware from friends who had taken the parts out of their own machines as they upgraded them. Never thought to ask for manuals, of course. (Also, sometimes I just found things like monitors laying on the side of the road — and my existing stuff was so old that this "junk" was an upgrade!)
And during my early adulthood, my "main rig" was almost always a Windows or (Hackintoshed) macOS machine. So it was still the "residue" of parts that left that rig as it got upgraded, that came together to form a weird little secondary Linux system. (So I could have kept the manuals at this point; but by then, the manuals weren't needed any more, as everything did become more PnP.)
It's only very recently that I bought a machine just to throw Linux on it. (Mostly because I wanted to replace my loud, power-sucking Frankenstein box, with one of those silent little NUC-like boxes you can find on Amazon that have an AMD APU in them, so I could just throw it into my entertainment center.) And funny enough... this thing didn't come with a manual, or even a (good) data-sheet! (Which is okay for HDMI these days, but meant that it was pretty hard to determine e.g. how many PCIe lanes the two M.2 slots on the board are collectively allocated.)
Hey you missed a word so I added it in for you. Most consumer PC equipment definitely did not come with any documentation covering the sort of stuff X's config file was asking about.
When that documentation was available it was something you could only get by contacting the manufacturer about. But you couldn't mention the word "Linux" because the CS rep would give a blanket "we don't support Linux" and you'd get nothing.
Ahh Linux people. Some things will never change.
()
/ Oh wait you're \ JL
| serious. Let me | ||
\laugh even harder./ LJ
. _,--"""""""---.
. ,' `.
. / \
. J L
. F L
J J
| J
___L______________ J
/,---------------. "". J
JJ / \/ | J J
LL J J | L J
JJ J # J # | L |
\\__`.___,_`.____,' F |
""-.---------....___/ |
|_T--+---+--.,._ |
|--|----\---\-`. |
|__|____J___J_ F F
_|__|____|___|_/ L
| L
|____________________M-K