7 ms·

> For a long time the X Window System had a reputation for being difficult to configure. In retrospect, I’m not 100% sure why it earned this reputation, because

by derefr 2y ago

> For a long time the X Window System had a reputation for being difficult to configure. In retrospect, I’m not 100% sure why it earned this reputation, because the configuration file format, which is plain text, has remained essentially the same since I started using Linux in the mid-1990s. 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. (After all, if there was some OS API already available at the time to fetch an objectively-correct answer, the X server would just use that API, and not ask you the question!) An example of what I personally remember: I had a PS2 mouse with three mouse-buttons and a two-axis scroll wheel ("scroll nub.") How do I make this mouse work under X? Well, X has to be told what each signal the mouse can send corresponds to. And there's no way to "just check what happens", because any mouse calibration program is relying on the X server to talk directly to the mouse driver — there wasn't yet any raw input-events API separate from X — so in the default X configuration that assumes a two-button mouse, none of the other buttons on the mouse get mapped to an X input event, so the mouse calibration program won't report anything when you try the other parts of the mose. So instead, you have to make a random guess; start X; see if the mouse works; figure out by the particular way it's wrong what you should be telling X instead; quit X; edit the config file; restart X; ...etc. (And now imagine this same workflow, but instead of something "forgiving" like your mouse not working, it's your display; and if you set a resolution + bit-depth + refresh rate that add up to more VRAM than you have, X just locks up the computer so hard that you can't switch back to a text console and have to reboot the whole machine.)

throwaway_2494 2y ago
>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.
- deleted 2y ago
  [deleted]
- xenophonf 2y ago
  Those specs weren't readily available to non-experts, never mind what to do with them. For a trip down memory lane, read through the XFree86 Video Timings HOWTO (https://tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.html https://tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.htm...). Getting stuff to work in the Good Old Days was _not_ easy.
  - anthk 2y ago
    30-70h, 50-160v =) I still remember that. And xf86cfg, and how much Debian was improved when Sarge arrived.
- robinsonb5 2y ago
  The manual that came with your laptop of 25 years ago isn't going to tell you whether your touchpad is Alps or Synaptic, or which PS/2 protocol it imitates.
  - neilv 2y ago
    True. Though laptops were in some ways easier than desktops, since laptops tended to have the same set of hardware in each unit, so hopefully you only had to find an `XF86Config` or `xorg.conf` that someone had shared for that model. Examples: http://www.neilvandyke.org/linux-thinkpad-560e/XF86Config-tp560e http://www.neilvandyke.org/linux-thinkpad-560e/XF86Config-tp... https://www.neilvandyke.org/linux-thinkpad-x20/xorg.conf https://www.neilvandyke.org/linux-thinkpad-x20/xorg.conf
- giantrobot 2y ago
  > You didn't have to guess, you just had to read the specs in the manual that didn't come with your equipment. 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.
  - tedunangst 2y ago
    Sure it did. There was a page in the pamphlet that came with my viewsonic 15" that listed the supported timings. You just threw it away, but that's not X's fault.
    - happymellon 2y ago
      No, I had plenty of equipment that came with a little piece of printed paper that came with not quite enough information to be useful.
- jagger27 2y ago
  > Just RTFM Ahh Linux people. Some things will never change.
- blueflow 2y ago
  To the people down-voting you: X is from a time when devices actually came with manuals. When the people using it were engineers and scientists and reading a datasheet or a manual was a normal thing to them. 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.
  - II2II 2y ago
    > To the people down-voting you: X is from a time when devices actually came with manuals. 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.
  - derefr 2y ago
    > 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. 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?)
- kevin_thibedeau 2y ago
  Modelines required timing information that was rarely available. You made a best guess and tweaked the numbers until it worked.
  - yencabulator 2y ago
    Or you hunted around in the pre-WWW world for a modeline database, and hoped your monitor was included. Here's a more modern incarnation and more background (the non-stippled kind): https://www.mythtv.org/wiki/Modeline_Database https://www.mythtv.org/wiki/Modeline_Database https://tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/ https://tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/ https://nyanpasu64.gitlab.io/blog/crt-modeline-cvt-interlacing/ https://nyanpasu64.gitlab.io/blog/crt-modeline-cvt-interlaci... https://xtiming.sourceforge.net/cgi-bin/xtiming.pl https://xtiming.sourceforge.net/cgi-bin/xtiming.pl
- babypuncher 2y ago
  That's already more work than other operating systems of the late '90s made you do to get a functioning mouse, keyboard, and display.
  - josefx 2y ago
    Given that the example mentioned above was about making the scroll wheel work? When Microsoft released the IntelliMouse it came with a driver disk, just plugging in the mouse without reading the manual left you with a non functional scroll wheel. Support for Microsoft style mice by later versions of Windows also did not stop companies from requiring their own drivers to enable non standard functionality.
