Refresh rate of external display on dock not recognized

ruuda · 2021-11-27 12:23:37

Summary

I have two 4K displays connected to my Dell WD19TB Thunderbolt dock. With two different laptops, I am able to drive both displays at 3840x2160 at 60 Hz. However, with a newer laptop, I can only drive one of the displays at 60 Hz, and the other one at at most 30 Hz.

Details

I am using the Dell WD19TB Thunderbolt dock. It is capable of driving two displays at 3840x2160 at 60 Hz, but not for all combinations of ports: one of the displays has to connect to the Type-C/Thunderbolt 3 port on the dock, the other to one of the DisplayPorts. This is how I connect my displays, and it works fine on the following two laptops:

2015 Dell XPS 9550 (Intel Core i7-6700HQ)
2020 Dell XPS 9500 (Intel Core i7-10750H)

It doesn’t work with this laptop:

2021 Dell XPS 9510 (Intel Core i7-11800H)

With the 9510, it will drive one display at 60 Hz (the one connected through DisplayPort), and one at at most 30 Hz at 3840x2160 (the one connected through Type-C, with a Type-C-to-DisplayPort cable).

On all three I am running the latest kernel (5.15.5.arch1-1 at the time of writing). In all cases, I connect the dock to the Thunderbolt port on the laptop. (You can tell because if you connect it to the non-Thunderbolt Type-C port, the firmware will show a warning that the dock is not connected to a Thunderbolt port.) I don’t have any nvidia or nouveau packages installed, I should be using only the integrated Intel GPUs.

DisplayPort/Thunderbolt/Type-C is fairly subtle, see e.g. https://www.bigmessowires.com/2019/05/1 … usb-c-hub/, and I suspect it is related to this. Two lanes of DisplayPort can provide at most 30 Hz at 3840x2160; so I suspect I’m somehow using this, and not the 4-lane mode? But clearly, the hardware supports it (at least the dock does, and I would expect the newer processor to not have regressed in this regard), so I think this is a software issue. How can I debug this further?

Things tried

Xrandr says the following (now on Xorg, on Wayland the names of the displays change, but I observe no difference between Xorg or Wayland), omitting the internal display:

DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP2-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 610mm x 350mm
   3840x2160     60.00*+  60.00    29.98  
   2560x1440     59.95  
   1920x1200     59.88  
   2048x1080     24.00  
   1920x1080     60.00    60.00    50.00    59.94    24.00    23.98  
   1600x1200     60.00  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    60.00    59.94  
   720x400       70.08  
DP2-2 disconnected (normal left inverted right x axis y axis)
DP2-3 disconnected (normal left inverted right x axis y axis)
DP3 connected 3840x2160+3840+0 (normal left inverted right x axis y axis) 610mm x 350mm
   3840x2160     29.98* 
   2560x1440     59.95  
   1920x1200     59.88  
   2048x1080     24.00  
   1920x1080     60.00    60.00    50.00    59.94    24.00    23.98  
   1920x1080i    60.00    50.00    59.94  
   1600x1200     60.00  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    60.00    59.94  
   720x400       70.08

In /sys/class/drm, we have:

$ ls /sys/class/drm/*         
/sys/class/drm/version

/sys/class/drm/card0:
card0-DP-1  card0-DP-3  card0-DP-5  card0-eDP-1  engine   power      dev    gt_act_freq_mhz    gt_cur_freq_mhz  gt_min_freq_mhz  gt_RP1_freq_mhz  uevent
card0-DP-2  card0-DP-4  card0-DP-6  device       metrics  subsystem  error  gt_boost_freq_mhz  gt_max_freq_mhz  gt_RP0_freq_mhz  gt_RPn_freq_mhz

/sys/class/drm/card0-DP-1:
device  drm_dp_aux1  i2c-30  power  subsystem  dpms  edid  enabled  modes  status  uevent

/sys/class/drm/card0-DP-2:
device  drm_dp_aux2  i2c-31  power  subsystem  dpms  edid  enabled  modes  status  uevent

/sys/class/drm/card0-DP-3:
device  drm_dp_aux3  i2c-32  power  subsystem  dpms  edid  enabled  modes  status  uevent

/sys/class/drm/card0-DP-4:
device  drm_dp_aux4  power  subsystem  dpms  edid  enabled  modes  status  uevent

/sys/class/drm/card0-DP-5:
device  drm_dp_aux5  power  subsystem  dpms  edid  enabled  modes  status  uevent

/sys/class/drm/card0-DP-6:
device  drm_dp_aux6  power  subsystem  dpms  edid  enabled  modes  status  uevent

/sys/class/drm/card0-eDP-1:
device  drm_dp_aux0  i2c-29  intel_backlight  power  subsystem  dpms  edid  enabled  modes  status  uevent

/sys/class/drm/card1:
device  power  subsystem  dev  uevent

/sys/class/drm/renderD128:
device  power  subsystem  dev  uevent

/sys/class/drm/renderD129:
device  power  subsystem  dev  uevent

$ cat /sys/class/drm/*/enabled
disabled
disabled
enabled
enabled
disabled
disabled
disabled

