[RESPONDED] AMD Mainboard: Caldigit TS4 dock monitors not identified

keawade · November 1, 2023, 10:29pm

I have a Caldigit TS4 dock that works flawlessly with my original Framework 13 11th Gen Intel mainboard. After upgrading to the new AMD mainboard however I’m not able to get the monitors working as expected.

Everything described is on a fresh Fedora 39 Beta 1.1 install with the AMD Framework 13 3.03 BIOS update.

Under wayland the displays connect but aren’t correctly identified and are instead listed as “Unknown display” with the only available resolution being 640x480.

Xorg behaves the same way. However I was able to implement a janky workaround by manually configuring Xorg display modes for the monitors.

# Use cvt to get the modeline
cvt 2560 1440
# Use the modeline to create a new mode
xrandr --newmode "2560x1440_60.00"  312.25  2560 2752 3024 3488  1440 1443 1448 1493 -hsync +vsync
# Add the new mode to the displays
xrandr --addmode DisplayPort-4 "2560x1440_60.00"
xrandr --addmode DisplayPort-5 "2560x1440_60.00"
# Use the new modes on the displays
xrandr --output DisplayPort-4 --mode "2560x1440_60.00"
xrandr --output DisplayPort-5 --mode "2560x1440_60.00"

This got the monitors working temporarily but unplugging the dock and plugging it back in results in the monitors going back to a default 640x480. At this point I don’t have to add the display modes again but I do have to open the Display Settings panel and set their resolution and positions correctly which is a huge hassle.

If I plug the monitors into the laptop directly via DisplayPort expansion cards they are immediately correctly recognized without issue.

Note: As far as I can tell Wayland doesn’t give you the option of manually specifying and using modes so I was unable to make any headway even with a temporary workaround on Wayland.

The main point here is that there appears to be a bug in the initial monitor identification when going through a CalDigit dock. The DisplayPort signal negotiation somehow fails to report the monitor’s capability and both Wayland and Xorg default to 640x480.

Matt_Hartley · November 1, 2023, 11:02pm

This going to be a tricky one as we focus our support on our HDMI/DP expansion cards - we do this as we cannot test against all the various docks out there.

With that being said, it would be worthwhile to file a Fedora bug report as you have access to the dock and we do not.

You can file a bug at this link.
To ensure this is associated with your AMD board specifically, please remember adding the Framework Laptop top level ticket ID 2240811 to the item: Blocks as @junaruga has explained in other threads.

Terin_Stock · November 9, 2023, 2:52pm

I’m also having issues with the TS4 dock on Gentoo, with the same symptoms as the OP. The dock works fine for all my other Thunderbolt devices, included the original 13th generation board. The display also works through the dock to a degree in a USB mode from port 4, but resolution and framerate is limited.

Is there any information I can provide to the Framework team? It doesn’t look like OP created a Fedora ticket for me to follow.

interface: 'wl_output',                                  version:  4, name: 60
	name: DP-6
	description:  DP-6-unknown
	x: 2256, y: 0, scale: 1,
	physical_width: 0 mm, physical_height: 0 mm,
	make: '', model: 'DP-6-unknown',
	subpixel_orientation: unknown, output_transform: normal,
	mode:
		width: 640 px, height: 480 px, refresh: 59.940 Hz,
		flags: current

Linux alamo 6.5.10-gentoo-dist #1 SMP PREEMPT_DYNAMIC Thu Nov  2 13:30:27 -00 2023 x86_64 AMD Ryzen 7 7840U w/ Radeon 780M Graphics AuthenticAMD GNU/Linux

 ● CalDigit, Inc. TS4
   ├─ type:          peripheral
   ├─ name:          TS4
   ├─ vendor:        CalDigit, Inc.
   ├─ uuid:          XXXXXXXX-XXXX-XXXX-ffff-ffffffffffff
   ├─ generation:    USB4
   ├─ status:        authorized
   │  ├─ domain:     XXXXXXXX-XXXX-XXXX-ffff-ffffffffffff
   │  ├─ rx speed:   40 Gb/s = 2 lanes * 20 Gb/s
   │  ├─ tx speed:   40 Gb/s = 2 lanes * 20 Gb/s
   │  └─ authflags:  none
   ├─ authorized:    Thu 09 Nov 2023 02:39:57 PM UTC
   ├─ connected:     Thu 09 Nov 2023 02:39:56 PM UTC
   └─ stored:        Thu 09 Nov 2023 02:39:57 PM UTC
      ├─ policy:     iommu
      └─ key:        no

