Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
Equinix is shutting down its operations with us on April 30, 2025. They have graciously supported us for almost 5 years, but all good things come to an end. We are expecting to transition to new infrastructure between late March and mid-April. We do not yet have a firm timeline for this, but it will involve (probably multiple) periods of downtime as we move our services whilst also changing them to be faster and more responsive. Any updates will be posted in freedesktop/freedesktop#2011 as it becomes clear, and any downtime will be announced with further broadcast messages.
Project 'drm/intel' was moved to 'drm/i915/kernel'. Please update any links and bookmarks that may still have the old path.
monitor connected via Displayport not detected anymore (kernel 5.11 -> 5.12)
I have Fedora 33 running, and with the Fedore kernel update from 5.11
series to 5.12 my external monitor is not detected anymore. Same is
true with the Fedora supplied 5.13 kernel version.
Hardware in use:
ThinkPad X1 Yoga 4th / Carbon 7th
Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
The Thinkpad is connected to a ThinkPad Thunderbolt 3 Dock with a
Thunderbolt cable and a monitor (Eizo EV3285) is connected via
Displayport to the docking station.
So I tried with vanilla kernel 5.11 and latest git head from Linus'
tree. 5.11 works while latest git head does not. I could bisect that
down to kernel commit
ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
With that commit the problem occurs one commit previous to that one the monitor is still detected.
I also reported that on mailing list(s) with developers on "To:"
vs.
Aug 20 13:13:03 kernel: [drm:drm_dp_send_link_address [drm_kms_helper]] link address reply: 0
Looks like the old dbuf hacks triggered an extra modeset quite early during the driver initialization, which somehow causes the display to work correctly. Without that spurious modeset the display starts to misbehave. Very strange.
Looks like the old dbuf hacks triggered an extra modeset quite early during the driver initialization, which somehow causes the display to work correctly. Without that spurious modeset the display starts to misbehave. Very strange.
Any idea how to proceed with this? DP is the only way I can connect my monitor to the Thinkpad with 4k@60Hz. Using HDMI is limited to 30Hz; so it is close to unusable.
@vsyrjala So did you check that adding this distrust_bios_wm which triggers the modeset helps here? I was wondering if we could just make a patch putting this back, at least to check if thats the case. I.e we will force a modeset whenever distrust_bios_wm is set, as I understood it was supposed to force a full DDB recalculation, however now we don't need that with the new Dbuf state handling.
Another hint is that it could be once again some MST issue with particular display, @heiko you might want to try it in non mst mode. Sometimes it is
possible to switch your display to non-mst(sst) from its menu.
Or you can add i915.enable_dp_mst=0 to kernel command line.
If that helps, that would be mean there is some issue related to DP MST protocols.
distrust_bios_wm was just a hack. Nothing to do with anything here really. The fact that it ended up doing a modeset that somehow makes the display behave better was just an accident. So if we wanted to restore the old behaviour we'd just force a modeset, but that goes agains the whole fastboot stuff which people like to have.
One thing I have been pondering occasionally is out SST->MST transition. Currently we just switch the mode during detection if everything is MST capable. But at that point the SST stream may still be active. So perhaps we should be more careful and only switch to MST mode once SST has been terminated. But I suspect actually implementing something like that isn't going to be fun.
@vsyrjala Yes, I don't think we need to put that hack back, idea was just to check if it helps. But I guess you've done that already.
Would be nice also if @heiko tries without MST mode, as I suggested above.
If it helps, then at least we would know for sure, that the problem is MST related.
So I can confirm that with fastboot=0 the display is detected again on commit ef79d62b5ce5, which broke things for me. Removing the parameter again breaks things again.
However the odd thing is that with Fedora 34 current kernel 5.13.14 it doesn't make the problem go away. So I'm wondering what kernel version should I test? I can try latest upstream kernel from Linus, since we are close to -rc1 if you want and if you think that would help? (note I didn't do that now, since compiling the kernel takes ages due to rather slow laptop, but if it helps there is no problem in doing that).
Should I try anything else?
@stanislav.lisovskiy So I tried a bit more, and after a system upgrade things are very unreliable - it is not predictable anymore if the display works or not.
That being said: with "i915.enable_dp_mst=0" the display is detected always until now - even with Fedora 34 kernel version 5.13.14. So it looks like this parameter makes the problem disappear.
@heiko This confirms then that the problem is MST related. There is some issue which was previously hidden by that modeset during boot. You could then use the display in SST mode or use fastboot option, because probably it might take time before we figure out the proper fix for the MST.