MULTIHEAD SUPPORT META BUG

Bug #42731 reported by Fabio Massimo Di Nitto
226
This bug affects 1 person
Affects Status Importance Assigned to Milestone
xorg (Ubuntu)
Fix Released
Medium
Bryce Harrington

Bug Description

We know that multihead support in X generally sucks and needs to be seriously improved.

Let's collect all the multihead bugs under this one.

Pointless to clutter malone with N duplicates.

Fabio

Changed in xorg:
status: Unconfirmed → Confirmed
Revision history for this message
BryanLawrence (b-n-lawrence) wrote :

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.

Revision history for this message
Soewono Effendi (seffendi) wrote :

> (1) multihead support does suck, and everything
to do with configuring it is non-intuitive.

disagree, there might be some problem with "wrong configured" setup. But in other cases we showed that it is a great "feature" that is really needed, useable and very useful.

> (2) 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.

Yes indeed, we should stay with the newer version, please see wiki.ubuntu.com/MoreUbuntu

For sure "evdev" is still an issue, but multiseat feature is the real useful feature of dapper!

best regards

Revision history for this message
BryanLawrence (b-n-lawrence) wrote :

I still think there are two classes of problem here, that have not been recognised by lumping them together in this meta bug.

Yes, we need to work out how to deal with multihead better, but we should not BREAK things with a new release, and that's what happened with dapper.

Revision history for this message
Jiri Bajer (sarimak) wrote : Multihead bug #1

Okay, here's my two cents:

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-(

My observations are based on experience with laptop HP compaq nc6000 (Radeon Mobility 7600, xorg driver) and external LCD HP 1705.

Used SW versions (Dapper):
xserver-xorg 7.0.0-0ubuntu4
xrandr 1.0.1-0ubuntu1
xserver-xorg-driver-ati 6.5.7.3-0ubuntu7

The magical Device section used in Zaphod's /etc/X11/xorg.conf:
Driver "radeon"
Option "DynamicClocks" "true"
Option "MergedFB" "true"
Option "CRT2Position" "RightOf"
Option "Metamodes" "1400x1050-1280x1024 1400x1050"
Option "MergedNonRectangular" "true"

Revision history for this message
Jiri Bajer (sarimak) wrote : Correction of typo

Radeon Mobility 9600 (M10, RV350)

Revision history for this message
Anders (andersja+launchpad-net) wrote :

There's a pretty good howto for multi head / multiterminal Ubuntu here (however it still required a patched Xephyr etc.):
http://netpatia.blogspot.com/2006/09/multiseat-computer-with-ubuntu.html

Revision history for this message
Bryce Harrington (bryce) wrote :
Revision history for this message
james (james-nurealm) 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"?

Revision history for this message
Andy Toulouse (abject-resignation) wrote : Re: [Bug 42731] Re: MULTIHEAD SUPPORT META BUG

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.

Revision history for this message
Vernon Brewer (vmbrewer) wrote :

Thank you very much for the help. I appreciate it.
V. Brewer
----- Original Message -----
From: "Bryce Harrington" <email address hidden>
To: <email address hidden>
Sent: Monday, April 23, 2007 11:34 PM
Subject: [Bug 42731] Re: MULTIHEAD SUPPORT META BUG

Another howto: http://ubuntuforums.org/showthread.php?t=221174

--
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.

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.463 / Virus Database: 269.6.0/775 - Release Date: 4/24/2007
5:43 PM

Revision history for this message
Bryce Harrington (bryce) wrote :

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.

Changed in xorg:
assignee: nobody → bryceharrington
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.