With the monitor directly connected over USB-C, it correctly negotiates:

interface: 'wl_output',                                  version:  4, name: 62
	name: DP-2
	description: Dell Inc. DELL U2723QE/XXXXXXX
	x: 2256, y: 0, scale: 2,
	physical_width: 600 mm, physical_height: 340 mm,
	make: 'Dell Inc.', model: 'DELL U2723QE/XXXXXXX',
	subpixel_orientation: unknown, output_transform: normal,
	mode:
		width: 3840 px, height: 2160 px, refresh: 59.997 Hz,
		flags: current

keawade · November 9, 2023, 3:52pm

Sorry I didn’t open a ticket as that requires creating an account which they explicitly warn will make the associated email address public and subject to increased spam.

Alan_Pearce · November 9, 2023, 7:00pm

Really? I haven’t had occasion to open a ticket as yet, but this sounds like it violates European privacy regulations as a minimum. I’m not familiar with data privacy regulations in other countries, but I was under the impression that similar regulations exist elsewhere.

keawade · November 9, 2023, 11:02pm

Yeah seems odd to me too. All I know is that the link above dropped me on a log in page that says

A user account is required to file a new bug or to comment into existing ones so that you can be contacted if more information is needed.

And going to the registration page I saw this notice and wasn’t particularly keen on continuing with that warning

PRIVACY NOTICE: Red Hat Bugzilla is an open bug tracking system. Activity on most bugs, including email addresses, will be visible to registered users. We recommend using a secondary account or free web email service (such as Gmail, Yahoo, Hotmail, or similar) to avoid receiving spam at your primary email address.

Correction on my above post then: Email isn’t public per se but visible to all other users and apparently they’ve got spam scrapers in their user pool if they’re concerned that addresses used will be spammed?

keawade · January 24, 2024, 10:55pm

Still haven’t seen any progress on this.

I was hoping system updates might resolve the issue in a month or two but that hasn’t been the case.

repnop · February 13, 2024, 2:00pm

Having the same problem ever since I upgraded to my AMD motherboard, though I’m on Arch (using Wayland). I did a little bit of extra digging since I also had issues with my displayport connected monitor not displaying anything while directly connected, and when I have everything hooked up to the dock, it seems like the displays fail to report an EDID?

[  740.739187] [drm:detect_link_and_local_sink [amdgpu]] *ERROR* No EDID read.
[  740.805818] [drm:detect_link_and_local_sink [amdgpu]] *ERROR* No EDID read.

I confirmed by using gnome-randr to figure out which display connections it was using, and in my case it was DP-7 and DP-8, then checking the sysfs files for the EDID that I found elsewhere online:

~> cat /sys/class/drm/card1-DP-7/edid | hexyl
┌────────┬─────────────────────────┬─────────────────────────┬────────┬────────┐
│        │ No content              │                         │        │        │
└────────┴─────────────────────────┴─────────────────────────┴────────┴────────┘
~> cat /sys/class/drm/card1-DP-8/edid | hexyl
┌────────┬─────────────────────────┬─────────────────────────┬────────┬────────┐
│        │ No content              │                         │        │        │
└────────┴─────────────────────────┴─────────────────────────┴────────┴────────┘

Checking the /modes file in those directories also reports the current resolution size of 640x480.

I don’t know enough about this to make any real educated guesses, but I’m happy to provide more information to anyone who wants to investigate any further!

Slav_Ivaskiv · February 24, 2024, 1:49am

Same issue with Kubuntu 22.04 and Caldigit TS3 Plus dock station. No issues on Windows 11. 11th gen Intel board had no issues.

keawade · April 23, 2024, 1:30pm

Still seeing these issues on the 3.05 bios.

Daniel_Power · August 1, 2024, 2:53pm

I’m also experiencing this with an Amd 7840u Framework and Caldigit TS4 on Archlinux. I’ve tested the latest Mainline and LTS kernels.

