You are not logged in.
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.
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?
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?
Offline
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 ...
Offline
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.
Offline
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.
Offline
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.)
Offline
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?)
Offline
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.
==========
Offline
Can you please post the complete outputs still?
Offline
I did, in the linked Gist: https://gist.github.com/ruuda/0ef9d12cd … ef5afcf62a
Offline
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
Offline