Description of problem: Using Ajax's build of xserver 1.20 for Fedora 28 [1] with the modesettings driver on intel (haswell), the screen remains dark grey (as if it kept the current content), the cursor is visible only on the external display and nothing else shows up on screen even though the Xserver is running (as confirmed with xdpyinfo). Using xorg-server 1.19 worked fine with modesettings. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EFHF6XVFURXIDDYII6PH2HIMYEXBCILR/ Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.19.99.902-0.1.fc28.x86_64 How reproducible: 100% Steps to Reproduce: 1. Log on GNOME on Xorg wit hxserver 1.20 Actual results: Nothing shows up on screen, although both monitors are lit up, the mouse cursor moves but is only visible on the external monitor. Expected results: Desktop, clients, windows, etc. all show up on screen. Additional info: Looks like the modesettings driver fails to set the mode, as seen in Xorg.0.log: (EE) modeset(0): failed to set mode: Invalid argument
Created attachment 1410357 [details] lspci -vv
Created attachment 1410358 [details] dmesg with drm.debug=0x16
Created attachment 1410359 [details] Xorg.0.log
kernel is 4.16.0-0.rc5.git0.2.fc28.x86_64
A “git bisect” gives: c8c276c9569b3ca1e695682a5443f1b615c606bd is the first bad commit commit c8c276c9569b3ca1e695682a5443f1b615c606bd Author: Louis-Francis Ratté-Boulianne <lfrb> Date: Wed Feb 28 01:19:43 2018 +0000 glamor: Implement PixmapFromBuffers and BuffersFromPixmap It relies on GBM >= 17.1.0 where we can import BO with multiple planes and a format modifier (GBM_BO_IMPORT_FD_MODIFIER). v2: Properly free fds in Xwayland [Also add glamor_egl_ext.h to Makefile.am for distcheck's sake - ajax] Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb> Reviewed-by: Daniel Stone <daniels> Acked-by: Keith Packard <keithp> Reviewed-by: Adam Jackson <ajax> :100644 100644 f4534e30be40418d52459bdc35b504f101de0d19 773567b53d5df6d7f8f2d94bcefd43bd71247de4 M configure.ac :040000 040000 c0b6c60c7f495b364563a1c4bc2ab09a894d0226 631ddb5a8cd1df72577a082b9fb2b51c489bfe4f M glamor :040000 040000 e3c1ceb61a269c4672143f59d5dc149ce8ade721 033f6fbcc370ba076c2ca811ce67673368b0fa6f M hw :040000 040000 26e8d926cdd79d805a7850ee0c20c49f5e9de969 ac974d68896345c126304f5338c4f52abd83acfd M include ** but** it's somehow hard to qualify as “good” or “bad” the states “in between”, like when only one output is working and not the other, of when no cursor is visible whatsoever...
So if qualifying as “good” when both outputs work as expected and as “bad” when either one or more output is not properly set up, then the first bad commit is “atomic modesetting”: 9817c14f6a2ea5db44459659131c13f403716df1 is the first bad commit commit 9817c14f6a2ea5db44459659131c13f403716df1 Author: Louis-Francis Ratté-Boulianne <lfrb> Date: Wed Feb 28 01:19:39 2018 +0000 modesetting: Use atomic modesetting to configure output/CRTCs To make sure we also use the same primary plane and to avoid mixing uses of two APIs, it is better to always use the atomic modesetting API when possible. v2: Don't use mode_output->connector_id Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb> Reviewed-by: Daniel Stone <daniels> Acked-by: Keith Packard <keithp> Reviewed-by: Adam Jackson <ajax> :040000 040000 dfba03adac9b5e46a8da89db35fddab24be694af 9eacc2bd5f9c8f837112a08b413c3b84f2cd7ff0 M hw
Created attachment 1410655 [details] modetest output when failed (xorg modesettings) The is the output of modetest after xorg failed to set the mode
Created attachment 1410658 [details] modetest output when succeeded (weston modesettings) This is the output of modetest when weston succeeds to set the mode. The code for atomic modesettings is very similar between hw/xfree86/drivers/modesetting/drmmode_display.c (xserver) and libweston/compositor-drm.c (weston) so it might be interesting to compare. The setup (desired) layout is similar in both cases, but the output of modetest differs slightly.
Created attachment 1411026 [details] portion of dmesg with drm.debug=0x16 for the failed modeset This is the diff of “before'n after”.
undef'ing “GBM_BO_WITH_MODIFIERS” in “drmmode_display.c” fixes the issue
And https://cgit.freedesktop.org/xorg/xserver/commit/hw/xfree86/drivers/modesetting/drmmode_display.c?id=757e0ee dones't make any difference, it doesn't fix the issue.
[77461.775658] [drm:drm_mode_atomic_ioctl [drm]] checking 000000009bde385c [77461.775661] i915 0000:00:02.0: [drm] plane[28]: primary A [77461.775663] i915 0000:00:02.0: [drm] crtc=pipe A [77461.775665] i915 0000:00:02.0: [drm] fb=105 [77461.775667] i915 0000:00:02.0: [drm] allocated by = Xorg [77461.775668] i915 0000:00:02.0: [drm] refcount=2 [77461.775671] i915 0000:00:02.0: [drm] format=AR24 little-endian (0x34325241) [77461.775673] i915 0000:00:02.0: [drm] modifier=0x100000000000001 [77461.775674] i915 0000:00:02.0: [drm] size=3840x1200 [77461.775676] i915 0000:00:02.0: [drm] layers: [77461.775678] i915 0000:00:02.0: [drm] size[0]=3840x1200 [77461.775680] i915 0000:00:02.0: [drm] pitch[0]=15360 [77461.775681] i915 0000:00:02.0: [drm] offset[0]=0 [77461.775683] i915 0000:00:02.0: [drm] obj[0]:(null) [77461.775685] i915 0000:00:02.0: [drm] crtc-pos=3840x1200+0+0 [77461.775688] i915 0000:00:02.0: [drm] src-pos=3840.000000x1200.000000+0.000000+0.000000 [77461.775690] i915 0000:00:02.0: [drm] rotation=1 [77461.775691] i915 0000:00:02.0: [drm] crtc[37]: pipe A [77461.775693] i915 0000:00:02.0: [drm] enable=1 [77461.775694] i915 0000:00:02.0: [drm] active=1 [77461.775696] i915 0000:00:02.0: [drm] planes_changed=0 [77461.775697] i915 0000:00:02.0: [drm] mode_changed=0 [77461.775699] i915 0000:00:02.0: [drm] active_changed=0 [77461.775701] i915 0000:00:02.0: [drm] connectors_changed=0 [77461.775702] i915 0000:00:02.0: [drm] color_mgmt_changed=0 [77461.775703] i915 0000:00:02.0: [drm] plane_mask=1 [77461.775705] i915 0000:00:02.0: [drm] connector_mask=1 [77461.775707] i915 0000:00:02.0: [drm] encoder_mask=1 [77461.775710] i915 0000:00:02.0: [drm] mode: 0:"" 0 140100 1920 1980 2016 2092 1080 1083 1088 1116 0x0 0x9 [77461.775712] i915 0000:00:02.0: [drm] connector[59]: eDP-1 [77461.775713] i915 0000:00:02.0: [drm] crtc=pipe A [77461.775724] [drm:drm_atomic_check_only [drm]] checking 000000009bde385c [77461.775766] [drm:drm_atomic_check_only [drm]] Invalid pixel format AR24 little-endian (0x34325241) [77461.775782] [drm:drm_atomic_check_only [drm]] [PLANE:28:primary A] atomic core check failed
Could this be “gbm_bo_get_format()” returning an unsupported format in “drmmode_bo_import()” ?
Created attachment 1411648 [details] use XRGB8888 instead of ARGB8888 So, another interesting finding, uisng the format GBM_FORMAT_XRGB8888 instead of GBM_FORMAT_ARGB8888 in drmmode_create_bo() fixes the issue...
Fixed in xorg-server-1.19.99.903 by commit ce7d5087c