New K6000 under linux and RANDR

Hi
We have 3 workstations running under RedHat Enterprise 7.4, each of them having a few K6000 graphic boards.

The configuration is relatively complex since the workstations are used for visualization on a monitor of approx. 6700mm x 2300mm. Since RANDR did not adjust the screens correctly, we did it manually - I am posting the xorg.conf below.

Everything was working fine, until driver version 384.90 was released. Since then, the screen is black. If RANDR is enabled again, the screens show up, but in an incorrect sequence. Disabling RANDR as we used to do all the time, now gives a black screen (with all 3 workstations).

Our guess is that now RANDR must be used and without RANDR it does not work anymore. Is this correct? Can this be changed again or is there a way to fix this problem?

It worked ever since we installed and configured the system, but now there is now way we can use the system anymore.

Thanks in advance
David


xorg.conf:

nvidia-settings: X configuration file generated by nvidia-settings

nvidia-settings: version 375.26 (buildmeister@swio-display-x86-rhel47-01) Thu Dec 8 19:06:44 PST 2016

Section “ServerLayout”
Identifier “Layout0”
Screen 0 “Screen0” 0 0
InputDevice “Keyboard0” “CoreKeyboard”
InputDevice “Mouse0” “CorePointer”
Option “Xinerama” “0”
EndSection

Section “Files”
FontPath “/usr/share/fonts/default/Type1”
EndSection

Section “InputDevice”
# generated from default
Identifier “Mouse0”
Driver “mouse”
Option “Protocol” “auto”
Option “Device” “/dev/input/mice”
Option “Emulate3Buttons” “no”
Option “ZAxisMapping” “4 5”
EndSection

Section “InputDevice”
# generated from default
Identifier “Keyboard0”
Driver “kbd”
EndSection

Section “Monitor”
# HorizSync source: edid, VertRefresh source: edid
Identifier “Monitor0”
VendorName “Unknown”
ModelName “LG Electronics W2442”
HorizSync 30.0 - 83.0
VertRefresh 56.0 - 75.0
Option “DPMS”
EndSection

Section “Device”
Identifier “Device0”
Driver “nvidia”
VendorName “NVIDIA Corporation”
BoardName “Quadro K6000”
BusID “PCI:2:0:0”
EndSection

Section “Screen”
Identifier “Screen0”
Device “Device0”
Monitor “Monitor0”
DefaultDepth 24
Option “Stereo” “3”
Option “nvidiaXineramaInfoOrder” “DFP-0”
Option “nvidiaXineramaInfo” “FALSE”
Option “metamodes” “GPU-0.DP-1: 1920x1080 +1920+1080, GPU-0.DVI-D-0: 1920x1080 +1920+0, GPU-0.DVI-I-1: 1920x1080 +0+0, GPU-0.DP-0: 1920x1080 +0+1080, GPU-1.DP-0: 1920x1080 +2386+1080, GPU-1.DP-1: 1920x1080 +4306+1080, GPU-1.DVI-D-0: 1920x1080 +4306+0, GPU-1.DVI-I-1: 1920x1080 +2386+0”
Option “SLI” “Off”
Option “MultiGPU” “Off”
Option “BaseMosaic” “1”

Alternative Konfiguration

Option “SLI” “On”

Option “SLIMosaic” “True”

Option “MultiGPU” “Off”

Option “BaseMosaic” “1”

SubSection     "Display"
    Depth       24
EndSubSection

EndSection

Section “Extensions”
Option “RANDR” “Disable”
EndSection

This should be working with randr enabled. Are you running this on plain X or do you use a desktop env, this could have a monitor manager interfering? There’s quite a big overlap of the monitors, is this intentional? Can you set the metamode after boot using
nvidia-settings --assign CurrentMetaMode="…"
To have more info, please set
Option “ModeDebug” “true”
in the screen section of the xorg.conf and attach the Xorg.0.log to your post.

Thanks for your answer. Unfortunately, it is not working correctly.
As stated, with RANDR disabled there is a black screen - with RANDR enabled the screens are placed in a wrong sequence.
Monitor manager: Gnome is started and then we normally use KDE.
The overlap is intentional, yes, we need this big overlap.
I set everything as you suggested.

The Xorg.0.log is under

I haven’t really tested it now, but it seems as if after setting the metamode things look pretty good.

Looks like the xserver is setting the correct mode which is then overriden by the DE. Previously you have been able to work around this by disabling randr so the DE couldn’t change it. Since this is obviously not working any more, you’ll have to override it in the DE itself.
If setting the metamode using nvidia-settings works, you can simply use an autostart entry to automate.
Otherwise, you’ll have to keep the DE from taking over modesetting.
I think for KDE, it is sufficient to disable the kscreen service in the KDE system service settings.
Gnome might be a bit harder, my first guess would be to delete the monitor configs once before starting X. Those are the monitors.xml files in ~/.config and /var/lib/gdm/.config directories. If that doesn’t work, you’ll have to modify those files by hand setting the desired values.

Strange what is happening, but as you write it seems as if the DE overrides everything. Also logging out and in again, messes everything up again (as expected).
On one of our 3 machines it is still not working correctly, but I haven’t had the time yet to find out what the problem could be.
So I will try the suggested workarounds and get back to you, if necessary.
Thanks a lot for your help!!!