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. 
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.
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? 
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.
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
Same issue with Kubuntu 22.04 and Caldigit TS3 Plus dock station. No issues on Windows 11. 11th gen Intel board had no issues.
Still seeing these issues on the 3.05 bios.
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.
1 Like
I just opened a bug report with RedHat here: 2303709 – Monitors not recognized correctly through CalDigit TS4 dock on AMD 7840U
1 Like
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.
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
@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
- USB-C/Thunderbolt Dock Megathread - #358 by Grigory_Malkov
- USB-C/Thunderbolt Dock Megathread - #408 by bnjns
- USB-C/Thunderbolt Dock Megathread - #473 by Techie_Zeddie
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.
1 Like
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.
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?
AMD+Linux for the most part does too, though there are definitely a lot more scratchy edge cases here.
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).
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.
I’m already using the CalDigit USB-C to DP adapter. Not working for me 
That was my experience as well. Sadly, my monitors only have 1 DP port each and 2 HDMIs, so I would have to investigate alternative options of switching instead of replugging cables all the time. Dock station is shared between the personal 2 laptops (AMD framework laptop and Intel Windows one), while DP ports are used by the desktop PC.
What’s frustrating is that both external monitors work fine in Windows, just not in Linux, so it seems like a driver issue, not a hardware one.