DisplayPort MST issues on i915

SkyBeam · 2025-12-18 10:23:36

I am using an HP ProBook 440 G5 with Intel Core i5-8250U CPU on an HP Ultraslim Docking Station with a display-port attached AOC AG324u display and recently noticed an issue.

As soon as I connect any screen to one of the DisplayPort outputs on the Ultraslim dock (yes, latest DP firmware 2.33 installed) I noticed quite extreme boot delays. This manifests in:

Analyzing boot using systemd-analyze plot also shows the system suddenly spends about 5 seconds only in systemd-backlight@backlight:intel_backlight.service
Loading of SDDM is delayed by about 15 seconds where the systems sits on text console apparently doing nothing
After password authentication a black screen is displayed for another 10-15 seconds before the system is logging on the user normally

Also when undocking and re-docking the system might freeze up for 10-20 seconds before displaying a toast message that another screen is attached.

What I tried:

Masking systemd-backlight service: Did speed up boot but did not fix delay loading SDDM or logon as well as freezes when re-docking
Disabling kms adding i915.modeset=0: Working and all delays are gone. However I cannot use any of the Display-Ports, no screens are detected.
Disabling DisplayPort via kernel option "video=DP-4:d": Working fine but I cannot use the external screen, not even after logging in. KDE/Wayland simply not showing any DP-attached screen.
Tinkering with i915 kernel module parameters. Finally adding i915.enable_dp_mst=0 fixed the boot delays and still allowing me to use external screens (but with reduced bandwidth).

I am unsure if this is an Arch issue or potential bug in i915 kernel module. I was unable to figure out properly why the system is freezing when an MST-attached screen is connected as I was unable to get any meaningful errors neither from logs nor dmesg. The system just freezing up. At this point I suspect some bug in i915 handling for DisplayPort Multi Stream Transport (MST). Some references on internet show similar issues with MST-enabled screens (usually daisy-chained display-port screens) where the recommendation is also to directly attach the screens with a dedicated cable with no real solution to the problem.
Of course I don't know if this is some sort of hardware limitation but if it is I am asking myself why MST is enabled by default on this hardware. Strange enough MST seems also to work. When connected to the dock I am getting 4 display ports (DP-1, DP-2, DP-3, DP-4) while DP 3+4 are connected to the two DisplayPort connectors on the Docking Station. I am also able to configure resolutions like 3840x2160@75Hz on the screen. When disabling MST I am limited to 3840x2160@60Hz (and potentially it will be impossible to connect a second screen, this I did not test yet).

So it looks to me like DisplayPort MST is causing some issues but due to the fact it's actually working despite those "freezes" I am wondering what is causing those and why it only happens during backlight service initialization as well as when SDDM or user-session is loaded or the screen is re-plugged as it seems to work fine during normal operation. It's just very annoying to wait for those "timeouts" as the laptop boots to desktop in 15 seconds until docked where it takes me more than a minute mostly waiting in front of black/frozen screen. The "disable MST" workaround might help someone but is not an option if you need MST (multiple screens attached to the dock or daisy-chained screens).

Virus1x · 2025-12-18 10:29:09

Okay, so your DP MST setup is lagging like crazy. Turning off MST fixes it, but then you can't use multiple high-refresh rate screens, which sucks.

SkyBeam · 2025-12-18 10:40:36

Virus1x wrote:

Okay, so your DP MST setup is lagging like crazy. Turning off MST fixes it, but then you can't use multiple high-refresh rate screens, which sucks.

Weird part is that it only lags on boot (perhaps backlight service, SDDM and wayland during init cause to trigger it) but when logged on it works normally. That is unless undock/dock events or re-plug of a screen happens when it "freezes up" again.

I don't know currently how to debug this further but some online research show that I don't seem to be the only one with this problem using MST feature. Also lots of reports in regards to hybrid graphics (optimus). My best guess is a bug in either i915 module or the kernel itself triggered by some code in backligt service and during DM initialization.

Sure MST setups are not that common and as of my knowledge also DVI/HDMI does not support MST. It's a DisplayPort thing and although very handy feature it might not be very widespread in use. Daisy-Chaining multiple screens with a single cable is a nice feature though but there only a few screens on the market which do not only have DisplayPort in but also DisplayPort out for daisy chaining. I just learned that the HP UltraSlim Dock (and potentially other docking solutions) use DisplayPort MST to provide multiple DisplayPort outs (which absolutely makes sense). Also using USB-C docks with multiple external screens are likely affected. There are also a bunch of 4K/HiDPI screens which use MST to provide high refresh rates on a single cable while each stream is driving half of the screen (as opposed to feature 2 physical input ports).

