SUMMARY When connecting an external monitor, the monitor does not work and while connected, the laptop screen freezes until the monitor is unplugged, STEPS TO REPRODUCE 1. Unplug monitor from dock. 2. Plug in dock to laptop - (all peripherals work) 3. Plug in monitor to dock HDMI port - (laptop screen freezes, monitor does nothing) 4. Unplug monitor from HDMI port - (laptop screen unfreezes) Alternatively to 1 and 2, plug in dock with the monitor connected to the dock's HDMI port. OBSERVED RESULT When the dock is connected to my laptop with monitor unplugged, all the peripherals function correctly. As soon as the monitor is connected (HDMI) the laptop screen freezes and the external monitor does nothing. When monitor is unplugged, the screen unfreezes and any typing etc. happening during the freeze becomes visible, indicating that everything is working behind the frozen screen. EXPECTED RESULT When monitor is connected, or when dock is connected with monitor connected to it, the laptop screen should continue to update (while open) and the external monitor should show a second screen. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 43 KDE Plasma Version: 6.5.4 KDE Frameworks Version: 6.21.0 Qt Version: 6.10.1 Kernel Version: 6.18.3-200.fc43.x86_64 (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i5-1035G7 CPU @ 1.20GHz Memory: 8 GiB of RAM (7.3 GiB usable) Graphics Processor: Intel® Iris® Plus Graphics Manufacturer: Microsoft Corporation Product Name: Surface Laptop 3 System Version: 124I:00036T:000M:0300000D:0B:07F:1C:05P:48S:01E:0Y:1K:0U:00 ADDITIONAL INFORMATION Command entered just before monitor connected: journalctl -f --since="0 hour ago" Output visible once it is unplugged: Jan 09 22:08:55 shackleton systemd[1]: pcscd.service: Deactivated successfully. Jan 09 22:08:55 shackleton audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=pcscd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Jan 09 22:08:57 shackleton kwin_wayland[3338]: Atomic modeset test failed! Invalid argument Jan 09 22:08:57 shackleton kwin_wayland[3338]: Atomic modeset test failed! Invalid argument Jan 09 22:08:57 shackleton kwin_wayland[3338]: Atomic modeset test failed! Invalid argument Jan 09 22:08:57 shackleton kwin_wayland[3338]: Atomic modeset test failed! Invalid argument Jan 09 22:08:57 shackleton kwin_wayland[3338]: Atomic modeset test failed! Invalid argument Jan 09 22:08:57 shackleton kwin_wayland[3338]: Atomic modeset test failed! Invalid argument Jan 09 22:08:57 shackleton kwin_wayland[3338]: Atomic modeset test failed! Invalid argument Jan 09 22:08:57 shackleton kwin_wayland[3338]: Atomic modeset test failed! Invalid argument Jan 09 22:08:57 shackleton kwin_wayland[3338]: Atomic modeset test failed! Invalid argument Jan 09 22:08:57 shackleton kwin_wayland[3338]: Atomic modeset test failed! Invalid argument Jan 09 22:08:57 shackleton kwin_wayland[3338]: Atomic modeset test failed! Invalid argument Jan 09 22:08:57 shackleton kwin_wayland[3338]: Atomic modeset test failed! Invalid argument Jan 09 22:08:57 shackleton kwin_wayland[3338]: Applying output configuration failed! Jan 09 22:08:58 shackleton kded6[3497]: Failed to notify "Created too many similar notifications in quick succession" Jan 09 22:09:08 shackleton kernel: logitech-hidpp-device 0003:046D:406F.000D: HID++ 4.5 device connected. Jan 09 22:09:34 shackleton kded6[3497]: Failed to notify "Created too many similar notifications in quick succession"
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!