So it is card0-DP-3 and card0-DP-4 that are enabled. card0-DP-3 is the display that I can’t drive at 60 Hz, card0-DP-4 is the one that I can. These names are stable across reboots and plugging cables in and out. What stands out is that the 30 Hz one has this i2c-32 file but the 60 Hz one doesn’t. The edids are identical except for the manufacturing date (it’s the same model display):

$ /usr/bin/diff -u <(parse-edid < /sys/class/drm/card0-DP-3/edid) <(parse-edid < /sys/class/drm/card0-DP-4/edid)
Checksum Correct

Checksum Correct

--- /proc/self/fd/11	2021-11-27 12:54:11.784328631 +0100
+++ /proc/self/fd/12	2021-11-27 12:54:11.784328631 +0100
@@ -2,7 +2,7 @@
 	Identifier "DELL U2718Q"
 	ModelName "DELL U2718Q"
 	VendorName "DEL"
-	# Monitor Manufactured week 48 of 2017
+	# Monitor Manufactured week 30 of 2019
 	# EDID version 1.4
 	# Digital Display
 	DisplaySize 610 350

I did find https://bugs.launchpad.net/ubuntu/+sour … ug/1922372 which looks related. From there, it looks like the fix was this patch: https://lore.kernel.org/all/20210201150 … intel.com/. However, that patch is already part of 5.15, so I don’t think this is the issue:

$ git log --grep 'update DP max link rate table' v5.15
commit b60e320bf35971e67b6afabd5614c6196b3be95d
Author: Lee Shawn C
Date:   Thu Feb 18 13:23:33 2021 +0800

    drm/i915/vbt: update DP max link rate table

What I tried so far:

Append video=card0-DP-3:3840x2160@60 video=card0-DP-4:3840x2160@60 to my kernel cmdline. This did not make a difference.
Follow the steps at https://wiki.archlinux.org/title/Xrandr … esolutions. This did not fix the issue.
Allow Thunderbolt devices during boot in the firmware settings. It did not make a difference, and it would be weird if it did, because the dock works fine if you plug it in after boot.

What can I do to further diagnose this?

ruuda · 2022-03-26 16:56:26

After some further investigation, in some very rare cases, the second display does get a 60 Hz refresh rate as well after boot. Sometimes, plugging the USB-C to DisplayPort cable into the other USB-C port of the dock allows the second display to be 60 Hz, but it doesn’t happen consistently. So far I haven’t been able to get it to work consistently. I suppose it’s a regression in the kernel, but maybe the dock is bad, or maybe it’s a combination of both ...

a9udn9u · 2022-10-15 15:20:41

Did you find a solution yet? I have a similar issue. My laptop outputs 4k@60hz via docking station on Windows but not on Arch. Same hardware so I'm sure this is a software problem. Unfortunately my dock only has USB-C thunderbolt ports for video output (CalDigit Element) so I can't get any monitor to work properly.

ruuda · 2022-10-16 10:52:42

It works partially now. On the 2020 XPS 9500, it works most of the time. Some days when I boot, it drops the refresh rate of the second display back to 30 Hz with no ability to change it back to 60 Hz, but then after a reboot, I can usually change it to 60 Hz. I have no clue why this happens only sometimes, but it is relatively rare (1 in 10–20 boots maybe).

On the 2021 XPS 9510, I haven’t been able to make the second display run at 60 Hz.

