Created attachment 133917 [details]
kern.log (drm.debug=0xe)

Created attachment 133918 [details]
Xorg.0.log

Created attachment 133919 [details]
lsb_release

Created attachment 133920 [details]
Xorg.0.log

After applying the following patch, all three screens turn into black screens after I change the display mode from mirror mode to extended mode.
(Please refer to the attached Xorg.0.log)

hw/xfree86/drivers/modesetting/drmmode_display.c:
-xf86CrtcSetSizeRange(pScrn, 320, 200, mode_res->max_width, mode_res->max_height);
+xf86CrtcSetSizeRange(pScrn, 320, 200, INT16_MAX, INT16_MAX);

Created attachment 133921 [details]
kern.log

Created attachment 133922 [details]
Xorg.0.log

After applying the following patch, all three screens turn into black screens after I change the display mode from mirror mode to extended mode.
(Log: attached Xorg.0.log and kernel log (attachment 133921 [details]))

ubuntu-zesty/drivers/gpu/drm/i915/intel_display.c
@@ -16458,9 +16458,12 @@ int intel_modeset_init(struct drm_device *dev)
                dev->mode_config.max_width = 4096;
                dev->mode_config.max_height = 4096;
        } else {
-               dev->mode_config.max_width = 8192;
-               dev->mode_config.max_height = 8192;
+               dev->mode_config.max_width = 16384;
+               dev->mode_config.max_height = 16384;
        }

I don't know why the 8192 limit never has been raised. Maybe the hardware never adopted for higher resolutions. Anyway:

As soon as you try to configure your 11520x2160 desktop, you can find in the log:
    [    84.385] failed to add fb -22
-22 is invalid argument and that error comes from the kernel. You could boot your kernel with drm.debug=0x5e and may get more hints why it fails.

Created attachment 135996 [details] [review]
extend max buffer size for test.

just followed the error from drm.debug=0x5e and tried to force extend max buffer size returned by intel_fb_pitch_limit(), then 3 X 4K monitor works well then.

there are 2 commit b321803dfb and ac484963f9 touched this part, but not sure why it specify (8192 * cpp)? have some better way to extend the size ?

environment setting:
kernel 4.15.0-rc2 [1]
drm, mesa and xorg version: http://paste.ubuntu.com/26124071/

[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.15-rc2/

I would contact the authors of the commits.

refer to this patch:
https://patchwork.freedesktop.org/patch/124918/

It looks 8192 means 4K X 2, and 16384 means 4K X 4,
So, followed the rule, I submitted a patch to support max 16K.

https://patchwork.kernel.org/patch/10097883/

my patch is not acceptable, 
Refer to the last comment from Ville Syrjälä
 "
 Even if this would be correct (which it's not for most platforms at
 least, not quite sure about the very latest hardware), anyone doing
 this should at least do a cursory check of the relevant math in the
 driver to make seure we don't end up with integer overflows.
 "

This change is for https://bugs.freedesktop.org/show_bug.cgi?id=102508 , and the hardware configuration is

* 00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:591d] (rev 04)
* Dell Thunderbolt BME dock : http://www.dell.com/support/article/us/en/04/sln301105/dell-thunderbolt-dock--tb16--information-and-specifications?lang=en
* internal native monitor is 4K, another 2 4K monitors are plugged behind BME dock

This patch could let this setting work, but looks it not the correct way.
Not see the the relevant math in original code of commit b321803dfb and ac484963f9 .
Does someone know how the original value 8192 be calculated out?
So that the way might could be followed for this new change.

I'm not sure if this is the right place to report it, but:
I have a similar problem, I've tried to apply all the patches mentioned here - for i915 driver in the kernel, for modesetting driver in xorg-server and updated mesa to 17.3.0 which is supposed to be updated, but I'm still seeing some sort of corruption - without the patches, the screens would remain black, but with the patches I see something like this - https://bugs.freedesktop.org/attachment.cgi?id=135329 

Maybe I've missed some other necessary patch?

Created attachment 136168 [details]
dmesg -w with drm.debug=0x5e before patch

this is the dmesg which opened drm.debug=0x5e, the kernel was built from latest drm_intel commit 0dfa1cee

Created attachment 136169 [details]
dmesg -w with drm.debug=0x5e of only applied the change in comment 6

this is the dmesg which opened drm.debug=0x5e, the kernel was built from latest drm_intel commit 0dfa1cee plus the change of comment 6.

and this message was a hint:
[drm:intel_framebuffer_init [i915]] tiled pitch (46080) must be at most 32768

Created attachment 136170 [details]
dmesg -w with drm.debug=0x5e after my patch in comment 10

this is the dmesg which opened drm.debug=0x5e, the kernel was built from latest drm_intel commit 0dfa1cee plus my patch in comment 10.

In this case, one internal 4K monitor plus 2 external 4k monitors which be attached after dell docking works well.

btw, all my test are in X modesetting.

Created attachment 136189 [details]
dmesg -w with drm.debug=0xe of wayland in artful after patch

this is the dmesg which opened drm.debug=0xe, the kernel was built from latest drm_intel commit 0dfa1cee plus my patch in comment 10, which is the same kernel what comment 15 used, and also works well.

This test was done on Ubuntu Artful with waylan , I just enabled debug level 0xe because 0x5e seems too heavy message that make all screen stay in dark after I plugged 2nd 4K monitor on dock.

I am working on the this feature request.

First, we need to be able to lift the limit that comment #0 proposed. To do so, we need to make sure we never exceed the maximum stride supported by the display controllers used by all the active CRTCs. If we exceed one of them, we need to enable per-CRTC framebuffers. This is a good base for tear-free anyway, and will enable this feature for all vendors.

I got a naive version of the proper patch to work as expected. I will keep on working on it to improve the performance and make it work with rotated displays and all the other options. I will then work on making the enabling of this feature dynamic, so as not to negatively affect the performance in the general case.

Once this is done, I will work with a kernel engineer to work-around the maximum-stride limit by internally creating another buffer that would be a read-only view of the big buffer, but limited to the size of the crtc. This would be done through GTT pages reshuffling (like what is done for rotation). If all goes well, the performance loss should be ~0 for the tearing implementation.

The tear-free implementation will however still require blitting, but this is not blocking this bug so we'll not talk about it here.

I'll keep you up to date.

Here is the first version of the patchset: https://cgit.freedesktop.org/~mperes/xserver/log/?h=3x4k

This has 0 performance cost unless we need to enable the feature because we exceed the driver's limits (what happens on Intel HW for 3x4k). In this case, we start using a buffer per-crtc and blit to it whenever there are damages on the screen.

This is pretty much the optimal behaviour performance-wise in a composited environment (unless the kernel lifts the limits I was talking about in the last comment). However, in non-composited environments, we can further improve this by blitting the damages no more than once per frame (hoping for some of the damages to overlap). I will get to that next week.

Also happening next week is more testing, and verifying that this also works without glamor and with the other options of modesetting.

*** Bug 107840 has been marked as a duplicate of this bug. ***

I posted a patch series for -modesetting that fixes this issue, and also adds TearFree support: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/24

The patch series from Ville (https://patchwork.freedesktop.org/series/49663/) will however be what you are looking for, as it will not reduce the performance at all.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/45.