Created attachment 142408 [details] dmesg with drm.debug=0x106 set and plugging in the dock Seems to happen quite reliably with my setup, but not necessarily reproducable with different hardware components. i.e. different laptop, almost identical kernel seemed fine: * X1 Carbon 4th Gen * Lenovo OneLink+ dock * 1x DELL 1920x1080 external screen * 1x DELL U2515H (2560x1440) external screen The U2515H stayed blank but GNOME (wayland) thought it was there. Attaching dmesg output with drm.debug=0x106 set. Kernel 4.18.16-300.fc29.x86_64 seems to behave better in this regard. Kernel was drm-tip, latest commit: commit 9ef57c71386778d8425b4884252f1919184645a1 (HEAD, drm-tip/drm-tip) Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Oct 19 12:25:58 2018 +0100 drm-tip: 2018y-10m-19d-11h-24m-46s UTC integration manifest
How often you can reproduce this issue? Can you verify this issue with latest drm-tip? (https://cgit.freedesktop.org/drm-tip). If problem exists with latest drm-tip, attach the full dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M.
No obvious errors visible in the log, by the end of the sequence eDP, DP-3 and DP-4 active. U2515H is on DP-4. Are you sure the display server is using the right connector? Is that display always off? If not could you also send a (full, and with drm.debug=0x1e as Lakshmi asked) log when it works correctly? (For instance does it work with a framebuffer console?) Thanks.
Could be same as https://bugs.freedesktop.org/show_bug.cgi?id=106250, which is yet still fixed only on my machine ;) This latter one was ddx/xserver issue, mistakenly thinking that crtc hasn't changed and no modeset required. However in my case it was every second connection leaving external displays blank, the subsequent connection usually fixed the issue. I've fixed it in Xserver, which now works for me, however haven't yet pushed the changed for XServer. Can you try xrandr --output (your output name) --crtc (some number here). If that helps - then this is probably a duplicate of 106250.
I was not using an X server though. That said, it is true that it could also be an issue related to mutter mishandling CRTCs. The regression does seem to get triggered by a kernel update though. I believe the issue happened in 2/3 cases, I don't remember if I booted with the dock or not. I'll rebuild drm-tip and try to generate a log with drm.debug=0x1e.
Created attachment 142422 [details] journalctl with kernel and comments Alright, here a log, booting up with the dock attached and commenting on the actions I am doing (look for "benjamin" or "root" to see the comments). Note that I could not reproduce the issue while on the console.
(In reply to Benjamin Berg from comment #5) > Created attachment 142422 [details] > journalctl with kernel and comments > > Alright, here a log, booting up with the dock attached and commenting on the > actions I am doing (look for "benjamin" or "root" to see the comments). > > Note that I could not reproduce the issue while on the console. Can you try a fix from 106250? Does it help? We just need to understand, currently it looks like same bug.
Reporter any updates here?
Benjamin, do you still have this issue? Any update here?
No feedback from more than 2 months, closing as resolved works for me. Please re-open if issue persists with latest drm-tip https://cgit.freedesktop.org/drm-tip and send dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M? You can also try the fix from Bug 106250 and give the feedback if that doesn't help the issue.
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.