- Asooka 2y ago
  lol () / 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 LMFAO
- derefr 2y ago
  Lucky you, buying computer hardware new-in-box :) 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.)
robinsonb5 2y ago
Yup, things are so much better now that they just work. Except when they don't, because now it's harder to do anything about it. I've lost count of the number of Linux machines I've seen that won't offer the correct resolution for a particular monitor (typically locked to 1024x768 on a widescreen monitor). I don't know whether the problem's with Linux, Xorg, crappy BIOSes or crappy monitors - but even now I occasionally resort to an xorg.conf file to solve such issues.
- jandrese 2y ago
  Do you work with a lot of KVMs? Directly plugged monitors usually just work thanks to EDID info, but cheap KVMs frequently block that signal and cause problems. It's rare for a monitor plugged directly into the computer to have problems these days, even on Linux.
  - robinsonb5 2y ago
    No KVMs involved - but three of the machines I have in mind (not identical, but all running the same version of Linux Mint) have two monitors attached, one of which is OK and the other isn't. (Not mine - so I haven't put any time into trying to solve it yet.) Another machine - which is mine - used to have a 19" VGA monitor attached which worked happily at 1280x1024 for months, then one day something got updated and it wouldn't do anything beyond 1024x768 after that until I resorted to an xorg.conf file.
    - jandrese 2y ago
      Also, on modern machines you almost never want to be editing the xorg.conf. xrandr took over the responsibility of doing resolution stuff. To fix the resolution on a modern distro the sequence is something like this (use your actual monitor dimensions and refresh rate of course): % cvt 1920 1080 60 Copy everything past "Modeline" into a cut buffer. % xrandr --newmode <paste the line from above> Keep a note of the first line in the field, it will look something like "1920x1080_60", this is the "mode name" Next, find out what your monitor is named: % xrandr | grep ' connected ' It will be HDMI-1 or VGA-1 or something like that, this is your "interface name". Now add the mode to your monitor specification: % sudo xrandr --addmode <interface name> <mode name> Finally, switch to the new mode: % xrandr --output <interface name> --mode <mode name> This is the modern way of doing it. Manually setting up modelines in the xorg config file is oldschool.
maximilianburke 2y ago
It was always fun to have the threat of overdriving and frying your CRT monitor hanging over your head when trying to get X going.
halyconWays 2y ago
You surfaced memories of childhood me installing RedHat 5.2, carefully selecting packages and X config options, getting it wrong, not knowing how to get back to that magical installation UI, and reinstalling the OS just to have another crack at it. Eventually I figured out how to launch that xconfig utility and found some sane defaults, and was thrilled when I finally saw the stippling pattern or even a window manager.
doctor_eval 2y ago
> For a long time the X Window System had a reputation for being difficult to configure. Honestly I thought it was hard to configure because until I used Linux, my X terminals didn’t need to be configured at all! I may be misremembering but I think my NCD terminal used bootp and probably a little tftp, then off it went. The hardest part was probably finding an Ethernet drop to plug it into. Now - get off my lawn!

by derefr 2y ago

throwaway_2494 2y ago

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

deleted 2y ago
[deleted]
xenophonf 2y ago
Those specs weren't readily available to non-experts, never mind what to do with them. For a trip down memory lane, read through the XFree86 Video Timings HOWTO (https://tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.html https://tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.htm...). Getting stuff to work in the Good Old Days was _not_ easy.
- anthk 2y ago
  30-70h, 50-160v =) I still remember that. And xf86cfg, and how much Debian was improved when Sarge arrived.
robinsonb5 2y ago
The manual that came with your laptop of 25 years ago isn't going to tell you whether your touchpad is Alps or Synaptic, or which PS/2 protocol it imitates.
- neilv 2y ago
  True. Though laptops were in some ways easier than desktops, since laptops tended to have the same set of hardware in each unit, so hopefully you only had to find an `XF86Config` or `xorg.conf` that someone had shared for that model. Examples: http://www.neilvandyke.org/linux-thinkpad-560e/XF86Config-tp560e http://www.neilvandyke.org/linux-thinkpad-560e/XF86Config-tp... https://www.neilvandyke.org/linux-thinkpad-x20/xorg.conf https://www.neilvandyke.org/linux-thinkpad-x20/xorg.conf
giantrobot 2y ago
> You didn't have to guess, you just had to read the specs in the manual that didn't come with your equipment. 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.
- tedunangst 2y ago
  Sure it did. There was a page in the pamphlet that came with my viewsonic 15" that listed the supported timings. You just threw it away, but that's not X's fault.
  - happymellon 2y ago
    No, I had plenty of equipment that came with a little piece of printed paper that came with not quite enough information to be useful.
