Ubuntu
xorg-server package

MASTER: Xinerama/Multihead with multiple video cards is not supported for most video drivers

Bug #316514 reported by Bryce Harrington
252
This bug affects 44 people
Affects Status Importance Assigned to Milestone
X.Org X server
Invalid
Medium
xorg-server (Ubuntu)
Triaged
Wishlist
Unassigned

Bug Description

Binary package hint: xorg

[Problem]
X does not support (or does not support very well) displaying a desktop across more than one video card. When it is possible, a variety of bugs are experienced.

[Discussion]
Prior to the introduction of Xrandr it was (sometimes) possible to configure xorg.conf to display on multiple video cards. One could then use Xinerama, etc. to stitch screens into a contiguous desktop. Of course, any alterations to this setup usually required hand-tuning xorg.conf.

The introduction of Xrandr made a number of things much easier, however it is not good at handling the case of multiple video cards. It can handle dual-head displays, where both monitors are connected to separate outputs on the same video card, but does not work as well with outputs on two different cards.

The fundamental problem (as I understand it) is essentially that X can talk to only one physical "pool" of memory, and each card has its own physical pool. Recent developments including GEM and several kernel changes promise to remedy this by enabling these pools to be aggregated and managed as a single virtual pool. Once the X server and drivers are updated to utilize this new architecture, they should be able to support multi-card functionality with Xrandr as well as (and better than) the old Xinerama configuration, including reconfiguring the display without needing to edit xorg.conf or restart X.

[Exceptions]
As mentioned above, the problem is most notable with drivers that have switched from Xinerama to Xrandr. If you're using an older driver that still uses the old Xinerama approach, you *might* find it works acceptably.

In my own testing, I've found cases where I could get displays across multiple cards (separate screens per-card) when running xrandr, but I ran into so many different bugs (mouse not working properly, X crashing, display corruption, etc.) that it was essentially unusable. Even if it could be made to work, this configuration is quite non-standard and not well tested. Resolving those issues will likely wait until the aforementioned architecture is fully in place.

The closed source -nvidia driver still uses Xinerama (it never got around to implementing Xrandr), so you can achieve multiple head displays that way. The nvidia configuration tool will be able to construct the xorg.conf settings for you to achieve Xinerama multi-head.

See original description
Tags: iso-testing
Revision history for this message
In , Pierre-bugzilla (pierre-bugzilla) wrote :

Created an attachment (id=7947)
xorg.conf

Xorg.0.log is unfortunately empty.

Revision history for this message
In , Michel-tungstengraphics (michel-tungstengraphics) wrote :

