Bug 110030

Created attachment 143643 [details]
dmesg output

@Maarten, to me this issue is a duplicate of Bug 109806.

Likely, yes

Created attachment 143674 [details] [review]
test-patch

I try to understand what exactly changed here so I looked into the sources. I have found that the association between connectors and crtcs changes due to the patch mentioned above. With the attached test-patch X works again and the debugging output shows the exchange of crtc-pointers between the connectors:

[    2.878198] [drm:drm_setup_crtcs [drm_kms_helper]] NOT WORKING: CONN 4 - crtc: ffffa36ef4054f48
[    2.878201] [drm:drm_setup_crtcs [drm_kms_helper]] NOT WORKING: CONN 5 - crtc: ffffa36ef4054f00
[    2.878205] [drm:drm_setup_crtcs [drm_kms_helper]] WORKING:     CONN 4 - crtc: ffffa36ef4054f00
[    2.878207] [drm:drm_setup_crtcs [drm_kms_helper]] WORKING:     CONN 5 - crtc: ffffa36ef4054f48

In the duplicate bug you said:
> Not a bug in the kernel, xorg's modesetting driver needs to set all
> connectors/crtc's directly when using atomic. The legacy path disabled crtc
> B for you if you stole all its connectors for a different crtc. In the
> atomic case you need to disable it yourself.
> 
> This is a bug in x.org's modesetting driver.

Though it seems to me this is not related here as there are no stolen connectors involved. And the source of the modesetting-driver from xorg already has a part that disables crtcs without connection (see https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/drivers/modesetting/drmmode_display.c line 778)

So do you say the right path from here is to let the modesetting driver change the association between the connectors and crtcs?

The pointers are just locations in memory, any difference in timing can cause them to change. :)

The xorg-modesetting driver needs to do the setup in 1 atomic commit, and disable unused crtc's when stealing connectors from them.

(In reply to Maarten Lankhorst from comment #5)
> The pointers are just locations in memory, any difference in timing can
> cause them to change. :)

I know what pointers are. ;) The point is that the call to 'drm_pick_crtcs' switched the associated crtcs between the outputs (look at the test-patch, the addresses are from the same run; once before, once after call to the function). And with this call added, X starts as expected.

drm_pick_crtcs looks hard to find the best match between connector and crtc while intel_fb_initial_config just uses the first crtc that has a matching mode.

So without understanding what all this stuff is, I come to the conclusion that the right association between connector and crtc is essential.
If the kernel now does not try its best to find this right association, the modesetting driver has to do it. I have looked at the code, tried some changes but with no success. It is just to complex for me to understand enough to fix this myself. :/

I have the same problem, but this time it is not related to a dual monitor configuration.

On my Pentium N3710 based notebook the X server does not start anymore too.
I made some investigations, and i guess its because after the patch another crtcs is choosen for the desired mode.

Before the patch intel_fb_initial_config always returned false, and drm_setup_crtcs is choosing crtc 46:pipe A which is fine for the X server.
[drm:intel_fb_initial_config [i915]] Not using firmware configuration
[drm:drm_setup_crtcs [drm_kms_helper]] looking for cmdline mode on connector 91
[drm:drm_setup_crtcs [drm_kms_helper]] looking for preferred mode on connector 91 0
[drm:drm_setup_crtcs [drm_kms_helper]] found mode 1366x768
[drm:drm_setup_crtcs [drm_kms_helper]] picking CRTCs for 8192x8192 config
[drm:drm_setup_crtcs [drm_kms_helper]] desired mode 1366x768 set on crtc 46 (0,0)

Now intel_fb_initial_config is returning true, but is choosing crtc 63 instead, and with crtc 63 the X server doesn't come up
[drm:intel_fb_initial_config [i915]] looking for cmdline mode on connector eDP-1
[drm:intel_fb_initial_config [i915]] looking for preferred mode on connector eDP-1 0
[drm:intel_fb_initial_config [i915]] connector eDP-1 on [CRTC:63:pipe B]: 1366x768
[drm:intel_fb_initial_config [i915]] connector DP-1 not enabled, skipping
[drm:intel_fb_initial_config [i915]] connector HDMI-A-1 not enabled, skipping
[drm:intel_fb_initial_config [i915]] connector DP-2 not enabled, skipping
[drm:intel_fb_initial_config [i915]] connector HDMI-A-2 not enabled, skipping
[drm:drm_setup_crtcs [drm_kms_helper]] desired mode 1366x768 set on crtc 63 (0,0)

So probably the patch itself is correct, but it breaks a previously running system, and i do not see any progress in the X server about an atomic commit.
There was some initial work according to
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/36/commits
but the patches are pending for almost half year.

@Manuel, if this is a duplicate of Bug 109806 or  https://gitlab.freedesktop.org/xorg/xserver/issues/542 I can close this bug.

As you said, it is very likely.

Closing this as duplicate of Bug 109806.
Please reopen this issue if you disagree.

*** This bug has been marked as a duplicate of bug 109806 ***