Ubuntu X.org maintainer Bryce Harrington writes in a response to Brainstorm idea 322:

Configuring X has been a long standing issue in Linux, and there's still room to improve.

Brainstorm 322 and its comments touch on a bunch of (partly unrelated) problems:

a) mis-detecting monitor resolution/refresh rates
b) supporting new hardware (and upcoming USB monitors)
c) binary driver issues
d) Importing Windows .inf/.icc files
e) multi-monitor configuration / detection; multi-card support

To cover this range of issues, I need to give some background on where things are at, so please pardon the length of this reply:

Xorg upstream's vision is that no configuration should be needed. In the vast bulk of cases, the hardware reports its capabilities and xserver can set things up properly. Besides, few users wish to deal with hacking on config files, and some are even put off by gui config tools.

This is a very good vision, and in fact something like 90-95% of the time it holds true. I remember in Feisty the most common complaint by Ubuntu reviewers was "it didn't get my resolution right"; thankfully that is a thing of the past - reviewers hardly ever mention resolution problems these days. This was largely due to installation scripting bugs, that were relatively straightforward to sort out.

Yet, there is still that last 5-10% or so that causes our problem (a) in the list above, which aren't due to install scripts (we've essentially eliminated install scripts these days). This 5-10% can be broken into three classes:

A. Defective hardware, requiring quirks to work around issues
B. Legitimate Xserver or misc driver bugs
C. New hardware, not yet supported

Class A is the easiest to deal with, since the symptoms are quite common, relatively easy to detect, and with patches that can be safely backported. It use to be that we would work around these issues in our installation scripts, but over time the pile of workarounds got to be complicated and hard to maintain. These days we work with upstream and pass bugs and patches to them and include them in the new development version of Ubuntu (and sometimes where feasible we backport/SRU them to the stable version too). This is beneficial because it helps all distros not just Debian/Ubuntu, and it gains upstream's help in maintaining the workarounds down the road.

Class B is harder to deal with, but also a priority that we hope continues to reduce in magnitude. Often these issues are exposed by new technologies coming on line (RandR, compiz, etc.) which is normal for actively developing software. Other times they're due to the evolving needs of users or the evolving capabilities of newly released hardware.

It would be nice if we had better testing tools. Indeed, this was a hot topic at XDC2008 last month, and it's been an item on my own todo list lately (see the 'x-testing-infrastructure' blueprint). But honestly, due to Xorg's nature even the best testing tools would be only able to catch a fraction of the possible bugs. So this makes human testers (i.e. YOU) very, very important. Thus, the approach I've focused on for Class B bugs is to help strengthen the human testing side of things through improving documentation for bug reporting, troubleshooting, and so on - see http://wiki.ubuntu.com/X/ - and through creating tools and resources that help users and testers more easily help us (pre-built driver binaries, etc.) Also see this Ubuntu Open Week for discussion:
https://wiki.ubuntu.com/MeetingLogs/openweekhardy/ImproveX

Class C is a different situation, because there is continually new hardware coming out, as problem (b) in our list above indicates. Fortunately, we are seeing upstream vendors (Dell, Intel, AMD, VIA, others) putting a priority on Linux support for their newest hardware. Indeed, these companies have begun collaborating with us at Canonical to test and ensure that support for their hardware is in place well before the general public sees it. I'm very optimistic about this and think it will make a huge difference moving forward in eliminating this whole topic as an issue, especially if the other graphics card vendors come on board.

Proprietary binary drivers (problem (c) above) are in a special category, since we don't have a way to patch them ourselves and since we can't troubleshoot them as easily (no debug symbols for backtraces, etc.) However, these days both AMD and nVidia are releasing their drivers on a quite regular schedule, and have made steady progress towards solving the bugs people see. (I suspect the bugs people do encounter are quite memorable, so the drivers may have a reputation for being buggier than they actually are when you look at the actual bug counts in Launchpad.) In any case, AMD/ATI has recently established a relationship with us for forwarding triaged -fglrx bugs their way.

Due to all the work going on in all the above areas, I think we can safely expect to see the number of problems in classes A, B, and C decrease from the 5-10% or whatever, to something quite vanishingly small. Given how far we got since Feisty, I have high hopes for Intrepid and Intrepid+1.

So, all of this is building the background for the following point I want to make regarding X configuration tools: Tools to work around X config issues may not be worth the time to craft them. The issues they address may go away completely by the time we're done, or X may change in such a way that keeping the config tool bug-free becomes hard.

Hopefully all the foregoing answers half the issues raised in Idea 322. The other half of 322 focuses on multi-head configuration problems.

A large part of the problem with multi-head is that we're in the midst of a lengthy transition from Xinerama to Xrandr for managing multiple displays. This transition is not fully complete yet, and while it has brought advances in some areas, it's resulted in feature regressions in others.

For example, monitor hotplugging - such as plugging a projector into a running laptop - now works quite well (esp. for Intel graphics). However, the new Xrandr is designed in such a way that it can only establish one combined screen for one video card. This means that dual-head layouts are possible with a 2-output video card, but four-head layouts using two video cards won't work (or at least will be very hard to get set up).

In Gutsy, we supplied a tool called displayconfig-gtk which provided for doing multi-head layouts via Xinerama, and had some other nifty features such as monitor .inf import (problem (d)). For Hardy since so many
drivers use Xrandr rather than Xinerama, we've deprecated that tool in favor of a new Screen Resolution tool. For more information on this transition, please see: https://wiki.ubuntu.com/X/DisplayConfigGtk

For .inf import, rather than doing this in a local config tool, a thought we've had is to replace that functionality with an online monitors database - see https://wiki.ubuntu.com/X/MonitorsDatabaseOnline - however the quirking approach has been so effective in solving monitor resolution detection issues, I wonder if time is better spent there...? In any case this is something I hope to see discussed at UDS. Screen Resolution uses Xrandr to do dual-head layouts on the fly. We have some tips for getting the most use out of it (and working around a couple issues) at https://wiki.ubuntu.com/X/Config

Screen Resolution does not touch xorg.conf at all. This is a good thing, in that it avoids a lot of problem scenarios that displayconfig-gtk would run into. It also means screen config can be done without a root password! However, video drivers have some Options that can be set in xorg.conf but not on the fly (the Virtual option is a particularly needed case in point), and it would be nice to have a way to set them. It may be nice to have a tool that can be run from an Advanced button in Screen Resolution or something, that allows "editing" the xorg.conf file in a more GUI-oriented fashion.

Going forward, one of the next big, high-priority changes in the Xinerama->Xrandr transition involves abstracting the way video card memory is handled. This will permit the memory in several cards to be pooled and thus allow mapping a screen over multiple cards (which will finally solve problem (e)). When that happens, Xrandr will finally have the framework for supporting >2 heads. I hope to see an initial version of this in Intrepid for experimentation purposes, with a stabilized version available by Intrepid+1. A lot of this depends on the quality of testing efforts by community members, so if this is something you're passionate about and want to put some effort in, you can get involved in Ubuntu X to help push it forward.

Finally is the topic of binary drivers and multi-head layouts. In some cases the binary drivers have much different support for this than the open drivers; sometimes this is because those drivers still use Xinerama, in other cases it's because they have their own solutions to the problem. I would expect as these drivers switch over to using Xrandr, you may also see some regressions in >2 monitor support here. Hopefully the above covers the 5 problems stated in brainstorm 322, illustrates where we are now and gives you an idea on a timeframe for the remaining improvements.