(In reply to comment #1)
>
> Xorg.0.log is unfortunately empty.

Please try

mount -o remount,sync <filesystem containing /var/log/Xorg.*.log>

before starting X.

Revision history for this message
In , Pierre-bugzilla (pierre-bugzilla) wrote :

Created an attachment (id=7962)
Xorg.0.log

Here you go.

This time I also got these extra lines to the console:

(**) RADEON(0): RADEONScreenInit finished
(**) RADEON(1): RADEONScreenInit d0000000 0

Revision history for this message
In , Ludov-dupont (ludov-dupont) wrote :

Created an attachment (id=8000)
Log of initialization failure

Revision history for this message
In , Ludov-dupont (ludov-dupont) wrote :

Created an attachment (id=8001)
Log of good initialization but exit failure

Revision history for this message
In , Ludov-dupont (ludov-dupont) wrote :

Created an attachment (id=8002)
Log of initialization and then good exit

Revision history for this message
In , Ludov-dupont (ludov-dupont) wrote :

Created an attachment (id=8003)
xorg.conf for two X800XL

Revision history for this message
In , Ludov-dupont (ludov-dupont) wrote :

Hi!

I experience the same problems as Pierre, but with two PCI-E cards (X800XL).

I have no problem if I only use one card at a time.

With both cards activated in my xorg.conf, I experience strange things :

- Sometimes, it will initialize both screens at the good resolutions/frequencies
(I can verify this on my monitors), but fail to launch the window manager.
- Sometimes, it will load X, where dri works great on both screens at the same
time (only tested with glxgears so far), but crash on exiting X.
- Sometime, everything is ok : launching X and exiting it.

It is quite sad that it is erratic as when I can launch X with DRI on both cards
(totally random : 50% probably as far as I observed), it works excellently
(thanks for the so good work on free acceleration to the DRI project).

I hope I don't abuse posting this on this bugreport, but my problem is really
similar to Pierre's one (except that sometimes, X will get launched). I also
join my logs and xorg.conf.

Otherwise, if it is of any help, let me know if I should install dri cvs (or
git, I don't know which one you use) to test patched version when there will be.
I am definately willing to help testing.

Revision history for this message
In , Ludov-dupont (ludov-dupont) wrote :

Just in order to give a precision (reading my message again made me understand
it was not clear) : as in Pierre's case, when X doesn't get launched, the
computer hard locks.

Revision history for this message
In , Pierre-bugzilla (pierre-bugzilla) wrote :

*poke*

Any tests we can perform to pinpoint the problem?

Revision history for this message
In , Michel-tungstengraphics (michel-tungstengraphics) wrote :

(In reply to comment #8)
> It is quite sad that it is erratic as when I can launch X with DRI on both cards
> (totally random : 50% probably as far as I observed), it works excellently

I didn't think this was even supposed to work yet, so consider yourself very
lucky when it does. :}

Revision history for this message
In , Pierre-bugzilla (pierre-bugzilla) wrote :

Would it be possible to get it working on at least one of the cards? Or is that
as difficult as getting it running on both?

Revision history for this message
In , Michel-tungstengraphics (michel-tungstengraphics) wrote :

(In reply to comment #12)
> Would it be possible to get it working on at least one of the cards? Or is that
> as difficult as getting it running on both?

I think it should be fine on one screen only (modulo AIGLX maybe see bug 9339).
The problem is that like most drivers, radeon currently enables the DRI when the
"dri" X server module is loaded, there's no direct way to enable it on one
screen but disable it on the other. I've been meaning to introduce Option "DRI"
for this but kept being preempted by more important stuff.

As a workaround, you could try causing the DRI to get disabled on one screen via
options that can't be satisfied, e.g. Option "GARTSize" with very large or small
values.

Revision history for this message
In , Pierre-bugzilla (pierre-bugzilla) wrote :

Still locks up, I'm afraid. I get this, so DRI should be disabled for the second
card:

(EE) RADEON(1): Illegal GART size: 512 MB

I also tried disabling AIGLX, but that didn't help.

Revision history for this message
In , Daniel Stone (daniels) wrote :

Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.

Revision history for this message
In , Ludov-dupont (ludov-dupont) wrote :

(In reply to comment #14)
> Still locks up, I'm afraid. I get this, so DRI should be disabled for the
> second
> card:
>
> (EE) RADEON(1): Illegal GART size: 512 MB
>
> I also tried disabling AIGLX, but that didn't help.
>

Hi there!

Sorry for not having answered earlier, but personnal problems have kept me off this problem for some time...

... this morning, I saw there was a quite recent packet for x11-drm on Gentoo (20070314) that I tried at once...

... what I can say for myself is that with this one, using an illegal AGPGartSize (eg 256, 512, 3000 for what I tested) on the card where I need opengl the least made X.org launch without hard-locking the machine... but the display on the no-dri screen (a merfedfb of two monitors on one PCI-E card) is totally corrupted... so much it is not usable... though the screen on the second card works ok, dri included (it serves me as an mythfrontend)...

... so, is there any specific AGPGartSize you could advice me to use, not to get this corruption?

Other than that, I have been testing the new drm module for a few hours and have to say that, without using AGPGartSize (not to get the borking of my screen), this one seems to be more stable for the, strange I have to confess (two cards, with a mergedfb pseudo xinerama on one of them, and a third monitor for mythtv), use I have of it :)

I still have random lockup, either on X startup or exit, but it happens a lot less... I would say everything goes ok between 3 times out of 4 or 4 times out of 5... and when it works, it is the only way I have to use, at the same time, MergedXinerama and not have mplayer detect the wrong size for fullscreen (as the only mode it can tweak fullscreen size detection is opengl mode... when in XV mode, it persists to detect the size of one of the crts on the other card... as do every fullscreen app I use on the second card... but for mplayer, the only satisfactory workaround for me is with the opengl fullscreen output)...

So really wonder if there is a way we can hope this bug be solved... opengl can solve many problems (like the fullscreen bug with fullscreen apps size detection on a second card when mergedfb pseudo-xinerama is used on another, which I still have to report)... and I assure you that this erratic bug is really rare and that everything works really good when X gets to be launched...

I remember you said that it is no even supposed to work yet, but it is even more encouraging as it does yet quite excellently (except for the lockups, rarest as I said)... In fact, those erratic lockups on exiting are the only thing that prevent me to keep it as is, because I do all my maintenance outside of X on the console, and I must be able to switch in and out of X without things locking up in the middle of an emerge... it already works but "only" needs to be, at least a bit more, stable...

Please let us know how we could be of any help... I dream so much of having a dual Metisse desktop with an opengl mythtv on a third screen (or at least my actual fvwm, plus opengl mythtv and the nice transitions) :D

Revision history for this message
Bryce Harrington (bryce) wrote : MASTER: Multiple video cards not supported

Binary package hint: xorg

[Problem]
X does not support (or does not support very well) displaying a desktop across more than one video card. When it is possible, a variety of bugs are experienced.

[Discussion]
Prior to the introduction of Xrandr it was (sometimes) possible to configure xorg.conf to display on multiple video cards. One could then use Xinerama, etc. to stitch screens into a contiguous desktop. Of course, any alterations to this setup usually required hand-tuning xorg.conf.

The introduction of Xrandr made a number of things much easier, however it is not good at handling the case of multiple video cards. It can handle dual-head displays, where both monitors are connected to separate outputs on the same video card, but does not work as well with outputs on two different cards.

The fundamental problem (as I understand it) is essentially that X can talk to only one physical "pool" of memory, and each card has its own physical pool. Recent developments including GEM and several kernel changes promise to remedy this by enabling these pools to be aggregated and managed as a single virtual pool.

[Exceptions]
As mentioned above, the problem is most notable with drivers that have switched from Xinerama to Xrandr. If you're using an older driver that still uses the old Xinerama approach, you *might* find it works acceptably.

In my own testing, I've found cases where I could get displays across multiple cards, but I ran into so many different bugs (mouse not working properly, X crashing, display corruption, etc.) that it was essentially unusable. Resolving those issues will likely wait until the aforementioned architecture is fully in place.

Changed in xorg:
importance: Undecided → Wishlist
status: New → In Progress
Bryce Harrington (bryce)
description: updated
Bryce Harrington (bryce)
description: updated
Bryce Harrington (bryce)
description: updated
Revision history for this message
Bryce Harrington (bryce) wrote :

Comment #13 on upstream bug 9231:

"> Would it be possible to get it working on at least one of the cards? Or is that
> as difficult as getting it running on both?

I think it should be fine on one screen only (modulo AIGLX maybe see bug 9339).
The problem is that like most drivers, radeon currently enables the DRI when the
"dri" X server module is loaded, there's no direct way to enable it on one
screen but disable it on the other. I've been meaning to introduce Option "DRI"
for this but kept being preempted by more important stuff.

As a workaround, you could try causing the DRI to get disabled on one screen via
options that can't be satisfied, e.g. Option "GARTSize" with very large or small
values."

Bug Watch Updater (bug-watch-updater)
Changed in xorg-server:
status: Unknown → In Progress
Ubuntu QA Website (ubuntuqa)
tags: added: iso-testing
Revision history for this message
djtoast (saube) wrote :

I also tried very hard to get this type of setup working without much sucess

2x nvidia cards. (Different versions ex.. 1 is 265gtx and the other cheap 8600 i beleive)
3 monitors.

at best I could get 2 monitors on same car using xinerama and 1 stand alone x.

I baught my new computer to do 3 monitors. unfortunately this means that i had to do the dreadfull thing of using windows as my operating system :(

Hope this gets better support in the future,

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

A patch to libpciaccess on bug http://bugs.freedesktop.org/show_bug.cgi?id=18160 upstream exists but doesn't solve the problem, just one small aspect of it. So not worth backporting it for lucid. Maybe lucid+1. The VGA arbiter work airlied is doing is needed on top of that.

Fwiw, if you're using two nvidia cards, then the -nvidia binary driver should support doing xinerama still.

Bryce Harrington (bryce)
summary: - MASTER: Multiple video cards not supported
+ MASTER: Xinerama/Multihead with several video cards is not supported
Bug Watch Updater (bug-watch-updater)
Changed in xorg-server:
importance: Unknown → Medium
Revision history for this message
Rudolf Cardinal (rudolf-pobox) wrote : Re: MASTER: Xinerama/Multihead with several video cards is not supported

I hope this is the right bug to add to; apologies if not.

My problem is: Xorg 1.9 can't do a single seamless desktop with two video cards without Xinerama.

I'm running Ubuntu 10.10 (Maverick) on a Asus P5N32-SLI motherboard with two NVidia GeForce 7600GS video cards (these are NV40-class cards as seen by Nouveau) through PCI. Each card is connected to a (rotatable) monitor, as it happens via DVI. My sequence of problems has been:

1. Current binary NVidia drivers for Ubuntu 10.04 allowed (with Xinerama) the left monitor to run in landscape mode and the right monitor in portrait mode (using ' Option "Rotate" "CCW" ' in the Device section of xorg.conf). However, they caused intermittent machine lockups (variably but including nothing-working crashes, including keyboard LEDs and kernel SysRq magic keys). Machine effectively unusable. So, out with NVidia drivers (except that their removal left the machine unbootable, so on to Ubuntu 10.10 and nouveau).

2. The Nouveau drivers reject Option "Rotate" ("(WW) NOUVEAU(1): Option "Rotate" is not used" in /var/log/Xorg.0.log).

3. Xinerama allows a seamless desktop, though without the ability to rotate one monitor. However, it crashes a bunch of apps at present; see bug https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/650539 . So Xinerama is (currently) out of the question, and, as I understand it, is deprecated in any case.

4. Creating two {Device, Monitor, Screen} sets of descriptions in xorg.conf, and stitching them together in the ServerLayout section [Screen 0 "Screen0" 0 0 / Screen 1 "Screen1" RightOf "Screen0"], allows two video cards with two monitors to be used. Great! And running "xrandr --screen 1 --output DVI-I-2 --rotate left" from a new file /etc/X11/Xsession.d/45custom-xrandr-settings allows the right-hand (second) monitor to go into portrait mode automatically following first login to X.

5. However, in this configuration there are two X screens, each with its own taskbar, and windows can't be dragged between screens, although the mouse pointer can wander between them. Presumably this reflects the problem of "one pool of memory per graphics card" described above, as other web sources suggest that a seamless desktop is easy to create on "dualhead" or similar (>1 output from a single video card) systems.

6. So, upshot: Xinerama is deprecated and now makes things crash, but X.org 1.9 with XRandR 1.3 doesn't seem able to create a seamless desktop across two video cards.

Bryce Harrington (bryce)
summary: - MASTER: Xinerama/Multihead with several video cards is not supported
+ MASTER: Xinerama/Multihead with multiple video cards is not supported
+ for most video drivers
description: updated
Bug Watch Updater (bug-watch-updater)
Changed in xorg-server:
importance: Medium → Unknown
status: In Progress → Invalid
Bug Watch Updater (bug-watch-updater)
Changed in xorg-server:
importance: Unknown → Medium
Bryce Harrington (bryce)
Changed in xorg-server (Ubuntu):
assignee: nobody → Chris Halse Rogers (raof)
Revision history for this message
Bryce Harrington (bryce) wrote :

While work continues upstream (-ati particularly), this is still an open issue in Ubuntu as of Precise. I don't foresee us getting a fix to this in the near term.

Changed in xorg-server (Ubuntu):
assignee: Chris Halse Rogers (raof) → nobody
status: In Progress → Triaged
Revision history for this message
Hanusz leszek (leszek-skynet) wrote :

Any new developments?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Related blueprints

Remote bug watches

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