Has a bug been filed upstream? If not, I’ll try to submit one over the weekend.

keawade · August 8, 2024, 3:47pm

I just opened a bug report with RedHat here: 2303709 – Monitors not recognized correctly through CalDigit TS4 dock on AMD 7840U

Daniel_Power · August 8, 2024, 6:51pm

I discovered that for me this issue depends on the monitor. I have a set of three identical BenQ monitors, each of which has this problem. But if I instead connect my Alienware monitor using the same dock and cables it works normally.

Does anyone else here have an extra monitor they can test, to see if it behaves differently?

I found an issue on the AMD display driver GitLab project that seems to match the issue discussed in this thread. I updated it with my experience and a dump of the EDID info for both the working and non-working monitors in hopes that helps them track it down.

MARTOS_Theo · August 10, 2024, 9:00am

I have the same problem with my framework 13 AMD and a Caldigit TS4 dock. I have two monitors plugged on the dock. When I connect the dock to my Framework, they’re both locked at 640x480@60Hz, despite being both 1440p displays. There is an IIYAMA and an AOC display.

Also, when plugged in, the network interface of the dock seems to work, but not the other USB devices?

Currently, I connect the dock through the USB3.2 port, which allows one display out of tow to work, at native resolution, but I lose the internet port on the dock due to bandwith limitation I guess (but all USB works)

Edit (Screens model numbers) :
AOC Q27G2WG4 from 2020
IIYAMA PL2796QS (XUB2796QSU) from 2023

Daniel_Power · August 10, 2024, 7:00pm

@Matt_Hartley I understand Framework Support is somewhat limited when it comes to supporting third party docks. But given that this issue seems to occur across many USB4 docks, and is affecting several users, is there anything Framework Support can do to escalate the issue upstream with AMD?

The issue is also affecting the Framework 16:

Users have also reported this issue in the Dock Compatibility megathread

Every response on the amd drm bug report seems to have been from a Framework user. So I do wonder if there’s a BIOS bug here that causes this to occur on Frameworks but not other laptops with Ryzen 7000. But I can only speculate.

Edit: I just verified the issue is also present on the Thinkpad T14s with Ryzen 7840u. So I no longer think there’s anything Framework specific about this issue.

Matt_Hartley · August 12, 2024, 5:15pm

Yeah, this is generally where it lands unfortunately. I am a USB dock user, but I do so strategically while using the dock for pushing my Brio webcam, external keyboard and mouse. DP and HDMI expansion cards handle my external displays.

Daniel_Power · August 12, 2024, 5:53pm

I am a USB dock user, but I do so strategically while using the dock for pushing my Brio webcam, external keyboard and mouse. DP and HDMI expansion cards handle my external displays.

That’s a huge downside compared to other platforms.
Intel+Windows, Intel+Mac, Intel+Linux, Apple Silicon, AMD+WIndows. All of these combinations have working USB4 or Thunderbolt docking capabilities with functional display out. Only AMD+Linux has this issue.

For my setup, I have a docking setup where I can connect any modern system using a single cable, except for my Framework 13 AMD with Linux.

Given that this affects several Framework owners, does Framework Support have any connections or leverage that it can use to escalate the issue with AMD? If not, what is our best path forward as end users to try and escalate the issue with AMD? Should I just reach out to the users who have reported the issue here, and request that they reply to the GitLab bug report?

Adrian_Joachim · August 13, 2024, 8:09am

AMD+Linux for the most part does too, though there are definitely a lot more scratchy edge cases here.

MARTOS_Theo · August 13, 2024, 3:37pm

Update from my last tests. I tried to connect both my displays with DisplayPort to USB-C cable to my dock, instead of HDMI to USB-C. And now, they work like a charm at native resolution and refresh rate. I’m now able to use the thunderbolt-capable ports (I tried the two top ports on my Framework 13, both worked fine).

Daniel_Power · August 13, 2024, 10:40pm

For now I’ve downgraded my laptop back to the Intel 11th Gen mainboard. The battery life isn’t quite as good, but it’s much less problematic. Monitors are working again.

Not sure yet what I’ll do with the AMD mainboard.