Created attachment 143642 [details] Xorg log Problem: when connecting two displays and starting X, both screens are just black with a static (not blinking) text cursor in the top left corner. With only one display (does not matter which one was disconnected) X starts normal after reboot. Restarting X after connecting/disconnecting a display does not change the behavior, the system has to be rebooted. d8a648cae347dcad29dc976a1970f503eb27febf is the first bad commit commit d8a648cae347dcad29dc976a1970f503eb27febf Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Feb 15 12:30:19 2019 +0000 drm/i915/fbdev: Actually configure untiled displays commit d179b88deb3bf6fed4991a31fd6f0f2cad21fab5 upstream. With this commit applied an additional line shows in /var/log/Xorg.0.log: [ 31.581] (EE) modeset(0): failed to set mode: Invalid argument Apart from this, the file is identical with or without the commit. No differences in dmesg.
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 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.