Bug 1558476

Summary: [xserver-1.20] modesettings driver fails to set mode, black screen
Product: [Fedora] Fedora Reporter: Olivier Fourdan <ofourdan>
Component: xorg-x11-serverAssignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 28CC: alexl, bskeggs, caillon+fedoraproject, jglisse, john.j5live, nicolas.cyril.schmitt, ofourdan, rhughes, rstrode, sandmann, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-05-22 13:39:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
lspci -vv
none
dmesg with drm.debug=0x16
none
Xorg.0.log
none
modetest output when failed (xorg modesettings)
none
modetest output when succeeded (weston modesettings)
none
portion of dmesg with drm.debug=0x16 for the failed modeset
none
use XRGB8888 instead of ARGB8888 none

Description Olivier Fourdan 2018-03-20 10:00:46 UTC 
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
Comment 1 Olivier Fourdan 2018-03-20 10:01:19 UTC 
Created attachment 1410357 [details]
lspci -vv
Comment 2 Olivier Fourdan 2018-03-20 10:01:49 UTC 
Created attachment 1410358 [details]
dmesg with drm.debug=0x16
Comment 3 Olivier Fourdan 2018-03-20 10:02:14 UTC 
Created attachment 1410359 [details]
Xorg.0.log
Comment 4 Olivier Fourdan 2018-03-20 10:03:47 UTC 
kernel is 4.16.0-0.rc5.git0.2.fc28.x86_64
Comment 5 Olivier Fourdan 2018-03-20 12:57:50 UTC 
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...
Comment 6 Olivier Fourdan 2018-03-20 13:24:03 UTC 
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
Comment 7 Olivier Fourdan 2018-03-20 17:18:10 UTC 
Created attachment 1410655 [details]
modetest output when failed (xorg modesettings)

The is the output of modetest after xorg failed to set the mode
Comment 8 Olivier Fourdan 2018-03-20 17:22:16 UTC 
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.
Comment 9 Olivier Fourdan 2018-03-21 08:16:28 UTC 
Created attachment 1411026 [details]
portion of dmesg with drm.debug=0x16 for the failed modeset

This is the diff of “before'n after”.
Comment 10 Olivier Fourdan 2018-03-21 10:37:49 UTC 
undef'ing “GBM_BO_WITH_MODIFIERS” in “drmmode_display.c” fixes the issue
Comment 11 Olivier Fourdan 2018-03-22 08:04:46 UTC 
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.
Comment 12 Olivier Fourdan 2018-03-22 09:03:02 UTC 
[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
Comment 13 Olivier Fourdan 2018-03-22 09:05:35 UTC 
Could this be “gbm_bo_get_format()” returning an unsupported format in “drmmode_bo_import()” ?
Comment 14 Olivier Fourdan 2018-03-22 09:29:53 UTC 
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...
Comment 15 Olivier Fourdan 2018-05-22 13:39:32 UTC 
Fixed in xorg-server-1.19.99.903 by commit ce7d5087c