I also tried connecting my screen via DP->HDMI adapter but this is quite unusable as only 3860x2140@30Hz is supported which leads to terrible user experience. So DisplayPort is a must.
My workaround disabling MST leaving me with 2 restrictions: I can only use 60Hz instead of 75Hz and I can use only a single screen. I can live with both limitations as of now so I will keep MST disabled. But still wondering if this is a bug in MST code which could potentially affect other users and of course it would be great if it can be fixed.

seth · 2025-12-22 21:07:39

Does it help to dump the monitors EDIDs (you can jsut copy the file from /sys/class/drm/card*/edid and inject it into the system so it doesn't have to be queried during the boot?
https://wiki.archlinux.org/title/Kernel … s_and_EDID ?

The dock might just be slow to wake up?

SkyBeam · 2025-12-23 14:18:26

seth wrote:

Does it help to dump the monitors EDIDs?
...
The dock might just be slow to wake up?

Thanks for your valuable input. I did actually read this exact page before and decided not to go down the rabbit hole of creating my own EDID as I knew the EDID presented by the screen are fine (used lots of CRU-editing on Windows before).
Nevertheless after your input I decided to dig into it to understand and follow the process. So I did...

sudo cp /sys/class/drm/card1-DP-3/edid /usr/lib/firmware/edid/ag324ux.bin
Add "drm.edid_firmware=DP-3:edid/ag324ux.bin" to my kernel boot options

I did then of course remove the "i915.enable_dp_mst=0" argument.

So to my surprise the system did not pause on loading "systemd-backlight@backlight:intel_backlight.service" and SDDM loaded more quickly. Though it did not feel as quick as with the "i915.enable_dp_mst=0" argument.
Then I checked my screen configuration and found to be limited to 60Hz but realized this is expected as I dumped the EDID while MST was disabled and 60Hz was maximum.

Then I went ahead and booted again with MST enabled and no manual EDID override (with all the painful delays) just to dump the EDID again ("sudo cp /sys/class/drm/card1-DP-3/edid /usr/lib/firmware/edid/ag324ux.bin").
This time after loading the re-built EDID I was also presented the 75Hz option. So this also confirmed I did the EDID dump and kernel arguments correctly. Then I thought the problem might be solved... but...

Now I somehow felt the startup was still slower and started to switch between static EDID mode ("drm.edid_firmware=DP-3:edid/ag324ux.bin,DP-4:edid/ag324ux.bin") and MST disabled (i915.enable_dp_mst=0) options and found

Static EDID somehow resolve the boot delay when loading systemd-backlight@backlight:intel_backlight.service. Though this might be just because the delay is shorter and due to parallel service startup it does not delay the boot process enough to be noticeable.
There is still some delay of about 6-10 seconds black-screen before SDDM is loaded and after entering the password until KDE is loaded. Roughly I see 3 seconds of black screen with white cursor on top left and then the backlight goes off for about 3-5 seconds before the login screen is displayed. Same delay repeats after entering the password before I see the KDE loading screen.
Static EDID is quite a bad solution when using docking-station and therefore changing workplaces with different screens.

So while I confirm the boot delays got much shorter there is still a significant difference in boot delays when disabling MST entirely versus overriding EDID only.
I did go some extra mile testing also what happens when I load static EDID on all my screens. So I loaded the ag324ux.bin for DP-1, DP-2, DP-3, DP-4, DP-5, HDMI-A-1, HDMI-A-2 as these are all the available display connectors. I also tried to load a static EDID for my internal EliteBook 850 G5 screen by dumping its EDID and loading it statically for eDP-1 port. As well as I tried to boot once just loading ag324ux.bin for all screens which left me with an unusable internal screen of course. But none of those attempts did resolve the delay entirely.

Then I tried to combine the methods and used the following kernel options:

i915.enable_dp_mst=0 drm.edid_firmware=DP-2:edid/ag324ux.bin

Note: DP-2 is the display port the screen is connected to if no MST is enabled.
This entirely resolved the boot delays as well (as expected by disabling MST) and also enabled me to use 75Hz for the screen even without MST enabled.

To summarize:

Loading manual EDID does not entirely resolve the delays
When MST is disabled somehow the driver does not properly read some of the EDID parameters (ie does not provide 75Hz option even if DP bandwidth would allow it)
Static EDID is a bad choice for docking stations and changing screen configurations

So I am back to square one. Disabling MST is the only way to fix the i915 issue with MST attached screens. I can manually inject the missing 75Hz mode by overriding EDID in MST-disabled mode. Unfortunately this comes at a heavy impact when changing between docking stations and screen configurations. I cannot imagine to use this in business environments where I need to switch between different workplaces randomly. Not a big deal though as 60Hz is usable. So being able to use 75Hz would be a nice bonus but not a must. The boot delays (which are partially still existing when overriding EDID) are however very annoying indeed.

Last edited by SkyBeam (2025-12-23 19:01:38)

seth · 2025-12-23 16:44:32

* Static EDID somehow resolve the boot delay when loading systemd-backlight@backlight:intel_backlight.service. Though this might be just because the delay is shorter and due to parallel service startup it does not delay the boot process enough to be noticeable.
* There is still some delay of about 6-10 seconds black-screen before SDDM is loaded and after entering the password until KDE is loaded. Roughly I see 3 seconds of black screen with white cursor on top left and then the backlight goes off for about 3-5 seconds before the login screen is displayed. Same delay repeats after entering the password before I see the KDE loading screen.

seth wrote:

The dock might just be slow to wake up?

Cheating in the EDID means that the backlight service doesn't have to wait for the monitor to actually respond, but of course you cannot see anything until it's physically really ready.
You might be able to avoid the second delay (when starting the session) by using https://wiki.archlinux.org/title/SDDM#Wayland

Doesn't though address

Static EDID is quite a bad solution when using docking-station and therefore changing workplaces with different screens.[/*¯

Does it matter what output at the dock you attach the monitor to?
Are there traces of i915 waiting for MST outputs to respond in the system journal?

SkyBeam · 2025-12-23 19:46:39

Thank you for the good suggestions and continued help.

seth wrote:

Cheating in the EDID means that the backlight service doesn't have to wait for the monitor to actually respond, but of course you cannot see anything unti0l it's physically really ready.
You might be able to avoid the second delay (when starting the session) by using https://wiki.archlinux.org/title/SDDM#Wayland

I did try that and did what is described in "2.12.1 KDE Plasma / KWin" configuring DisplayServer=wayland and CompositorCommand. The results were "interesting" at least.

The boot procedure of course was unaffected. I was using hard-coded EDID ans did not disable MST for testing
When SDDM is loaded I could still see about 3 seconds where I just see the "_" cursor on top left of the screen with no apparent system activity
Then the screen instead of turning black for another 3-6 seconds as before it is immediately showing the cursor on black background. But it will take another 3-10 seconds displaying ontly the cursor before the login mask is showing up
After logging instead of going black-screen I can see some systemd console output for 3-5 seconds before KDE loads. The overall delay is not improved here; just seeing some output while waiting.

seth wrote:

Doesn't though address
Static EDID is quite a bad solution when using docking-station and therefore changing workplaces with different screens.

This is perhaps the biggest issue. Hard-coding EDID is quite a bad workaround for non-desktop computers.

seth wrote:

Does it matter what output at the dock you attach the monitor to?

No. Tried both DP outputs. The dock has 2x DP + 1x VGA (no, not going to try this one ?).

seth wrote:

Are there traces of i915 waiting for MST outputs to respond in the system journal?

Here's an output of all i915 related journal lines during boot:

kernel: i915 0000:00:02.0: [drm] Found kabylake (device ID 5917) integrated display version 9.00 stepping C0
kernel: i915 0000:00:02.0: vgaarb: deactivate vga console
kernel: i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=io+mem
kernel: i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_ops [i915])
kernel: i915 0000:00:02.0: [drm] Registered 3 planes with drm panic
kernel: [drm] Initialized i915 1.6.0 for 0000:00:02.0 on minor 1
kernel: fbcon: i915drmfb (fb0) is primary device
kernel: snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [i915])
kernel: i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
kernel: i915 0000:00:02.0: [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.

Nothing which immediately rings a bell to me. The last line (framebuffer size) indicates I need to increase the framebuffer which I did by changing from 32MB to 64MB. This however did nothing in regards to the initialization delays but removed this message.

DRM/HDCP might be a cause for delays too. I tried also to remove the i915/kbl_dmc_ver1_04.bin temporary but that did not change anything despite the driver to claim it disabled power management.

None of this changes (memory increase, skipping firmware) had any impact on the huge delay when MST is enabled.

So still to me it looks like manually disabling MST is the best and most practical option.

seth · 2025-12-23 23:18:30

When SDDM is loaded I could still see about 3 seconds where I just see the "_" cursor on top left of the screen with no apparent system activity
Then the screen instead of turning black for another 3-6 seconds as before it is immediately showing the cursor on black background. But it will take another 3-10 seconds displaying ontly the cursor before the login mask is showing up
After logging instead of going black-screen I can see some systemd console output for 3-5 seconds before KDE loads. The overall delay is not improved here; just seeing some output while waiting.

So the output is actually active at this time?

If you enable MST, remove the edid but use https://www.kernel.org/doc/Documentation/fb/modedb.rst to force 60Hz, do you still have any of the lags?
Can you check in the motitor OSD whether it actually receives a 75Hz signal w/ the slow MST configuration?

SkyBeam · 2025-12-23 23:57:42

seth wrote:

So the output is actually active at this time?

I did get output in every configuration. Never reported any issue getting output. Just the delays as well as missing 75Hz Mode (the screen can actually do 4K@144 but the laptop is limited to 4K@75Hz). In all configurations I can get the 4K screen and the laptop screen output.

seth wrote:

If you enable MST, remove the edid but use https://www.kernel.org/doc/Documentation/fb/modedb.rst to force 60Hz, do you still have any of the lags?

I didn't mention this in the initial post but I did use video= kernel arguments as one of the first things to try at no avail before I went to i915 module configuration.
I tried video=3840x2160@60 (with MST not disabled) as well as different modes for the screens like video=eDP-1:1920x1080@120,DP-3:3840x2160@60.
I also experimented with reduced blanking options but this would be meaningful only if operating at the limit of the DP bandwidth and not if limited to 60Hz.
Findings there is that as long as MST is enabled 60Hz is used in SDDM but after logging on and loading KDE the screen is detected as 3840x2160@75Hz regardless of the video= options.

Also all the delays are there and I am waiting an additional minute for the system to be ready on the desktop starring at black screens when backligt service loads, when SDDM loads and when KDE loads.

seth wrote:

Can you check in the motitor OSD whether it actually receives a 75Hz signal w/ the slow MST configuration?

The refresh rates are exactly as reported by the system:

MST enabled: 4K@75Hz and FHD@120Hz for the internal screen. Just as detected and reported by KDE screen configuration and kscreen-doctor. Very long initialization delays.
MST enabled, video= arguments: Video Arguments only used until KDE loads (4K@60Hz during boot and SDDM, 4K@75Hz after KDE load. Very long initialization delays.
MST enabled, static EDID: 4K@60Hz/4K@75Hz depending on EDID configuration loaded. ~6 seconds delay loading SDDM, ~6-10 seconds delay loading KDE. Solution unsuitable for dynamic monitors.
MST disabled: 4K@60Hz detected and confirmed by screen. No delays.
MST disabled, custom EDID: 4K@75 configured and confirmed by screen. No delays. Unsuitable for dynamic monitor configurations.

So yes, the screen is confirming the refresh rates.
My main PC connected to the screen is occupying the DisplayPort input so the laptop is connected via DP->USB-C adapter cable but I have repeated the same tests also when using the primary full-size DisplayPort connector directly. As well as I tried to enable/disable AdaptiveSync on the screen which did not make any difference in any of those scenarios. To me it really looks like there is a serious problem with the i915 MST handling.

seth · 2025-12-24 16:29:35

I did get output in every configuration. Never reported any issue getting output. Just the delays

I meant "output during the delay" - I had hoped the delay is b/c the system tries and fails to get a 75Hz mode until it gives up and resorts to 60Hz

SkyBeam · 2025-12-25 10:43:36

seth wrote:

I meant "output during the delay" - I had hoped the delay is b/c the system tries and fails to get a 75Hz mode until it gives up and resorts to 60Hz

Oh okay. Well, during SDDM and KDE load there is a delay of about 3 seconds where I can seee the white "_" cursor on top left of the screen and then another 3-6 seconds delay where the screen is really black (backlight off) before the login screen returns. So I see your suspicion might be right but actually it goes exactly to the mode I'd expect. So I can't see any fallback mechanisms to kick in.
I still think it might be some issue in the i915 driver or hardware MST implementation.

Thanks again for your help.

Arch Linux

#1 2025-12-18 10:23:36

DisplayPort MST issues on i915

#2 2025-12-18 10:29:09

Re: DisplayPort MST issues on i915

#3 2025-12-18 10:40:36

Re: DisplayPort MST issues on i915

#4 2025-12-22 21:07:39

Re: DisplayPort MST issues on i915

#5 2025-12-23 14:18:26

Re: DisplayPort MST issues on i915

#6 2025-12-23 16:44:32

Re: DisplayPort MST issues on i915

#7 2025-12-23 19:46:39

Re: DisplayPort MST issues on i915

#8 2025-12-23 23:18:30

Re: DisplayPort MST issues on i915

#9 2025-12-23 23:57:42

Re: DisplayPort MST issues on i915

#10 2025-12-24 16:29:35

Re: DisplayPort MST issues on i915

#11 2025-12-25 10:43:36

Re: DisplayPort MST issues on i915

Board footer