I think there are at least two classes of bug here:
(1) multihead support does suck, and everything
to do with configuring it is non-intuitive.
(2) The recent xorg upgrade has definitely broken some things for high resolution monitors. Unless
there are *compelling* reasons to stay with the
newer version, or this bug is actually fixed, I think dapper should go back to a previous version.

Zaphod is computer serviceman and uses his employer's laptop for daily onsite work. When he returns to the office he plugs his lappie into the docking station (or plugs all the cables manually if his employer saves on equipment) and wants to use external keyboard, mouse and LCD without any interaction (or to switch the location/profile manually at worst). Keyb/mouse work out-of-the box atm but the external LCD doesn't.

To fix it manually (if Zaphod knows how to do it) he has to:
1) find out the resolutions of both laptop's internal LCD and external LCD
2) change /etc/X11/xorg.conf to add MergedFB support using fixed grahic pseudomode computed from both LCD's resloutions
3) restart Xorg to apply the changes
4) use xrandr to switch between single and dual LCD configs

What also works for him then:
1) he is able to switch the configs on-a-fly
2) when he has left some windows on the external LCD and switches to singlehead the windows are migrated to primary screen
3) dragging the windows between the screens works
4) panel is not duplicated on external screen
5) window maximization works even if the screens have got different resolutions
6) SOME applications are dualhead-aware and place the dialogs in the middle of screen (and not the viewport)
7) dualhead works fine with swsusp
8) there is no screen distortion/unused space if the screens have got different resolutions

What doesn't work and annoys him atm:
1) if the external LCD is not connected in the boot time (to be more specific: before Xorg startup) there is no way to switch into the dualhead else than to plug in the VGA cable and restart Xorg
2) he cannot use graphical xrandr front-ends (neither preferences dialog nor systray applet) because they crash when the dualhead mode is selected (and they also display invalid refresh rates - xrandr does this too but doesn't crash)
3) SOME silly-written apps/dialogs still don't care about multihead configurations and assume the middle of the screen = middle of the viewport (and thus place the windows partially on both screens and make their contents almost unreadable) - Hello, Openoffice, did you hear it? ;-)
4) there is no sane rule for new window placement - it depends on screen where is the focused window, screen where is mouse cursor, screen where is the parent window or what?
5) and the obvious one: everything must be configured manually and I'm pretty sure everything won't work for all graphic cards the same way B-(

This metabug is _not_ strictly a duplicate of Bug #96498. Specifically in the context of booting Ubuntu from the live CD, let us suppose that we do not care if the dual head display is correctly configured. Instead, we suppose that the user simply wants _a_ display, as opposed to a "black" screen, this being the difference between an "immediately usable" and "not immediately unusable" system, and assuming that the text-mode virtual-terminals are still running successfully, as was _not_ the case in one of the beta CDs, in which case the situation is even worse. To achieve this, the configuration script simply needs to distinguish the "currently in use" video card from the "not currently in use" video card, and then continue to configure a "single head" system, as normal. So the question is: Is there an easy way to distinguish which video card is "currently in use"?

I don't have a launchpad account, I don't know why I'm "a direct
subscriber of a duplicate bug," and I don't want these emails!
On Apr 24, 2007, at 8:07 AM, james wrote:

> This metabug is _not_ strictly a duplicate of Bug #96498.
> Specifically
> in the context of booting Ubuntu from the live CD, let us suppose that
> we do not care if the dual head display is correctly configured.
> Instead, we suppose that the user simply wants _a_ display, as opposed
> to a "black" screen, this being the difference between an "immediately
> usable" and "not immediately unusable" system, and assuming that the
> text-mode virtual-terminals are still running successfully, as was
> _not_
> the case in one of the beta CDs, in which case the situation is even
> worse. To achieve this, the configuration script simply needs to
> distinguish the "currently in use" video card from the "not
> currently in
> use" video card, and then continue to configure a "single head"
> system,
> as normal. So the question is: Is there an easy way to distinguish
> which video card is "currently in use"?
>
> --
> MULTIHEAD SUPPORT META BUG
> https://bugs.launchpad.net/bugs/42731
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.

Closing this bug because by and large the new xrandr capabilities take care of all the multi-head issues.

Not all drivers use xrandr currently - binary drivers in particular. However, all the major drivers do. There are some limitations such as needing to specify Virtual options for -intel, but these issues are reported separately already.

Configuration can now be done using either the xrandr command-line utility or in the xorg.conf file. In addition, we're anticipating having a GUI to do this, by either Hardy or Hardy+1.