Comment 47 for bug 147721

displayconfig-gtk has grown obsolete since Gutsy. We knew this would happen due to information about the direction that upstream was going by making more and more of xorg.conf's contents optional, and shift to more use of Xrandr for configuration. In recent months, we've been working on migrating to a new Xrandr-based replacement, which is now available in Hardy Beta.

The move to Xrandr and trimming down of xorg.conf has been planned since before Gutsy, and we knew it was under way when Gutsy started. As a general rule, these are GOOD changes for the end user, as it means the end of days of having to manually edit your xorg.conf. Today, Xorg has the abilities to auto-detect nearly everything with your video setup (and even can guess at your input devices too, although that's newish). Following Debian, we've been gradually dropping techie bits and pieces from xorg.conf, like sync rates, resolutions, modules, fonts, monitor layouts. We even experimented briefly during Hardy with not even listing the driver (it worked, but caused some unexpected side effects so we pulled back from that). In general we have found that for the vast majority of people, these changes are beneficial - their hardware is all automatically detected and set up correctly, and if they wish to make tweaks to resolution or whatever, they can do it at run time using tools like 'xrandr'.

Now, there are still some corner cases where things don't "just work". For instance, some monitors fail to provide valid EDID data about what resolutions they support, or mistakenly use 'cm' rather than 'mm' when reporting physical size. Or, some video cards come up with their tv-out turned on, which confuses X when it tries picking resolutions. Or the resolution is right, but the modeline is wrong, resulting in swishing or sync issues or so on. In these cases, rather than expecting the user to configure their way around the problem, what we've been doing is fixing up the xserver with "quirks" - hardware-specific fixups that lets X take special cases when dealing with that hardware, so everything "just works" and you don't have to think about it.

A particularly exciting consequence of this video hotplugging capability is that today with some video drivers like -intel, you can plug in your laptop to a projector, and it gets detected and set up and "just works", although there are still a variety of problems and sometimes you have to poke it a bit with xrandr to get matching resolutions and so on. But it's come a long way and bodes well for the future.

Anyway, there is an unfortunate downside to all of this, and that is that it breaks displayconfig-gtk. displayconfig-gtk was designed in the days before all this hotplugging, back when you could make the assumption that the entire configuration of the system was captured 100% completely and accurately in xorg.conf. Thus, this tool is designed to read in the xorg.conf, present a GUI representation of its contents, allow you to fiddle and tweak, and then write back out a static xorg.conf, specifying every detail including down to sync rates and mode lines.

Perhaps even more troublesome for many is the fact that the way multi-head configuration was done also changed as part of this. The old static way, Xinerama, was replaced with the new run-time Xrandr 1.2 approach. Unfortunately, it was implemented in such a way that drivers could either do one or the other - if you try loading a Xinerama config on a system with -intel, it crashes. Xrandr has some cool benefits, such as being able to shuffle monitors around, rotate them, etc. without having to reboot and without having to edit xorg.conf. However, it also has some limitations compared with Xinerama, such as being harder to do with multiple video cards; these limitations are just temporary setbacks though - the bad news is they require massive underlying structural changes to X's memory management, but the good news is that these changes are already under way and initial versions of the code are available upstream for testing (we experimented with this new libdrm TTM code during Hardy but found it wasn't rock solid stable, and didn't want to take this chance for Hardy - Intrepid seems a more appropriate time to land this new stuff).

It's sort of a shame that displayconfig-gtk came on the scene *just* as X was gaining momentum moving to the video autodetection stuff, because it really is a beautiful tool for situations where xorg.conf can be counted on to remain static, and it works pretty darn good with Xinerama layouts. But dynamic layout and xrandr is the way into the future.

We also looked into if we could rewire displayconfig-gtk to upgrade it to use Xrandr (ala bug 144641). Unfortunately this is sort of like converting a Ford Mustang into a Toyota Prius... both nice cars, but they have fundamentally different internals and designs. Moving from static xorg.conf configuration to dynamic on the fly configuration requires an entirely different design approach, and while the interface may look similar and may have similar knobs and levers, under the hood it's an entirely different game.

Yet, even though configuring with xrandr is a step up from hand editing xorg.conf, it's not a huge step. And indeed for people who like using gui tools such as displayconfig-gtk, it could be seen as a major step down.

So I took as a priority to try to implement a new replacement for us. Initially, I worked on a tool of my own design - http://bryceharrington.org/drupal/display-config-0. However, an important goal to me is that this not end up being a Ubuntu-specific thing like displayconfig-gtk had been, since that means that we're alone in maintaining it and because non-Ubuntu users would not benefit from it. So in chatting with upstream I found out about Soeren Sandmann's work for Fedora that GNOME was already considering for integration in a future version of GNOME, and decided to shift gears and join forces with him. With a bit of elbow grease, I got this integrated for us in Ubuntu: http://bryceharrington.org/drupal/display-config-1.

Please be aware that this is a very new tool - not even pushed to GNOME yet, and its features are far from complete. But it does let you set the resolutions, orientation, and refresh rates of both monitors, so already this is an advantage over the current situation for most people with displayconfig-gtk. And for this reason I think this particular bug can be closed as fix released. Not that I'm saying it solves every possible multi-monitor configuration need, only that it is able to handle this one particular problem of detecting and setting resolutions and so on when they're not listed in xorg.conf.

This tool can be accessed via the System -> Preferences -> Screen Resolution command. Indeed, with this we're finally getting back to having a single admin tool for display configuration (I know many were bugged about having two separate tools, even though they really had completely different purposes, so this should resolve that.)

The design *intent* of this tool is for doing multi-screen layouts (left-of/right-of), but unfortunately that is not implemented at the moment (bug 201593). Fixing bugs took precedence to this. This feature is coming soon, but I can't predict if it'll be in time for Hardy (it's getting pretty late in the release). I will be providing it in a ppa for Hardy when it's available in any case.

Other cool upcoming features that are likely to hit in Intrepid (and *possibly* sooner) include a better backend for handling crt/lcd switch hotkeys (e.g. bug 133568), automatic monitor plugin detection, which will select from pre-defined monitor configurations, and drag-and-drop gui multi-head monitor layouts. If you're interested in coding on these or other new features, please drop me a line and I can give more guidance.

Finally, even though we're switching focus to this new tool, displayconfig-gtk will still be present on your system for Hardy, just not installed in the menu by default. We want to avoid confusing the vast majority of people for whom this tool is now obsolete, but want to make sure the minority still using Xinerama or static configs still have the ability to access it, even though it takes an additional step to run. We still use displayconfig-gtk for the bulletproof-X mode, so need to have it around regardless (maybe one day the X server can auto-handle failsafe too!)