Created attachment 81557 [details]
Xorg log file with Xinerama Enabled

Created attachment 81558 [details]
Xorg Configuratin File

Based on the backtrace, I think this is similar to bug #62914 -- try just commenting out the offending lines from the xf86-video-nouveau driver, i.e. something like

diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index b9b7164..8d782d3 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -346,11 +346,13 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr mode,
        drmmode_ConvertToKMode(crtc->scrn, &kmode, mode);
 
        fb_id = drmmode->fb_id;
+/*
 #ifdef NOUVEAU_PIXMAP_SHARING
        if (crtc->randr_crtc->scanout_pixmap)
                x = y = 0;
        else
 #endif
+*/
        if (drmmode_crtc->rotate_fb_id) {
                fb_id = drmmode_crtc->rotate_fb_id;
                x = 0;

You may also want to upgrade to 1.0.8 -- that has some zaphod-related fixes, I think. (You're not enabling ZaphodHeads -- I think you should be, unless you're only using a single monitor per video card.)

 Your comment was:

    I'm trying to drive 4 monitors in a 2x2 configuration using as single video card, which appears as two cards with two outputs on each card.
    Without using an xorg.conf file two of the monitors by default are set up as one display and the other two monitors are black, althought the log file does show the other displays are detected.
    With my xorg.conf file I now have two monitors as one display and the other two monitors as a second display :0.0 and :0.1, although only :0.0 has a menu at the top of the screen.
    I am running the latest version of Fedora - downloaded it a few days ago.
    I have had a similar configuration working for some time, but with Kubuntu and two physically distinct ATI cards and the closed source driver, only changed configuration because one of the cards failed.  As part of trying to get up and running again I'm now using a different video card and have switched to Fedora.
    When I enable Xinerama I get a segmentation fault (log file attached).
    I gather I am supposed to have a Screen 0 and Screen 1 for each pair of outputs in the Device sections, however if I uncomment those lines X stalls on startup, but doesn't crash - I can still log on using <Ctrl><Alt><F2>
    Any help woudld be appreciated.
    Best Regards
    Trev

I've upgraded to 1.0.8 and enabled ZaphodHeads, and it doesn't appear to make any difference, with the exception that when I get the segmentation error I can now switch to a terminal using <Ctrl><Alt><F2>.  I'll attach the new Xorg.0.log and new xorg.conf.

Created attachment 81570 [details]
new xorg.conf

Created attachment 81571 [details]
Xorg log file with Xinerama and ZaphodHead Enabed (1.0.8)

Using the ZaphodHeads and Xinerama enabled and having commented out the lines below:

/*
 #ifdef NOUVEAU_PIXMAP_SHARING
        if (crtc->randr_crtc->scanout_pixmap)
                x = y = 0;
        else
 #endif
*/

It now starts without crashing, however I'm getting some odd effects and although I can drag a window to the bottom double display it isn't visible and I'm getting the full width of the screen buffer in the top left window, so when I move the mouse across the desktop moves sideways, showing what is on the right hand display (although clicking on the copy on the left window has no effect). The top right display is the only screen that appears correctly.

Best Regards

Trev

I think your Xorg config is a little off. Take a look at:

http://nouveau.freedesktop.org/wiki/MultiMonitorDesktop/

You need to define 4 screens, one for each monitor, but you appear to only have 2. (Also, I'm not 100% sure that the example is correct -- it references Screen 0/1 twice, that might be a typo and perhaps should be Screen 0/1/2/3... not entirely sure though.)

I've made a copy of the example xorg.conf, only changing the address of the PCI addresses, it runs and it produces a small window saying it is in fallback mode and obviously as I want to run a 2x2 configuration the displays were in the wrong place.  Just altering it to put the displays in the correct place causes all displays to come up as black.
This may be caused by one of the monitors only being capable of 1024x768 and the others being capable of 1280x1024 and the driver not being able to sort it out.
I've altered xorg.conf to set all the displays to default to 1024x768 and now it starts up, but when I try to expand or drag a window from display DVI-I-1 to any of the other displays the only thing visible in the other displays is the mouse.
All of the above were attempted using 1.0.8 with the section you suggested commented out.
I'll attach the latest xorg.conf file

Created attachment 81654 [details]
xorg.conf only top left display working properly

Created attachment 81655 [details]
Xorg.0.log with only top left display working properly (all at 1024x768)

The xorg.conf I used with two screen sections produces a 2x2 display with the menu at the top spanning 2 monitors, this is as I would like (except when Xinerama is enabled to join the two screens it goes wrong).

The xorg.conf I used with four screen sections (zaphod head) as per the example doesn't work either, but also the menu is only the width of one display which at 1024x768 doesn't fit very well.

As far as I know in theory both versions should work - but there seems to be some sort of problem with Xinerama working with a 2x2 display.

Best Regards
Trev

Hi

I'm not sure about this - I've not done any C programming for a long time, the bit of code below from panoramiXprocs.c line 1837 where it has:
y < -wBorderWidth((WindowPtr)pDraw)
is there supposed to be a gap between the - symbol and the function? wBorderWidth call and if so is that likely to cause a problem?

Trev

      if( /* check for being onscreen */
screenInfo.screens[0]->x + pDraw->x + x < 0 ||
screenInfo.screens[0]->x + pDraw->x + x + w > PanoramiXPixWidth ||
screenInfo.screens[0]->y + pDraw->y + y < 0 ||
screenInfo.screens[0]->y + pDraw->y + y + h > PanoramiXPixHeight ||
/* check for being inside of border */
        x < - wBorderWidth((WindowPtr)pDraw) ||
x + w > wBorderWidth((WindowPtr)pDraw) + (int)pDraw->width ||
y < -wBorderWidth((WindowPtr)pDraw) ||
y + h > wBorderWidth ((WindowPtr)pDraw) + (int)pDraw->height)
return BadMatch;
    }

Spaces around operators don't matter in C. You can even do one of my favourites:

while (x --> 0) { // as x goes to 0
  ...
}

:)

