Resorted to editing xorg.conf? Heck, I prefer doing it that way
Like I said before, I don't do ANYTHING to configure X. It works out of the box with free drivers, at native resolution, without needing anything.
I don't have an xorg.conf and I don't use anything else.
Well, I would only *need* it for setting my keyboard and some driver options, but I prefer to have it because explicit settings are always faster than any kind of autoscanning.
I really only use xorg.conf nowadays for enabling color tiling in radeon.
You didn't think thoroughly about resolution choices. Come on, today's laptops are often equipped with a 1440 x 900 screen - to which category would You qualify it, less than 1280 x 1024 or less than 1600 x 1200?
Because of the infinite variation of packages, versions, and patchsets, something dynamic, like open source drivers, which can be adjusted to match the particular conditions, will naturally be more stable than a static blob that is designed for a much more rigid set of conditions.
Complexity of code isn't necessarily a reason for something to be unstable. More like the fact that all the blobs are just windoze drivers shoehorned into a totally incompatible system... and the dynamic nature of the operating system obviously, as mentioned above, needs a more dynamic driver.It's just somewhat easier to achieve in the OSS gfx drivers due to reduced features, thus reduced code complexity.
Note: It is NOT the job of the driver to override defective input data, it is the job of the monitor to provide good information about its characteristics. If this weren't the case, then there would be no need to supply an EDID -- just manufacturer and model ID numbers.
Here's how you can force a mode without having to hack the driver: http://nouveau.freedesktop.org/wiki/KernelModeSetting