Honestly, it is pretty easy to configure the X Server these days; very little manual intervention has been required since the mid-2000s if you want to accept the defaults, which largely are correct and good. I am mindful about what families of hardware I buy, though, but that's not too restrictive. The only piece of hardware of mine that needs manual configuration is the Logitech TrackMan Marble, but that's only because I operate the mouse with a right-handed layout with my left hand. Interestingly the TrackMan Marble does not work with its full feature set in Wayland (core example: the buttons to enable horizontal/vertical panning of a wide or tall document), and this is not exotic hardware. How configuration is being handled in the X to Wayland conversion is a mystery to me. Some of it is happening in libinput (I think), but other parts aren't. This is one of the reasons I am deferring the Wayland migration for as long as I can.
Configuring software stack that runs (think: what the ~/.xsession file manages) is the place I've invested most of my effort, and that's purely about aesthetics and behavior: DPI, font rendering settings, window manager, etc. And this is pretty easy to do these days, because most of these things can prototyped and altered in an existing X session (keeping a tight edit-run loop).
And both of these situations can be alleviated by storing critical configuration files (e.g., ~/.xsession or the X Server configuration) under version control. There's no point in having to invest in reconfiguration of the same hardware these days when there's cheap version control and storage.
Oh, for sure. I've been using X in various capacities for ~3 decades.
I remember how it was. I'm impressed with how it is.
I recently switched back to X as a primary desktop after a rather long hiatus of doing [mostly!] other things. There was some initial driver discourse (standard nVidia vs. OSS necessary nonsense), but it wasn't really so bad once I sorted out what I needed and most "regular" Linux users can skip by a lot of this by default.
So far, I've done zero manual configuration of X itself outside of using XFCE4's GUI tools to arrange the three monitors in front of me in the right order -- and I don't presently see any reason to change anything else.
It's been very pleasant, all said, even though I got here on Medium-Hard Mode with an a rather barebones base install of Void on an existing ZFS pool for root.
X really was one of the easier parts of the whole operation.
(I have no interest in Wayland. It offers no clear advantage to me as a user that I can identify; even the games I like to play run splendidly in X. I've also always adored the concept of remotely displaying GUI applications. It's convenient -- I ran remote X apps for years immediately prior to this recent switch, and it worked well. Remote X apps have saved my bacon a few times by allowing me to quickly get a thing done in a familiar way instead of learning how to do it using something else entirely and maybe stuffing it up in some unforeseen fashion.)
Thanks. Now I'll have nightmares of the time I spent trying to help a friend get the 32" TV they won in a contest (back when an LCD of that size was still both unusual and expensive) to work at proper native resolution in Windows.
Windows really wanted it to be 1080p, and the TV supported this input, but it was a blurry mess.
It was advertised as 720p, and the TV supported this input as well, but that was also a blurry mess.
It actually had a physical vertical resolution of something like 760 lines, which was not one of the modes that it offered up over DDC as an option for whatever was driving it to use.
Fun times.
(I did eventually get 1:1 pixel mapping, but IIRC I had to give him a different video card for this to happen.)
What Linux solves through configuration, Windows solves by having everything you buy come with its own model-specific drivers that burn the needed configuration into the .INI + .DLL.
Windows "not liking your video card" is presumably because you either aren't using the right driver, or because Windows doesn't like your driver — i.e. the monitor is old enough that there's no version of that driver for current Windows.
PnP will always work for a simple+direct+modern (GPU → DisplayPort or HDMI → display) display path; but there are a lot of people who for whatever reason still need to use VGA.
Despite EDID being invented during the VGA era, it wasn't invented at the beginning of it — so older VGA displays don't support EDID, and therefore don't support reporting their valid modes. (And this is relevant not just for CRTs, but LCDs too — and especially projectors for some reason. Some projectors released as recently as 2010 were VGA-only + non-EDID-reporting!)
Remember Windows saying "you proposed a new monitor resolution; we're gonna try it; if you don't see anything, wait 15 seconds and we'll undo the change"? That's because of expensive mid-VGA-era EDID-less VGA monitors. These were advertised as supporting all sorts of non-base-VGA-spec modes that people wanted to use, but came with nary a driver to tell Windows what those modes were — so Windows was in that era just offering people essentially the same experience as editing xorg.conf to add ModeSet lines, just through a UI. And obviously, if even Windows had no proprietary back-channel to figure out what the valid modes were, then Linux didn't have a penguin's chance in hell of deducing them without your manual intervention.
---
But also, people are often trying to "upcycle" old computers into Linux systems (embedded systems like digital-signage appliances being especially popular for this) — and these systems often only come with VGA outputs, and video controllers that don't capture EDID info for the OS even when they do receive it.
Hook an early-2000s "little guy" (https://www.youtube.com/watch?v=AHukN0JsMpo) to any display you like over VGA, no matter how modern — and it still won't know what it's talking to, and will need those modeset lines to be able to send anything other than one of the baseline-VGA-spec modes (usually 800x600@60Hz.)
And this is, of course, still true if you try to use one of these devices with a modern HDMI display using an adapter.
(You might think to get away from this by using a "USB video adapter" and creating an entirely-new PnP-compatible video path through that... but these devices are usually old enough that they only support USB 1.1. But hey, maybe you'll luck out and they have a Firewire port, and you could in theory convince Linux to use a Firewire-to-DVI adapter as an output for a display rather than an input from a camcorder!)
---
Besides the persisting relevance of VGA, there's also:
• https://en.wikipedia.org/wiki/FPD-Link, which you might encounter if you're trying to get Linux running on a laptop from the 1990s, or maybe even a "palmtop" (i.e. the sort of thing that would originally have been running Windows CE);
• and the MIPI https://en.wikipedia.org/wiki/Display_Serial_Interface, which you might see if you're trying to do bring-up for a new Linux on a modern ARM SBC (or hacking on a system that embeds one — a certain popular portable game console, say.)
In both of these cases, no EDID-like info is sent over the wire, because these protocols are for devices where the system integrator ships the display as part of the system; and so said integrator is expected to know exactly what the specs of the display they're flex-cable-ing to the board is, and write that into a config file for the (proprietary firmware blob) driver themselves.
If you're rolling your own Linux for these systems, though,
then you don't get a proprietary-firmware-blob driver to play with; the driver is generic, and that info has to go somewhere else. xorg.conf to the rescue!
> on modern machines you almost never want to be editing the xorg.conf.
No one ever wanted to be editing xorg.conf! (xkcd 963 anyone?)
I did try the "modern" way when I hit this problem (which would have been in early 2022) - but even if it had worked (which it didn't) I don't think it would have persisted beyond a reboot?
I've never had this technique fail on me. I've done it a lot since I work with a variety of crappy KVMs and run into this problem often enough. You do need to make it a startup script, but that's pretty easy to do.
If it didn't work it's possible you have deeper problems, like X falling back to some crappy software only VESA VGA mode because the proper drivers for your card got corrupted. I've not seen this in many many years, but it's possible. The last time it happened it was really obvious because the whole thing was crazy slow, like the mouse cursor was laggy and typing text into the terminal had over a second of delay. It wasn't subtle at all.
I seem to remember at the time I had trouble finding "current" instructions - I think the syntax changed somewhere along the line? - so there may well have been some crucial step missing.
I'm sure it hadn't fallen back to a VESA mode because I was using compositor features like zooming in on particular windows while screencasting.
To fix the resolution on a modern distro the sequence is something like this (use your actual monitor dimensions and refresh rate of course):
Copy everything past "Modeline" into a cut buffer. 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:
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:
Finally, switch to the new mode: This is the modern way of doing it. Manually setting up modelines in the xorg config file is oldschool.