[Feature Request] Proper support of tiled displays (4K, 5K etc.) in Linux

[michael9999]

This problem has been mentioned many times before. E.g.: Xorg-1.16 configuration for 5k (5120 x 2880) display with two DP inputs - Linux - NVIDIA Developer Forums

I also have a 5K Dell UP2715K which is connected via two display ports and is exposed to the X server as two 2560x2880 tiles. (connected to two DP ports of a GTX 1080 card in my case)

Tiled displays turn out to be a real pain in Linux for no good reason. And this problem is not going away as mentioned by X.org developers on their mailing list: How do we want to deal with 4k tiled displays?

Hopefully, the situation with current 4k monitors is temporary and we’ll
start seeing single-tile 4k displays soon, fixing the problem “forever”.
Until we get 8k tiled displays.

Moreover, this problem does not exist in Windows. I tried the same setup in Windows 10 and it just works, the display is exposed as one 5120x2880 panel as it should be. (+ there is this statement which I guess applies to Windows only: https://developer.nvidia.com/4k-ultra-high-resolution-development : “The NVIDIA driver automatically detects 4K 60Hz tiled format, so no special user set up is required.”) So, NVIDIA developers, why did you choose to torture us - Linux users - with this? ;)

There is a “solution” in X.org and RANDR 1.5 - MST-monitors (see also this page for links to some initial implementation patches and comments: RandR 1.5 Brings Monitor Objects & Tile Support For X.Org - Phoronix ) - which introduced the concept of “Monitor” objects (in addition to all other concepts in RANDR) and exposure of the TILE property from EDID. (and recent NVIDIA drivers started to expose that TILE property to RANDR) Which is a very odd solution in my opinion. Here is why:

1. There is no good reason to expose a tiled display as separate displays to X/RANDR. What would be the use cases for this? Why would you want to treat regions of the same physical display as separate entities in the context of RANDR functionality? What purpose would this serve?
2. Most applications (window managers / composers, games etc.) which access RANDR extension are still unaware that they should also consider "Monitors" instead of or in addition to "Outputs". (imagine a multiple monitor setup with a mix of tiled and non-tiled displays) And it is unreasonable to expect them all to implement this especially considering that there is no tangible benefits of this "solution" (see the previous point).
3. Lower resolution modes of this particular monitor are driven via only one port (see below for details), which further underlines the absurdity of exposing it as two displays merely because its native mode requires data to be sent to two ports due to DP bandwidth restrictions

A proper solution would be if THE DRIVER would combine the two outputs/CRTCs into one logical device and expose that to X/RANDR. (I guess something like this is already implemented in the Windows driver) How to do this? I suspect that the answer is in EDID (a.k.a. DisplayID) data. Here is what it looks like for my monitor:

Left Tile:

$ edid-decode < edid-dfp-3.bin 
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   10 ac b6 40 53 38 35 38 1d 1a
version:         01 04
basic params:    b5 3c 22 78 3a
chroma info:     72 25 ac 50 33 b7 26 0b 50 54
established:     00 00 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    9f 0b 50 a0 30 e0 0e 10 30 20 35 00 55 50 21 00 00 1a
descriptor 2:    00 00 00 ff 00 33 44 38 46 38 36 37 4a 38 35 38 53 0a
descriptor 3:    00 00 00 fc 00 44 45 4c 4c 20 55 50 32 37 31 35 4b 0a
descriptor 4:    00 00 00 fd 00 1d 4b 1f b4 36 01 0a 20 20 20 20 20 20
extensions:      01
checksum:        a7

Manufacturer: DEL Model 40b6 Serial Number 943011923
Made week 29 of 2016
EDID version: 1.4
Digital display
10 bits per primary color channel
DisplayPort interface
Maximum image size: 60 cm x 34 cm
Gamma: 2.20
DPMS levels: Off
Supported color formats: RGB 4:4:4, YCrCb 4:4:4, YCrCb 4:2:2
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed mode: Clock 29.750 MHz, 597 mm x 336 mm
                848  896  928 1008 hborder 0
                480  483  488  494 vborder 0
               +hsync -vsync 
Serial number: 3D8F867J858S
Monitor name: DELL
Monitor ranges (bare limits): 29-75Hz V, 31-180kHz H, max dotclock 540MHz
Has 1 extension blocks
Checksum: 0xa7 (valid)

DisplayID extension block
Extension version: 18
Length 121, version 18, extension count 0
tiled display block: capabilities 0x00000080
num horizontal tiles 2, num vertical tiles 1
tile location (0, 0)
tile dimensions (2560, 2880)
Type 1 detailed timing: aspect: 16:9,  
Detailed mode: Clock 238.240 MHz, 0 mm x 0 mm
               2559 2606 2637 2718
               2879 2881 2890 2919
               +hsync -vsync
Type 1 detailed timing: aspect: 16:9,  
Detailed mode: Clock 483.240 MHz, 0 mm x 0 mm
               2559 2606 2637 2718
               2879 2881 2890 2960
               +hsync -vsync

EDID block does NOT conform to EDID 1.3!
        Detailed block string not properly terminated

Right Tile:

$ edid-decode < edid-dfp-5.bin  
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   10 ac b6 40 53 38 35 38 1d 1a
version:         01 04
basic params:    b5 3c 22 78 3a
chroma info:     72 25 ac 50 33 b7 26 0b 50 54
established:     21 08 00
standard:        81 00 b3 00 d1 00 a9 40 81 80 d1 c0 01 01 01 01
descriptor 1:    56 5e 00 a0 a0 a0 29 50 30 20 35 00 55 50 21 00 00 1a
descriptor 2:    00 00 00 ff 00 33 44 38 46 38 36 37 4a 38 35 38 53 0a
descriptor 3:    00 00 00 fc 00 44 45 4c 4c 20 55 50 32 37 31 35 4b 0a
descriptor 4:    00 00 00 fd 00 1d 4b 1f b4 36 01 0a 20 20 20 20 20 20
extensions:      02
checksum:        c4

Manufacturer: DEL Model 40b6 Serial Number 943011923
Made week 29 of 2016
EDID version: 1.4
Digital display
10 bits per primary color channel
DisplayPort interface
Maximum image size: 60 cm x 34 cm
Gamma: 2.20
DPMS levels: Off
Supported color formats: RGB 4:4:4, YCrCb 4:4:4, YCrCb 4:2:2
First detailed timing is preferred timing
Established timings supported:
  640x480@60Hz
  800x600@60Hz
  1024x768@60Hz
Standard timings supported:
  1280x800@60Hz
  1680x1050@60Hz
  1920x1200@60Hz
  1600x1200@60Hz
  1280x1024@60Hz
  1920x1080@60Hz
Detailed mode: Clock 241.500 MHz, 597 mm x 336 mm
               2560 2608 2640 2720 hborder 0
               1440 1443 1448 1481 vborder 0
               +hsync -vsync 
Serial number: 3D8F867J858S
Monitor name: DELL
Monitor ranges (bare limits): 29-75Hz V, 31-180kHz H, max dotclock 540MHz
Has 2 extension blocks
Checksum: 0xc4 (valid)

CEA extension block
Extension version: 3
8 bytes of CEA data
  Audio data block
    Linear PCM, max channels 2
    Supported sample rates (kHz): 48 44.1 32
    Supported sample sizes (bits): 24 20 16
  Speaker allocation data block
    Speaker map: FL/FR
Underscans PC formats by default
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
1 native detailed modes
Detailed mode: Clock 533.250 MHz, 597 mm x 336 mm
               3840 3920 3952 4000 hborder 0
               2160 2214 2219 2222 vborder 0
               -hsync -vsync 
Detailed mode: Clock 241.500 MHz, 597 mm x 336 mm
               2560 2608 2640 2720 hborder 0
               1440 1443 1448 1481 vborder 0
               +hsync -vsync 
Checksum: 0x34 (valid)

DisplayID extension block
Extension version: 18
Length 121, version 18, extension count 0
tiled display block: capabilities 0x00000082
num horizontal tiles 2, num vertical tiles 1
tile location (1, 0)
tile dimensions (2560, 2880)
Type 1 detailed timing: aspect: 16:9, Preferred  
Detailed mode: Clock 533.240 MHz, 0 mm x 0 mm
               3839 3886 3917 3998
               2159 2161 2165 2220
               +hsync -vsync
Type 1 detailed timing: aspect: 16:9,  
Detailed mode: Clock 238.240 MHz, 0 mm x 0 mm
               2559 2606 2637 2718
               2879 2881 2890 2919
               +hsync -vsync
Type 1 detailed timing: aspect: 16:9,  
Detailed mode: Clock 483.240 MHz, 0 mm x 0 mm
               2559 2606 2637 2718
               2879 2881 2890 2960
               +hsync -vsync
VESA DMT timing block

EDID block does NOT conform to EDID 1.3!
        Detailed block string not properly terminated
EDID block does not conform at all!
        Impossible extension block count

Errors at the and are obviously due to the fact that the edid-decode utility does not support EDID 1.4 blocks.
I am also attaching the raw binary and textual EDID dumps obtained via NVIDIA’s GUI tool.

Here is also somewhat more readable output from xrandr -prop (RANDR’s DP-0 corresponds to NVIDIA’s DFP-3, DP-2 to DFP-5):

Screen 0: minimum 8 x 8, current 5120 x 2880, maximum 32767 x 32767
DVI-D-0 disconnected (normal left inverted right x axis y axis)
        CscMatrix: 65536 0 0 0 0 65536 0 0 0 0 65536 0 
        BorderDimensions: 4 
                supported: 4
        Border: 0 0 0 0 
                range: (0, 65535)
        SignalFormat: TMDS 
                supported: TMDS
        ConnectorType: DVI-D 
        ConnectorNumber: 0 
        _ConnectorLocation: 0 
HDMI-0 disconnected (normal left inverted right x axis y axis)
        CscMatrix: 65536 0 0 0 0 65536 0 0 0 0 65536 0 
        BorderDimensions: 4 
                supported: 4
        Border: 0 0 0 0 
                range: (0, 65535)
        SignalFormat: TMDS 
                supported: TMDS
        ConnectorType: HDMI 
        ConnectorNumber: 3 
        _ConnectorLocation: 3 
HDMI-1 disconnected (normal left inverted right x axis y axis)
        CscMatrix: 65536 0 0 0 0 65536 0 0 0 0 65536 0 
        BorderDimensions: 4 
                supported: 4
        Border: 0 0 0 0 
                range: (0, 65535)
        SignalFormat: TMDS 
                supported: TMDS
        ConnectorType: HDMI 
        ConnectorNumber: 4 
        _ConnectorLocation: 4 
DP-0 connected primary 2560x2880+0+0 (normal left inverted right x axis y axis) 600mm x 340mm
        CscMatrix: 65536 0 0 0 0 65536 0 0 0 0 65536 0 
        TILE: 453 1 2 1 0 0 2560 2880 
        EDID: 
                00ffffffffffff0010acb64053383538
                1d1a0104b53c22783a7225ac5033b726
                0b505400000001010101010101010101
                0101010101019f0b50a030e00e103020
                350055502100001a000000ff00334438
                463836374a383538530a000000fc0044
                454c4c205550323731354b0a000000fd
                001d4b1fb436010a20202020202001a7
                701279000012001680100000ff093f0b
                000000000044454cb640533835380300
                28105d0004ff099f002f801f003f0b28
                0002000900c4bc0004ff099f002f801f
                003f0b51000200090000000000000000
                00000000000000000000000000000000
                00000000000000000000000000000000
                00000000000000000000000000007b90
        BorderDimensions: 4 
                supported: 4
        Border: 0 0 0 0 
                range: (0, 65535)
        SignalFormat: DisplayPort 
                supported: DisplayPort
        ConnectorType: DisplayPort 
        ConnectorNumber: 2 
        _ConnectorLocation: 2 
   848x480       59.74 +
   2560x2880     59.98*   29.99  
DP-1 disconnected (normal left inverted right x axis y axis)
        CscMatrix: 65536 0 0 0 0 65536 0 0 0 0 65536 0 
        BorderDimensions: 4 
                supported: 4
        Border: 0 0 0 0 
                range: (0, 65535)
        SignalFormat: TMDS 
                supported: TMDS
        ConnectorType: DisplayPort 
        ConnectorNumber: 2 
        _ConnectorLocation: 2 
DP-2 connected 2560x2880+2560+0 (normal left inverted right x axis y axis) 600mm x 340mm
        CscMatrix: 65536 0 0 0 0 65536 0 0 0 0 65536 0 
        TILE: 453 1 2 1 1 0 2560 2880 
        EDID: 
                00ffffffffffff0010acb64053383538
                1d1a0104b53c22783a7225ac5033b726
                0b50542108008100b300d100a9408180
                d1c001010101565e00a0a0a029503020
                350055502100001a000000ff00334438
                463836374a383538530a000000fc0044
                454c4c205550323731354b0a000000fd
                001d4b1fb436010a20202020202002c4
                02030cf123090707830100004dd000a0
                f0703e805020650c555021000018565e
                00a0a0a029503020350055502100001a
                00000000000000000000000000000000
                00000000000000000000000000000000
                00000000000000000000000000000000
                00000000000000000000000000000000
                00000000000000000000000000000034
                701279000012001682101000ff093f0b
                000000000044454cb640533835380300
                3c4cd00084ff0e9f002f801f006f083d
                0002000400105d0004ff099f002f801f
                003f0b280002000900c4bc0004ff099f
                002f801f003f0b51000200090007000a
                08810008040004021000000000000000
                0000000000000000000000000000c590
        BorderDimensions: 4 
                supported: 4
        Border: 0 0 0 0 
                range: (0, 65535)
        SignalFormat: DisplayPort 
                supported: DisplayPort
        ConnectorType: DisplayPort 
        ConnectorNumber: 1 
        _ConnectorLocation: 1 
   2560x1440     59.95 +
   3840x2160     60.00    60.00  
   2560x2880     59.98*   29.99  
   1920x1200     59.88  
   1920x1080     60.00  
   1680x1050     59.95  
   1600x1200     60.00  
   1280x1024     60.02  
   1280x800      59.81  
   1024x768      60.00  
   800x600       60.32  
   640x480       59.95    59.94  
DP-3 disconnected (normal left inverted right x axis y axis)
        CscMatrix: 65536 0 0 0 0 65536 0 0 0 0 65536 0 
        BorderDimensions: 4 
                supported: 4
        Border: 0 0 0 0 
                range: (0, 65535)
        SignalFormat: TMDS 
                supported: TMDS
        ConnectorType: DisplayPort 
        ConnectorNumber: 1 
        _ConnectorLocation: 1

So, from what I understand from the above, the native resolution (5120x2880) needs to be driven via the tiled mode which needs to be driven via two DP connectors. The rest of the supported modes should be driven by ONLY ONE of the connectors, as those modes’ bandwidth “fits” into one port. (the driver should request the mode setting on one port and turn off the other port?) In other words, the algorithm to construct the display device (and the list of modes) that should be exposed to X/RANDR should be something like this:

• Parse EDID info of all connected displays
• If there is tile info present, combine the corresponding "displays" into one and expose the result to X/RANDR instead of exposing every device separately
• In order to do this:
• Use the tile info to construct the native mode, look up the corresponding tile's modes to set proper modes on all tiles/ports (i.e. 2560x2800 on two tiles/"displays" in this case)
• Go over the rest of the modes, noting which of the ports should be used to set that mode.

In other words, the driver should construct and maintain some sort of table (or other structure) for connected tiled displays. Something like this:
(left column exposed to X/RANDR, right column used by the driver internally to control the display ports)

5120x2880@60 - [2560x2880@60, 2560x2880@60]
2560x1440@60 - [off         , 2560x1440@60]
... etc.

Could you please implement this? I appreciate all the effort the NVIDIA developers invest in maintaining Linux drivers, but could you please show us a little bit more love?
edid-dfp-3.txt (768 Bytes)
edid-dfp-5.txt (1.13 KB)
edid-dfp-3.bin.gz (195 Bytes)
edid-dfp-5.bin.gz (270 Bytes)

[michael9999]

For those who are also struggling with this problem, here is the workaround I am currently using. (xorg.conf is attached)

I use KDE/plasma/kwin whose kscreen (“display manager” which manages displays via RANDR) treats my display as two separate ones by default. To trick it (and other software that uses RANDR info/API) into treating the display as a whole I use Option “Xinerama” “1” in my xorg.conf to disable RANDR extension.

This is somewhat unsupported configuration (the driver complains about it in the X.org log) but it works for the most part.

This breaks software that expects RANDR extension to be present, and it appears that it is expected to be present these days. For example, I’ve had to fix a bug in gtk/gdk (see: Bug 773601 – Display size detected as 0x0 pixels when RANDR is not available ) as apparently no one noticed or cared that gtk/gdk was broken when RANDR extension is not present. Another example is The Talos Principle game, which just crashes when trying to issue some RANDR calls as far as I can tell. Most software works fine though.

xorg.conf.gz (702 Bytes)

[michael9999]

Also, attached is my monitor’s specification (Dell UP2715K). The specifications of supported modes start at page 12.
104196.pdf (9.77 MB)

[michael9999]

And here is the diff of the parsed dumps of two tiles (dfp-3 is left, dfp-5 is right):

--- edid-dfp-3-dec.txt  2016-11-20 00:49:11.183700972 +0200
+++ edid-dfp-5-dec.txt  2016-11-20 00:48:56.570174709 +0200
@@ -1,18 +1,18 @@
-$ edid-decode < edid-dfp-3.bin 
+$ edid-decode < edid-dfp-5.bin  
 Extracted contents:
 header:          00 ff ff ff ff ff ff 00
 serial number:   10 ac b6 40 53 38 35 38 1d 1a
 version:         01 04
 basic params:    b5 3c 22 78 3a
 chroma info:     72 25 ac 50 33 b7 26 0b 50 54
-established:     00 00 00
-standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
-descriptor 1:    9f 0b 50 a0 30 e0 0e 10 30 20 35 00 55 50 21 00 00 1a
+established:     21 08 00
+standard:        81 00 b3 00 d1 00 a9 40 81 80 d1 c0 01 01 01 01
+descriptor 1:    56 5e 00 a0 a0 a0 29 50 30 20 35 00 55 50 21 00 00 1a
 descriptor 2:    00 00 00 ff 00 33 44 38 46 38 36 37 4a 38 35 38 53 0a
 descriptor 3:    00 00 00 fc 00 44 45 4c 4c 20 55 50 32 37 31 35 4b 0a
 descriptor 4:    00 00 00 fd 00 1d 4b 1f b4 36 01 0a 20 20 20 20 20 20
-extensions:      01
-checksum:        a7
+extensions:      02
+checksum:        c4
 
 Manufacturer: DEL Model 40b6 Serial Number 943011923
 Made week 29 of 2016
@@ -26,24 +26,63 @@
 Supported color formats: RGB 4:4:4, YCrCb 4:4:4, YCrCb 4:2:2
 First detailed timing is preferred timing
 Established timings supported:
+  640x480@60Hz
+  800x600@60Hz
+  1024x768@60Hz
 Standard timings supported:
-Detailed mode: Clock 29.750 MHz, 597 mm x 336 mm
-                848  896  928 1008 hborder 0
-                480  483  488  494 vborder 0
+  1280x800@60Hz
+  1680x1050@60Hz
+  1920x1200@60Hz
+  1600x1200@60Hz
+  1280x1024@60Hz
+  1920x1080@60Hz
+Detailed mode: Clock 241.500 MHz, 597 mm x 336 mm
+               2560 2608 2640 2720 hborder 0
+               1440 1443 1448 1481 vborder 0
                +hsync -vsync 
 Serial number: 3D8F867J858S
 Monitor name: DELL
 Monitor ranges (bare limits): 29-75Hz V, 31-180kHz H, max dotclock 540MHz
-Has 1 extension blocks
-Checksum: 0xa7 (valid)
+Has 2 extension blocks
+Checksum: 0xc4 (valid)
+
+CEA extension block
+Extension version: 3
+8 bytes of CEA data
+  Audio data block
+    Linear PCM, max channels 2
+    Supported sample rates (kHz): 48 44.1 32
+    Supported sample sizes (bits): 24 20 16
+  Speaker allocation data block
+    Speaker map: FL/FR
+Underscans PC formats by default
+Basic audio support
+Supports YCbCr 4:4:4
+Supports YCbCr 4:2:2
+1 native detailed modes
+Detailed mode: Clock 533.250 MHz, 597 mm x 336 mm
+               3840 3920 3952 4000 hborder 0
+               2160 2214 2219 2222 vborder 0
+               -hsync -vsync 
+Detailed mode: Clock 241.500 MHz, 597 mm x 336 mm
+               2560 2608 2640 2720 hborder 0
+               1440 1443 1448 1481 vborder 0
+               +hsync -vsync 
+Checksum: 0x34 (valid)
+
 
 DisplayID extension block
 Extension version: 18
 Length 121, version 18, extension count 0
-tiled display block: capabilities 0x00000080
+tiled display block: capabilities 0x00000082
 num horizontal tiles 2, num vertical tiles 1
-tile location (0, 0)
+tile location (1, 0)
 tile dimensions (2560, 2880)
+Type 1 detailed timing: aspect: 16:9, Preferred  
+Detailed mode: Clock 533.240 MHz, 0 mm x 0 mm
+               3839 3886 3917 3998
+               2159 2161 2165 2220
+               +hsync -vsync
 Type 1 detailed timing: aspect: 16:9,  
 Detailed mode: Clock 238.240 MHz, 0 mm x 0 mm
                2559 2606 2637 2718
@@ -54,6 +93,9 @@
                2559 2606 2637 2718
                2879 2881 2890 2960
                +hsync -vsync
+VESA DMT timing block
 
 EDID block does NOT conform to EDID 1.3!
         Detailed block string not properly terminated
+EDID block does not conform at all!
+        Impossible extension block count

[defender110]

+1 for this. I have two GTX 1070 cards and a Dell UP2715K and the best resolution I can get is 2560x1440. :( I tried to get this working by enabling Base Mosaic and forcing both ports to 2560x2880 and putting them side-by-side on the same X screen. This didn’t work. The second display always comes up at something like 800x800.

The monitor only seems to take advantage of one of the ports so I’m stuck at 2560x1440. I can’t get any higher resolution to work at all.

I’ve tried plugging both DP cables into the same GPU and also in separate GPUs but the outcome is always the same.

I just spent over a grand on GPUs and I hope that NVIDIA can get this driver issue worked out.

I’m happy to help test any ideas.
nvidia-bug-report.log.gz (270 KB)

[defender110]

Update: so I was finally able to get pseudo 5120x2880 resolution by using xrandr like this:

xrandr --output GPU-0.DP-2 --mode 2560x2880
xrandr --output GPU-1.DP-2 --mode 2560x2880
xrandr --output GPU-1.DP-2 --right-of GPU-0.DP-2

There are still a few major issues, however:

Issue #1: Like @michael9999 mentioned, what I actually have is two 2560x2880 tiles, not a unified 5120x2880 desktop. This means that I can’t have a window that actually spans both desktops. I might be able to achieve this with xinerama (yuck) but that causes a host of other problems. Maybe there is a way to work around this with xrandr? I don’t know.

Issue #2: I get screen corruption issues when I create a new virtual desktop in i3 (window manager). The new desktop is filled with outdated pieces (like 17 minutes old) of other desktops and my root background picture. If I start a full-screen app on that new desktop, the corruption goes away. I’m guessing that this is a driver issue and an old image still in video RAM is being displayed.

Issue #3: Not necessarily a driver issue but the colors on this monitor look like total crap. Red looks like magenta.

[michael9999]

@defender110, If you can live without RANDR the Xinerama approach sort of works. My second post above has my xorg.conf attached. (you would need to adjust port names according to your setup)

Otherwise, two other workarounds come to mind (I’ve tried a lot of things while wrangling with this issue):

1. In kwin (KDE/Plasma’s WM/compositor) it is possible to make maximized windows span both “screens” (tiles) via WM’s scripts. (a script can be attached to the maximization event) Perhaps there is a similar way to do it in i3. (I’ve never used it but from what I’ve heard it is highly customizable)

2. Use Gnome’s WM, it seems to support RANDR 1.5’s concept of “monitors” (see my first post for details). This should resolve WM-related issues. Its upcoming version also promises support for Nvidia’s approach to Wayland: GNOME Lands Mainline NVIDIA Wayland Support Using EGLStreams - Phoronix

Neither of these workarounds resolve any issues for apps which talk directly to RANDR though. (many games are broken)

Re your issue #3, that’s odd, I do not have any issues with colors. Colors look perfectly fine on my monitor.

[ymukhin]

+1. Same problem with Quadro K1200 cards and Dell UP2715K monitors appearing as two tiles each. Nvidia, please fix this in the Linux blob and restore parity to macOS and Win drivers.

In i3 WM, there is an undocumented (but known to Google) feature called ‘fake-output’ that allows to stitch two tiles together. Give it a google and a try.

Force one i3 instance/workspace across multiple monitors - i3 FAQ

[defender110]

@ymukhin I gave fake-output a shot but i3bar gets really screwy and virtual screens didn’t work as expected.

The real solution is for NVIDIA to–like you say–fix this in the Linux blob driver. 5K is the future–let’s get this working!

[ymukhin]

This problem is solved in Xorg just above the driver abstraction level.

RandR 1.5 addressed the problem of composite screens with a concept of a ‘Monitor’ back in March-2015.

https://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt?id=randrproto-1.5.0

man xrandr does not document ‘Monitor’-related options yet; See

xrandr --help
...
  --listmonitors
  --listactivemonitors
  --setmonitor <name> {auto|<w>/<mmw>x<h>/<mmh>+<x>+<y>} {none|<output>,<output>,...}
  --delmonitor <name>

I have two K1200 cards and setup two Xorg ‘screens’ in my xorg.conf, then combine separate tiles of each UP2715K into a named ‘Monitor’ in my .xininitrc:

xrandr --screen 0 --output DP-5 --mode 2560x2880 --pos 0x0 --rotate right
xrandr --screen 0 --output DP-4 --mode 2560x2880 --pos 0x2560 --rotate right
xrandr --screen 0 --output DP-6 --mode 2560x2880 --pos 2880x2560 --rotate right
xrandr --screen 0 --output DP-7 --mode 2560x2880 --pos 2880x0 --rotate right
xrandr --screen 0 --setmonitor DellUP2715Kmws0 2880/340x5120/600+0+0 DP-4,DP-5
xrandr --screen 0 --setmonitor DellUP2715Kmws1 2880/340x5120/600+2880+0 DP-6,DP-7

xrandr --screen 1 --output DP-5 --mode 2560x2880 --pos 0x0 --rotate right
xrandr --screen 1 --output DP-4 --mode 2560x2880 --pos 0x2560 --rotate right
...
DISPLAY=:0.1 exec i3 &
DISPLAY=:0.0 exec i3

i3 WM implemented support for Randr 1.5 Nov-2016, it is not yet in current (8-Nov-2016) releases but is in the NEXT git branch. It works and is amazing. Base Mosaic doesn’t work for me in this setup so there are two independent xorg ‘screens’. NVIDIA?

Thanks and bravo to Jim Gettys and Keith Packard (RandR 1.5) and Michael Stapelberg (i3wm).

https://github.com/i3/i3/issues/1799

[michael9999]

@ymukhin, As I said in my original post, this is NOT A SOLUTION.
It is rather an odd use of RANDR extension to “solve” a problem it was NOT designed to solve.

RANDR is intended to allow users to perform operations on physically separate devices (resize, rotate, combine them etc.).

Name one use case for RANDR for two separate side-by-side tiles of one physical monitor. Why would you want to resize/rotate half of the monitor? And even if you would, why stop there then? Divide it up into 1000 pieces (for example) and let RANDR operate on them all separately.

And implementing this “solution” (RANDR 1.5 “monitors”) in window managers does not solve this problem for the myriad of applications which talk to RANDR directly (e.g. games) and do not implement this “solution” themselves.

To sum up, this “solution”:

• Introduces a whole new layer on top of RANDR concepts. (the concept of "monitors" which simply consist of combined "outputs")
• Requires that ALL applications which talk to RANDR implement "monitors" and use them the same way (in sync) to make sense. (but what if some application has a different idea of "monitors" than the WM? What then? Games and other full-screen apps want to change resolution of "outputs"/CRTCs, but "monitors" do not have a concept of resolution change, how are they supposed to deal with "monitors?" They have to deal with underlying outputs/CRTCs/tiles directly to do it. It is a mess! And without any upside.)
• To "solve" the problem of tiled monitors you tell this "solution" ONCE that "these two tiles are really one physical device" AND NEVER CHANGE THIS. Why on earth is RANDR machinery even needed for this??? The functionality of joining back ONE physical device separated at the data transport level into two does not belong in RANDR.

The only proper solution is to “join” back the tiles into one physical output at the driver level and expose that to X/RANDR (and to KMS for that matter) and never expose separate tiles to X/RANDR. It is ONE physical screen. The fact that the data stream that is needed to drive it is split into two streams/cables/connections (and only in one – although the “native” one – mode out of many supported) simply provides zero justification to present it to X/RANDR as “two outputs”, it serves no purpose and only causes problems.

Perhaps there are use cases for RANDR 1.5’s “monitors” (and implementing them in WMs) but solving “the problem of tiled monitors” is not it! (with all due respect to X developer Keith Packard who introduced “monitors”, solving tiled monitors via this is a misguided idea)

[michael9999]

Here is also some interesting info from DRM/Intel discussion concerning some sync problems on this monitor:
https://bugs.freedesktop.org/show_bug.cgi?id=97244#c3

Here is my theory: the monitor is one physical panel taking data from two DP inputs making a final composited image from both, side by side. It probably takes one output as a reference and tries to synchronize scanlines from the other. It also probably expects equal timings and particular frames sent at the same moment on both outputs.

[defender110]

Wow, thanks ymukhin—I’m so close now and hoping you can help me a little more.

Here’s where I’m at:

I am now running xrandr in my .xinitrc like this:

# Set modes on our outputs
xrandr --screen 0 --output GPU-0.DP-2 --mode 2560x2880 --pos 0x0
xrandr --screen 0 --output GPU-1.DP-2 --mode 2560x2880 --pos 2560x0

# Combine our two outputs into one big monitor
xrandr --screen 0 --setmonitor DellUP2715K 5120/600x2880/340+0+0 GPU-0.DP-2,GPU-1.DP-2 

# Start i3 window manager
DISPLAY=:0.0 exec i3

This results in the same old situation: i3 thinks each half of the Dell 5K is its own monitor and maximized windows only take up half the screen.

Here’s what xrandr shows:

[cjs@socotra ~]$ xrandr
Screen 0: minimum 8 x 8, current 5120 x 2880, maximum 32767 x 32767
GPU-0.DVI-D-0 connected (normal left inverted right x axis y axis)
   1600x1200     60.00 +
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   640x480       75.00    59.94  
GPU-0.HDMI-0 disconnected (normal left inverted right x axis y axis)
GPU-0.HDMI-1 disconnected (normal left inverted right x axis y axis)
GPU-0.DP-0 disconnected (normal left inverted right x axis y axis)
GPU-0.DP-1 disconnected (normal left inverted right x axis y axis)
GPU-0.DP-2 connected primary 2560x2880+0+0 (normal left inverted right x axis y axis) 600mm x 340mm
   848x480       59.74 +
   2560x2880     59.98*   29.99  
GPU-0.DP-3 disconnected (normal left inverted right x axis y axis)
GPU-1.DVI-D-0 disconnected (normal left inverted right x axis y axis)
GPU-1.HDMI-0 disconnected (normal left inverted right x axis y axis)
GPU-1.HDMI-1 disconnected (normal left inverted right x axis y axis)
GPU-1.DP-0 disconnected (normal left inverted right x axis y axis)
GPU-1.DP-1 disconnected (normal left inverted right x axis y axis)
GPU-1.DP-2 connected 2560x2880+2560+0 (normal left inverted right x axis y axis) 600mm x 340mm
   2560x1440     59.95 +
   3840x2160     60.00    60.00  
   2560x2880     59.98*   29.99  
   1920x1200     59.88  
   1920x1080     60.00  
   1680x1050     59.95  
   1600x1200     60.00  
   1280x1024     60.02  
   1280x800      59.81  
   1024x768      60.00  
   800x600       60.32  
   640x480       59.95    59.94  
GPU-1.DP-3 disconnected (normal left inverted right x axis y axis)

GPU-0.DP-2 and GPU-1.DP-2 are the two outputs going to the Dell 5K.

Here’s what xrandr --listactivemonitors shows:

Monitors: 1
 0: DellUP2715K 5120/600x2880/340+0+0  GPU-0.DP-2 GPU-1.DP-2

So it looks like there’s one Monitor with 5120x2880 resolution. What’s going on with i3 to not take advantage of it?

Here’s my /etc/X11/xorg.conf:

configuration file generated by nvidia-settings
# nvidia-settings:  version 375.26  (builduser@felix)  Fri Dec 16 13:16:44 CST 2016


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

Section "Files"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    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      "DELL UP2715K"
    HorizSync       31.0 - 180.0
    VertRefresh     29.0 - 75.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 1070"
    BusID          "PCI:1:0:0"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-5"
    Option         "metamodes" "GPU-9100e211-857c-8dc7-6952-59b4e8e2f516.GPU-0.DP-2: 2560x2880 +0+0, GPU-f88e2401-de1b-74c7-9f6f-a58de10b62f9.GPU-1.DP-2: 2560x2880 +2560+0"
    Option         "MultiGPU" "Off"
    Option         "SLI" "off"
    Option         "BaseMosaic" "on"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Would you post your Xorg.conf and relevant i3 config (and anything else) so I can check it out?

Thanks.

[defender110]

OK, I made a little progress. I realized that I wasn’t on the ‘next’ branch of i3, so I built that from source and now I am able to open windows that span the screen without the use of fake-outputs. So that’s cool!

However, many things like polybar and dmenu don’t recognize the full width so I’m not sure if this is really any better than using fake-outputs.

On a side note, I now have an awful flicker on the monitor that doesn’t go away after powering the system and monitor off. I even reverted to my original xorg.conf and xrandr settings and nothing changes. I wonder if I have a failing GPU.

[ymukhin]

Check version of RandR with

xrandr --version

also you need the latest i3wm from git. I used nvidia-settings to generate xorg.conf, but only because I have two cards and need two X ‘screens’. The only state you need to originate is a RandR 1.5 ‘monitor’, check with

xrandr --listmonitors

Looking at your .xinitrc, it looks like you are trying to combine outputs on two distinct GPUs. Use nvidia-settings to make sure that both outputs are on the same X ‘screen’. This should not be possible without some NVIDIA driver magic like Mosaic. Better, just use outputs from the same card for each UP2715K.

[ymukhin]

And the fun continues with Dell UP3218K 8k via 2x DisplayPort 1.3.

Hopefully top layers of X will start getting updated for RandR 1.5 sooner rather than later.

[defender110]

OK, that makes sense. What I was doing was splitting right-side and left-side video inputs across two GTX 1070 GPUs, thinking I would get better performance by using one GPU for each half of the screen. I went ahead and moved both inputs to the same GPU and disabled the Mosaic stuff. It may be in my head by I swear that it even seems a little faster now.

I also fixed (mostly) the flickering problem by enabling “Force Full Composition Pipeline”.

I’m sure you’re right–three years from now, most X apps will just “work” on these goofball multi-port monitors.

Thanks for your help!

[defender110]

While we’re on the subject, were you able to get this monitor working on your (non-X) Linux console? My machine boots up and I get a console but it’s low-res. If I start up X and then later exit X, the console never comes back and the monitor goes into sleep mode.

[ymukhin]

When I tried this setup several month ago I had the same experience that you describe: no firmware-boot; low-res vt during kirnel boot (with NVIDIA driver); no vt on exit from X, and split into two tiles displayes in X.
My current machine is based on Supermicro X11SAE-F, quadro K1200 x2 and I get the whole POST-firmware-boot sequence, low-res Linux virtual console on kernel boot and after exiting X. I am not sure which frame buffer driver the Arch Linux kernel is loading, but it works well (with only a little bit longer lag than I am used to after exiting X). When X does DPMS these UP2715K screens hang and don’t wake up on key press/mouse move, I force DPMS a second time with

xset dpms force off

then wait a moment and wake them up again with a key stoke, they always come up on the second try.

We have now outlined some useful info for those looking into to buy these displays. Dispite being on the market for a couple of years, there is very little on the web. These are great units, do require more patience and setup time than older monitors, most likely will not work out of the box, will require careful selection of most-up-to-date peices of kernel/dirvers/X, but experience is rewarding. I am most grateful to authors of RandR and i3wm for making this experience possible, before you can get a comparable setup with Apple hardware and macOS! I have not tried, but suspect that everything can be reproduced with amd cards (like firepro w4100 and xf86-video-ati driver).

[defender110]

Thanks, @ymuhkin. I will try to write something up about all of this and get it on the web. I’ve been working on a blog post as part of a broader look at moving from macOS to Linux–which I did recently, fifteen years after switching from Linux to the Mac. The screen is great and I’m generally very happy!

Are you saying that the xset dpms force off fixed your no-VT-on-exit problem?

In case anybody stumbles upon this and wonders what hardware I used in my setup, here’s what I have:

ASUS uATX X99-M WS motherboard
(qty 2) ASUS GeForce GTX 1070 8GB ROG STRIX OC Edition GPUs (only one currently in use)
Arch Linux
i3 (‘next’ branch)