ruuda · 2023-12-01 18:02:47

This issue is not solved, but I have a workaround now that works consistently for both the XPS 9500 and the XPS 9510.

1. Boot with both displays connected and laptop lid closed. Almost always, the left display runs at 60 Hz, the right display at 30 Hz.
2. Turn off the left display. At this point, the right display usually switches to 60 Hz, but don’t turn on the left display yet, because then the right one will switch back to 30 Hz.
3. Turn off the right display (both of them are off now).
4. Turn on the right display again.
5. Turn on the left display again.

Now about half of the time, both will run at 60 Hz. If not, then at least the 60 Hz option is now available in Gnome display settings, and that works consistently.

A faster way that also works consistently is to boot with only the right display turned on, and to turn on the left display later. The other way around, booting with only the left display and turning the right one on later, doesn’t work.

(Of course, left and right are arbitrary depending on your setup. I’m not sure what causes the right display to be the victim, whether it’s a serial number or the ports the cables are connected to.)

seth · 2023-12-02 07:41:51

Please dump the edids when the output allows only 30Hz and when it allows 60Hz

for OUT in /sys/class/drm/card0*; do echo $OUT; edid-decode $OUT/edid; echo "================="; done

You'll need https://aur.archlinux.org/packages/edid-decode-git

You might be able to leverage that by injecting the "good" EDID, https://wiki.archlinux.org/title/Kernel … s_and_EDID
nb. that the output names have to be correct (your approach description in the OP seems to be off there?)

ruuda · 2023-12-05 19:08:28

Thank you for looking into this. I ran edid-decode in both cases, output here: https://gist.github.com/ruuda/0ef9d12cd … ef5afcf62a. The order is different between the two, but the contents is not:

--- a/tmp/30hz.txt
+++ b/tmp/60hz.txt
@@ -1,6 +1,9 @@
 /sys/class/drm/card1
 ==========
 /sys/class/drm/card1-DP-1
+EDID of '/sys/class/drm/card1-DP-1/edid' was empty.
+==========
+/sys/class/drm/card1-DP-2
 edid-decode (hex):
 
 00 ff ff ff ff ff ff 00 10 ac ec a0 4c 54 36 30
@@ -124,9 +127,6 @@ Block 1, CTA-861 Extension Block:
                  Vfront    3 Vsync  10 Vback    6 Vpol N
 Checksum: 0x4a  Unused space in Extension Block: 8 bytes
 ==========
-/sys/class/drm/card1-DP-2
-EDID of '/sys/class/drm/card1-DP-2/edid' was empty.
-==========
 /sys/class/drm/card1-DP-3
 EDID of '/sys/class/drm/card1-DP-3/edid' was empty.
 ==========

seth · 2023-12-05 19:21:47

Can you please post the complete outputs still?

ruuda · 2023-12-06 17:05:44

I did, in the linked Gist: https://gist.github.com/ruuda/0ef9d12cd … ef5afcf62a

seth · 2023-12-06 19:12:48

Sorry, overread that.

The EDID is stable, both outputs offer

    DTD 3:  3840x2160   29.980602 Hz  16:9     65.688 kHz    262.750000 MHz (609 mm x 349 mm)
                 Hfront   48 Hsync  32 Hback   80 Hpol P
                 Vfront    3 Vsync   5 Vback   23 Vpol N
    DTD 4:  3840x2160   59.996625 Hz  16:9    133.312 kHz    533.250000 MHz (609 mm x 349 mm)
                 Hfront   48 Hsync  32 Hback   80 Hpol P
                 Vfront    3 Vsync   5 Vback   54 Vpol N

The filter has to be applied in the server (check the xorg log)
You could try to add

◉ cvt12 3840 2160 60 -b                    
# 3840x2160 @ 60.000 Hz Reduced Blank (CVT) field rate 60.000 Hz; hsync: 133.320 kHz; pclk: 522.61 MHz
Modeline "3840x2160_60.00_rb2"  522.61  3840 3848 3880 3920  2160 2208 2216 2222 +hsync -vsync

which has a slightly lower signal than the cvt1 reduced blanking offered by the EDID
https://wiki.archlinux.org/title/Xrandr … esolutions

Arch Linux

#1 2021-11-27 12:23:37