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

Framework Laptop 13 Linux
1

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.

1 Like
2

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.
3

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
1 Like
4

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. :slightly_frowning_face:

5

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.

6

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? :person_shrugging:

7

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.

8

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!

1 Like
9

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

10

Still seeing these issues on the 3.05 bios.