Display Boundary Bug? - 2 cards, 4 monitors, 2 X screens, Twinview on each X screen

I’m trying to configure my X environment using two graphics cards (one GT440 and one GT520) using 4 NEC monitors in portrait mode (1080x1920). I have configured two X screens (one per video card) and each device is set to use TwinView mode. The problem I’m having is, once I enable the second video card the first two displays (those connected to the first video card) no longer act as 2 individual displays but instead become one big 2160x1920 display and the window manager can’t tell that there are any boundaries anywhere between the two. When I have the second video card disabled, the WM has no problems at all distinguishing that that are 2 display entities.

I’ve verified that it is not an issue with the window manager itself by trying many different ones. Also the fact that it works fine with only one video card activated more or less eliminates the WM as the issue. Enabling Xinerama only makes matters worse, besides the fact that this is less than ideal anyway. In this meantime I’ve been running all 4 displays in Zaphod mode (4 X screens) but there really is no reason I can think of why this shouldn’t work with 2 X screens using TwinView.

I’ve attached two multihead screenshots below (created with ‘scrot -m’) to illustrate this issue. One is with the 2nd video card enabled, the other with it disabled. Also, here is the configuration I’m trying to use.

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "TwinScreen0" 0 0
    Screen      1  "TwinScreen1" RightOf "TwinScreen0"
    Option         "Xinerama" "0"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "NEC EX231W"
    HorizSync       31.0 - 83.0
    VertRefresh     56.0 - 76.0
    Option         "DPMS"
EndSection

Section "Monitor"
    Identifier     "Monitor1"
    VendorName     "Unknown"
    ModelName      "NEC EX231W"
    HorizSync       0.0 - 0.0
    VertRefresh     0.0
    Option         "DPMS"
EndSection

Section "Monitor"
    Identifier     "Monitor2"
    VendorName     "Unknown"
    ModelName      "NEC EX231W"
    HorizSync       0.0 - 0.0
    VertRefresh     0.0
    Option         "DPMS"
EndSection

Section "Monitor"
    Identifier     "Monitor3"
    VendorName     "Unknown"
    ModelName      "NEC EX231W"
    HorizSync       0.0 - 0.0
    VertRefresh     0.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GT 440"
    Option	   "MetaModes"			"1920x1080, 1920x1080"
    Option	   "ConnectedMonitor"		"DFP-0, DFP-1"
    Option	   "MetaModeOrientation"	"DFP-0 RightOf DFP-1"
    BusID          "PCI:1:0:0"
EndSection

Section "Device"
    Identifier     "Device1"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GT 520"
    Option	   "MetaModes"			"1920x1080, 1920x1080"
    Option	   "ConnectedMonitor"		"DFP-0, DFP-1"
    Option	   "MetaModeOrientation"	"DFP-0 RightOf DFP-1"
    BusID          "PCI:3:0:0"
EndSection

Section "Screen"
    Identifier     "TwinScreen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option	   "TwinView" "True"
    Option         "nvidiaXineramaInfoOrder" "DFP-1,DFP-0"
    Option         "metamodes" "DFP-0: nvidia-auto-select { Rotation=left }, DFP-1: nvidia-auto-select { Rotation=left }"
    Option	   "TwinViewOrientation"	"DFP-0 RightOf DFP-1"
    SubSection     "Display"
	Modes	    "1920x1080,1920x1080"
        Depth       24
    EndSubSection
EndSection

Section "Screen"
    Identifier     "TwinScreen1"
    Device         "Device1"
    Monitor        "Monitor2"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option	   "TwinView" "True"
    Option         "nvidiaXineramaInfoOrder" "DFP-0"
    Option         "metamodes" "DFP-0: nvidia-auto-select { Rotation=left }, DFP-1: nvidia-auto-select { Rotation=left }"
    Option	   "TwinViewOrientation"	"DFP-0 RightOf DFP-1"
    SubSection     "Display"
	Modes	    "1920x1080,1920x1080"
        Depth       24
    EndSubSection
EndSection

2012-11-16-141639_4320x1920_scrot.png4320×1920 410 KB

2012-11-16-155641_2160x1920_scrot.png2160×1920 270 KB

Does it help if you manually specify your layout through the nvidiaXineramaInfoOverride X config option?

ftp://download.nvidia.com/XFree86/Linux-x86/310.14/README/xconfigoptions.html#nvidiaXineramaInfoOverride

I added the following line to the Device section then to the Screen section but it did not change and/or fix the issue.

Option “nvidiaXineramaInfoOverride” “1920x1080+0+0, 1920x1080+1080+0”

Anything else I could try?

Also, I’m assuming my setup isn’t too common, so if there’s any debug information that would be helpful just let me know what to run and I’ll provide the output. I’m also lurking on the Freenode IRC channel.

Thanks!

The Xinerama extension (the actual X protocol that the server uses to communicate with clients) only supports one X screen. As soon as you enable two, the Xinerama extension cannot work and gets disabled. You can check it with “xdpyinfo -ext XINERAMA”. This is presumably what your window manager is trying to use to determine where the physical display boundaries are.

So then, you’re saying this is a limitation with Xorg and what I’m trying to do isn’t possible? Then the only way for me to make each display have its own boundaries is to use zaphod mode and abandon twinview altogether? I’ve used zaphod mode before and I know that will indeed work, it’s just of course less desirable since I then can’t span and/or move any clients across 2 of the screens.

Here’s the output from ‘xdpyinfo -ext XINERAMA’:

name of display:    :0.0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    11300000
X.Org version: 1.13.0
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    7
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  window 0x2c00009, revert to Parent
number of extensions:    27
    BIG-REQUESTS
    Composite
    DAMAGE
    DOUBLE-BUFFER
    DPMS
    DRI2
    GLX
    Generic Event Extension
    MIT-SCREEN-SAVER
    MIT-SHM
    NV-CONTROL
    NV-GLX
    RANDR
    RECORD
    RENDER
    SECURITY
    SHAPE
    SYNC
    X-Resource
    XC-MISC
    XFIXES
    XFree86-DGA
    XFree86-VidModeExtension
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
default screen number:    0
number of screens:    3

screen #0:
  dimensions:    2160x1920 pixels (1035x290 millimeters)
  resolution:    53x168 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32
  root window id:    0x760
  depth of root window:    24 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x20
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 16777215
  options:    backing-store NO, save-unders NO
  largest cursor:    64x64
  current input event mask:    0x7a403f
    KeyPressMask             KeyReleaseMask           ButtonPressMask          
    ButtonReleaseMask        EnterWindowMask          LeaveWindowMask          
    KeymapStateMask          StructureNotifyMask      SubstructureNotifyMask   
    SubstructureRedirectMask FocusChangeMask          PropertyChangeMask       
  number of visuals:    228
  default visual id:  0x21
  visual:
    visual id:    0x21
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x22
    class:    DirectColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits

(4000+ more lines of the same visual ID stuff)

Hmm, I expected the Xinerama extension to still exist and just report itself as disabled, not be missing entirely. In any case, you can work around it by overriding what X clients see using the fake Xinerama library.