[i915] Dual DP 4K @60Hz requires toggling to 30Hz and back to 60Hz

[iMac]

I recently started using a Cable-Matters-201355 with my XPS 9380 (8th Gen TB3). The dock supports dual 4K DP @ 60Hz via thunderbolt with PD input. (HBR3 compliant USB-C Dock (DSC/DP1.4 support) that uses all 4 high speed lanes to get dual 60Hz)

Both displays boot mirrored when powered up (Dell Logo, Grub, Kernel output) however go blank just as wayland starts up.

Unplugging one of them allows the other to appear at 3840x2160@60Hz, after which I have to execute the following process to get both up and running.

1) Change the refresh rate of the active display to 30Hz, apply in Screen Display settings dialog
2) Plug the 2nd monitor in; At this point both appear in Screen Display dialog @60Hz, but the 2nd remains blank
3) Change both to 30Hz, apply; At this point the 2nd screen turns on
4) Change both to 60Hz, apply; At this point both are working at 60Hz, my desired end state

Inspection of edid seems fine (below), other than the DisplaySize showing 27" instead of 32". Monitors are identical.

Previously, I might be able to script my steps above using xrandr, but that seems to no longer be the case with 21.10 and wayland. I seem to be limited to the Screen Display dialog.

Since I can fix by simply re-applying the settings, it seems like a bug on startup. If I could find a CLI option to allow me to script this somehow, that workaround would be just fine for myself.

Lid open/closed, power via the 201344 or direct via other TB-PD port has no impact.

Here's hoping for a bugfix in 22.04 or at least a way to script the display configuration.

$ cat /sys/class/drm/card0-DP-4/edid | parse-edid
Checksum Correct

Section "Monitor"
 Identifier "LG HDR 4K"
 ModelName "LG HDR 4K"
 VendorName "GSM"
 # Monitor Manufactured week 5 of 2021
 # EDID version 1.4
 # Digital Display
 DisplaySize 600 340
 Gamma 2.20
 Option "DPMS" "true"
 Horizsync 30-135
 VertRefresh 56-61
 # Maximum pixel clock is 560MHz
 #Not giving standard mode: 1152x864, 60Hz
 #Not giving standard mode: 1280x1024, 60Hz
 #Not giving standard mode: 1280x720, 60Hz
 #Not giving standard mode: 1600x900, 60Hz
 #Not giving standard mode: 1920x1080, 60Hz
 #Not giving standard mode: 1280x800, 60Hz

 #Extension block found. Parsing...
 Modeline "Mode 6" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
 Modeline "Mode 0" 519.38 3840 3864 3880 3896 2160 2214 2219 2222 +hsync -vsync
 Modeline "Mode 1" 266.64 3840 3848 3992 4000 2160 2214 2219 2222 +hsync -vsync
 Modeline "Mode 2" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
 Modeline "Mode 3" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync
 Modeline "Mode 4" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync
 Modeline "Mode 5" 25.200 640 656 752 800 480 490 492 525 -hsync -vsync
 Modeline "Mode 7" 241.50 2560 2608 2640 2720 1440 1443 1448 1481 +hsync -vsync
 Option "PreferredMode" "Mode 6"
EndSection

[iMac (imac-netstatz)]

I managed to bring both screens up at 30Hz on boot by passing video resolutions as kernel parameters

video=DP-3:3840x2160@30 video=DP-4:3840x2160@30

This caused me to realize I was actually loosing the kernel boot output after the framebuffer kicked in (I was loosing a five seconds or so of green service [OK]s) output prior to wayland starting.).

Now, with the displays active @30Hz prior to wayland, wayland has no problems starting on both screens, and my 60Hz settings are restored when wayland starts, as it remembers the display configuration. *HAPPY*

In summary, it is working the way I expected it too, by simply forcing 30Hz during early DRM/i915 framebuffer loading and then letting wayland restore my settings for the 60Hz configuration.

I even updated my edid with the proper 32" DisplaySize, fixing the bug in the displays, so it looks proper and does any scaling math accurately.

I no longer think this bug is a wayland issue, but not really sure where to move it.

My complete set of kernel parameters is shown below, which covers some corner cases where replugging things enumerates the ports as DP-5 and DP-6 rather than default DP-3 and DP-4, and includes my update to edid which updates DisplaySize to "710 400"

None of the errors are important, I will briefly explain.

The early edid errors are simply because my edid overrides are not in initramfs image, but they are still loaded later prior to wayland from /lib/firmware/edid/.

The DPCD read error is emitted due to an unused port on the dock. Port 1 and 2 are the ones used for DP-3 and DP-4 in my case. I determined this by observing that if either monitor is absent on boot, another one of these lines (with Port 1 or Port 2 specified) appears.

$sudo dmesg | grep -i drm
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.13.0-39-generic root=UUID=55cd97c8-08cc-4c11-8fb2-a7e0e7b10386 ro drm.edid_firmware=DP-3:edid/lg32edid.bin,DP-4:edid/lg32edid.bin,DP-5:edid/lg32edid.bin,DP-6:edid/lg32edid.bin video=DP-3:3840x2160@30 video=DP-4:3840x2160@30 video=DP-5:3840x2160@30 video=DP-6:3840x2160@30
[ 0.054811] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.13.0-39-generic root=UUID=55cd97c8-08cc-4c11-8fb2-a7e0e7b10386 ro drm.edid_firmware=DP-3:edid/lg32edid.bin,DP-4:edid/lg32edid.bin,DP-5:edid/lg32edid.bin,DP-6:edid/lg32edid.bin video=DP-3:3840x2160@30 video=DP-4:3840x2160@30 video=DP-5:3840x2160@30 video=DP-6:3840x2160@30
[ 1.785350] fb0: switching to inteldrmfb from EFI VGA
[ 1.841274] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
[ 1.930861] i915 0000:00:02.0: [drm] GuC firmware i915/kbl_guc_49.0.1.bin version 49.0 submission:disabled
[ 1.930877] i915 0000:00:02.0: [drm] HuC firmware i915/kbl_huc_4.0.0.bin version 4.0 authenticated:yes
[ 1.936210] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[ 2.344327] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes
[ 2.390395] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes
[ 2.420949] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes
[ 2.455474] [drm:edid_load [drm]] *ERROR* Requesting EDID firmware "edid/lg32edid.bin" failed (err...

[Daniel van Vugt (vanvugt)]

Thanks for the bug report. Negotiating bandwidth and supported modes, as well as the boot-time mode, are all jobs for the kernel. So I will reassign this to the kernel.

The 'wayland' package is for protocol bugs only.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1968235

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.