jagger27 2y ago
> Just RTFM Ahh Linux people. Some things will never change.
blueflow 2y ago
To the people down-voting you: X is from a time when devices actually came with manuals. When the people using it were engineers and scientists and reading a datasheet or a manual was a normal thing to them. 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.
- II2II 2y ago
  > To the people down-voting you: X is from a time when devices actually came with manuals. 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.
- derefr 2y ago
  > 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. 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?)
kevin_thibedeau 2y ago
Modelines required timing information that was rarely available. You made a best guess and tweaked the numbers until it worked.
- yencabulator 2y ago
  Or you hunted around in the pre-WWW world for a modeline database, and hoped your monitor was included. Here's a more modern incarnation and more background (the non-stippled kind): https://www.mythtv.org/wiki/Modeline_Database https://www.mythtv.org/wiki/Modeline_Database https://tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/ https://tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/ https://nyanpasu64.gitlab.io/blog/crt-modeline-cvt-interlacing/ https://nyanpasu64.gitlab.io/blog/crt-modeline-cvt-interlaci... https://xtiming.sourceforge.net/cgi-bin/xtiming.pl https://xtiming.sourceforge.net/cgi-bin/xtiming.pl
babypuncher 2y ago
That's already more work than other operating systems of the late '90s made you do to get a functioning mouse, keyboard, and display.
- josefx 2y ago
  Given that the example mentioned above was about making the scroll wheel work? When Microsoft released the IntelliMouse it came with a driver disk, just plugging in the mouse without reading the manual left you with a non functional scroll wheel. Support for Microsoft style mice by later versions of Windows also did not stop companies from requiring their own drivers to enable non standard functionality.
Asooka 2y ago
lol () / 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 LMFAO
derefr 2y ago
Lucky you, buying computer hardware new-in-box :) 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.)

robinsonb5 2y ago

Yup, things are so much better now that they just work. Except when they don't, because now it's harder to do anything about it. I've lost count of the number of Linux machines I've seen that won't offer the correct resolution for a particular monitor (typically locked to 1024x768 on a widescreen monitor). I don't know whether the problem's with Linux, Xorg, crappy BIOSes or crappy monitors - but even now I occasionally resort to an xorg.conf file to solve such issues.

jandrese 2y ago
Do you work with a lot of KVMs? Directly plugged monitors usually just work thanks to EDID info, but cheap KVMs frequently block that signal and cause problems. It's rare for a monitor plugged directly into the computer to have problems these days, even on Linux.
- robinsonb5 2y ago
  No KVMs involved - but three of the machines I have in mind (not identical, but all running the same version of Linux Mint) have two monitors attached, one of which is OK and the other isn't. (Not mine - so I haven't put any time into trying to solve it yet.) Another machine - which is mine - used to have a 19" VGA monitor attached which worked happily at 1280x1024 for months, then one day something got updated and it wouldn't do anything beyond 1024x768 after that until I resorted to an xorg.conf file.
  - jandrese 2y ago
    Also, on modern machines you almost never want to be editing the xorg.conf. xrandr took over the responsibility of doing resolution stuff. To fix the resolution on a modern distro the sequence is something like this (use your actual monitor dimensions and refresh rate of course): % cvt 1920 1080 60 Copy everything past "Modeline" into a cut buffer. % xrandr --newmode <paste the line from above> Keep a note of the first line in the field, it will look something like "1920x1080_60", this is the "mode name" Next, find out what your monitor is named: % xrandr | grep ' connected ' It will be HDMI-1 or VGA-1 or something like that, this is your "interface name". Now add the mode to your monitor specification: % sudo xrandr --addmode <interface name> <mode name> Finally, switch to the new mode: % xrandr --output <interface name> --mode <mode name> This is the modern way of doing it. Manually setting up modelines in the xorg config file is oldschool.

maximilianburke 2y ago

It was always fun to have the threat of overdriving and frying your CRT monitor hanging over your head when trying to get X going.

halyconWays 2y ago

You surfaced memories of childhood me installing RedHat 5.2, carefully selecting packages and X config options, getting it wrong, not knowing how to get back to that magical installation UI, and reinstalling the OS just to have another crack at it. Eventually I figured out how to launch that xconfig utility and found some sane defaults, and was thrilled when I finally saw the stippling pattern or even a window manager.

doctor_eval 2y ago

> For a long time the X Window System had a reputation for being difficult to configure. Honestly I thought it was hard to configure because until I used Linux, my X terminals didn’t need to be configured at all! I may be misremembering but I think my NCD terminal used bootp and probably a little tftp, then off it went. The hardest part was probably finding an Ethernet drop to plug it into. Now - get off my lawn!