The commit roughly implementing what I was suggesting has been pushed out into xf86-video-nouveau 1.0.9. But we can repurpose this bug to be about xinerama-fail. I unfortunately can't really help with that though. I'm also having a bit of a hard time understanding what you mean when you're describing those problems, perhaps taking a photo would help. Do note that Xinerama is considered to be the devil's spawn nowadays, so getting a card with 4 outputs could be the way to go -- NVE0+ cards can have support for that. If, OTOH, you're satisified with having 2 separate screens of 2 monitors each (which I guess is what you were doing at first) and not being able to drag windows across them, then the multi-screen solution should work too... (just get rid of zaphod heads/xinerama, but keep the separate device/screen sections pointing at the right things)

Hi,
I did try the change and it made no difference.
My 4 monitors are working as a single screen 4 monitors across and one monitor high, unfortunately they are physically positioned as 2 across and two high.
As specified previoulsy if I change the configuration to match the physical setup and try to have a single screen two monitors across and two monitors high I get a segmentation fault.
I did purchase a single card with 4 outputs, unfortunately it is internally configured as 2 seperate pci addresses (the card was secondhand).
Best Regards
Trev

You probably got the NVS 450. If you get a kepler-based chipset (most GeForce 600/700 cards... but not all!) it will be a single GPU.

Anyways, can you please show the backtrace you get with xf86-video-nouveau 1.0.9? And the xorg.conf that you get it with? I thought that should have been fixed...

Created attachment 84350 [details]
1.0.9 sliding and seperate top and bottom displays

Using 1.0.9 a segmentation fault no longer occurs, however the driver isn't performing as expected.
The attached file causes the display on the individual monitors to move sideways as you move the mouse from one monitor to the next.  In addition the top two monitors act as one screen and the bottom two as a different screen and you cannot bridge across them with a program window(e.g a browser).

Created attachment 84351 [details]
log file for sliding seperate top and bottom

http://nouveau.freedesktop.org/wiki/MultiMonitorDesktop/

You only have 2 screens in your config, you need 4 screens for Xinerama to work properly (one per monitor). Otherwise it makes sense that you get the scrolling behaviour. Have you tried this with nouveau 1.0.9?

An alternative if you have xorg 1.14.3, is to use reverse prime. This is a bit experimental and will likely be rather slow. (Basically using GPU0 to do all the rendering and transfer the textures to GPU1 for actual display.) To do that, take a look at http://nouveau.freedesktop.org/wiki/Optimus/ (it's describing a different case, but some of the ideas carry over).

No retest in years. Given that people have gotten 20-screen walls working with nouveau, this is most likely an issue with the user's configuration. Marking as invalid.