| Summary: | Laptop screen freezes when external monitor is connected (not NVIDIA) | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Richard <kde.qls1m> |
| Component: | multi-screen | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | major | CC: | kde.qls1m, nate, xaver.hugl |
| Priority: | NOR | Keywords: | multiscreen |
| Version First Reported In: | 6.5.4 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Richard
2026-01-10 03:55:40 UTC
Please get a drm debug log of when you connect the monitor: https://invent.kde.org/plasma/kwin/-/wikis/Debugging/Debugging-DRM-issues (In reply to Zamundaaa from comment #1) > Please get a drm debug log of when you connect the monitor: > https://invent.kde.org/plasma/kwin/-/wikis/Debugging/Debugging-DRM-issues Please find log linked here - couldn't get it small enough to upload. https://mega.nz/file/e8AWQTZQ#MhHYpaajzUK2WElx5A92uOoayyw-xd4l4ZQFZSxibI8 Log started just before connecting the monitor to the dock's HDMI and ended just after the KDE message appears notifying the disconnection of the monitor. > [ 5398.987584] i915 0000:00:02.0: [drm:intel_dp_compute_link_config [i915]] Try DSC (fallback=no, joiner=no, force=no)
> [ 5398.987731] i915 0000:00:02.0: [drm:intel_dp_compute_config_limits [i915]] [ENCODER:288:DDI C (TC)/PHY TC1][CRTC:262:pipe C] DP link limits: pixel clock 529200 kHz DSC on max lanes 2 max rate 810000 max pipe_bpp 24 max link_bpp 14.0000
> [ 5398.987844] i915 0000:00:02.0: [drm:intel_dp_dsc_compute_config [i915]] No Valid pipe bpp for given mode ret = -22
> [ 5398.987966] i915 0000:00:02.0: [drm:intel_dp_compute_link_config [i915]] Try DSC (fallback=no, joiner=no, force=no)
> [ 5398.988070] i915 0000:00:02.0: [drm:intel_dp_compute_config_limits [i915]] [ENCODER:288:DDI C (TC)/PHY TC1][CRTC:262:pipe C] DP link limits: pixel clock 529200 kHz DSC on max lanes 2 max rate 810000 max pipe_bpp 24 max link_bpp 14.0000
> [ 5398.988173] i915 0000:00:02.0: [drm:intel_dp_dsc_compute_config [i915]] No Valid pipe bpp for given mode ret = -22
> [ 5398.988281] i915 0000:00:02.0: [drm:intel_modeset_pipe_config [i915]] [ENCODER:288:DDI C (TC)/PHY TC1] config failure: -22
That looks like the dock simply doesn't support the full resolution + refresh rate of that display.
Plasma 6.6 will have a timeout for giving up and disabling the screen instead of using the best mode, at which point you can manually reduce the resolution or refresh rate.
Ideally we'd be able to detect that and automatically downgrade the mode, but KMS still doesn't report any more information than "that doesn't work", so the timeout is the best we can do right now.
I still wonder why it takes that long for KWin to do these tests. It should take at most 24 tests with two displays and four crtcs, and with each test taking about 20ms (judging by your logs), the tests should be done after half a second. Without debug logging, it should be a lot faster than that still. (In reply to Zamundaaa from comment #3) > > [ 5398.987584] i915 0000:00:02.0: [drm:intel_dp_compute_link_config [i915]] Try DSC (fallback=no, joiner=no, force=no) > > [ 5398.987731] i915 0000:00:02.0: [drm:intel_dp_compute_config_limits [i915]] [ENCODER:288:DDI C (TC)/PHY TC1][CRTC:262:pipe C] DP link limits: pixel clock 529200 kHz DSC on max lanes 2 max rate 810000 max pipe_bpp 24 max link_bpp 14.0000 > > [ 5398.987844] i915 0000:00:02.0: [drm:intel_dp_dsc_compute_config [i915]] No Valid pipe bpp for given mode ret = -22 > > [ 5398.987966] i915 0000:00:02.0: [drm:intel_dp_compute_link_config [i915]] Try DSC (fallback=no, joiner=no, force=no) > > [ 5398.988070] i915 0000:00:02.0: [drm:intel_dp_compute_config_limits [i915]] [ENCODER:288:DDI C (TC)/PHY TC1][CRTC:262:pipe C] DP link limits: pixel clock 529200 kHz DSC on max lanes 2 max rate 810000 max pipe_bpp 24 max link_bpp 14.0000 > > [ 5398.988173] i915 0000:00:02.0: [drm:intel_dp_dsc_compute_config [i915]] No Valid pipe bpp for given mode ret = -22 > > [ 5398.988281] i915 0000:00:02.0: [drm:intel_modeset_pipe_config [i915]] [ENCODER:288:DDI C (TC)/PHY TC1] config failure: -22 > That looks like the dock simply doesn't support the full resolution + > refresh rate of that display. > > Plasma 6.6 will have a timeout for giving up and disabling the screen > instead of using the best mode, at which point you can manually reduce the > resolution or refresh rate. > Ideally we'd be able to detect that and automatically downgrade the mode, > but KMS still doesn't report any more information than "that doesn't work", > so the timeout is the best we can do right now. Thank you. It did actually work (albeit unreliably) a couple of updates ago. I believe at full res. The dock is happy in Windows but I guess it knows to limit the refresh rate. Is there any way to force it to try 60 Hz, for example, as a workaround until 6.6? Thanks again. If you wait for a while, it should eventually give up, and then you can configure it in display settings. If your laptop has an HDMI port, you could also plug it in there and reduce the refresh rate. (In reply to Zamundaaa from comment #6) > If you wait for a while, it should eventually give up, and then you can > configure it in display settings. > If your laptop has an HDMI port, you could also plug it in there and reduce > the refresh rate. (In reply to Zamundaaa from comment #6) > If you wait for a while, it should eventually give up, and then you can > configure it in display settings. > If your laptop has an HDMI port, you could also plug it in there and reduce > the refresh rate. That worked. I plugged it in and walked away for a bit and when I came back, the laptop screen was released and I was able to access the Display Configuration GUI to change the settings for the external monitor. It was already at 60 Hz (with no option to increase) and the HDR setting was disabled. I turned down the color bit rate and a few other bits that I'm afraid I didn't track, and the external monitor started working. It tentatively seems to work happily now regardless of settings EXCEPT that if I enable HDR it reverts to the behavior that caused me to submit this bug. That is odd since it appeared to be disabled to start with, but very acceptable. In all I now appear to have a functioning system. I defer to you the expert as to how to resolve this report. The initial behavior is not desirable given the long period of frozen screen, but it ultimately works. Many thanks for your assistance and contributing to this project! |