On a Framework laptop with the AMD 7840U mainboard: Under wayland external 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. More info and users reporting similar behavior can be found in the Framework forum thread here: https://community.frame.work/t/responded-amd-mainboard-caldigit-ts4-dock-monitors-not-identified/39228 Reproducible: Always Steps to Reproduce: 1. Connect external monitor(s) to a CalDigit TS4 dock 2. Connect CalDigit TS4 dock to Framework laptop with an AMD 7840U mainboard Actual Results: Monitors are recognized and display signal is sent but the monitors are not properly identified and instead are identified as "Unknown display" and only sent 640x480 display signal. Expected Results: Monitors should be correctly identified and able to select supported display modes.
Wayland is just a protocol specification in XML and the low-level C library that deals with the protocol. This issue here is a bug not with the protocol itself but with either the kernel driver, your compositor or desktop environment's implementation of the Wayland protocol and surrounding functionality. But definitely to Wayland.
(In reply to Olivier Fourdan from comment #1) > But definitely to Wayland. Typo there, I mean, definitely _not_ Wayland.
Okay that makes sense. Sorry I'm not entirely sure what specific component to list it under. For example there are many kernel components available in the components list but I don't know what the majority of them are to be able to categorize it myself. Are you able to recommend a specific component or is that something that is done as part of normal triage?
I'm affected by this issue as well. It occurs on both Wayland and Xorg, so I don't believe it's a bug with Wayland. I am also using a Caldigit TS4 with an Amd 7840U Framework laptop. In my testing of two monitors, the bug only occurs with one of them. Both monitors work fine in the same configuration but with a Macbook, so I am confident the monitor is not defective. I found this upstream bug report which appears to be relevant: https://gitlab.freedesktop.org/drm/amd/-/issues/3050
Just to add, this is also happening with other docking stations. I can confirm this is also happening with a Dell Thunderbolt Laptop Computer Dock - WD22TB4 and someone also mentioned it is happening with a UGREEN Revodok Max 313. To note, I can confirm both the Dell WD22TB4 and the CalDigit TS4 behaves correctly in Windows 11 with my Framework Laptop 16 AMD Ryzen 7 7840HS. https://community.frame.work/t/responded-amd-mainboard-caldigit-ts4-dock-monitors-not-identified https://community.frame.work/t/guide-ugreen-revodok-max-313 https://community.frame.work/t/usb-c-thunderbolt-dock-megathread/1460/492
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Logged in just to see if I have the ability to change the version number, but when I did, I didn't see a version field to change.
Oh, I see the field now - had to click on Show advanced fields button. However, it doesn't look like I can change the version #. Maybe the original poster (keawade) does.
Fedora Linux 40 entered end-of-life (EOL) status on 2025-05-13. Fedora Linux 40 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
I had a similar issue on my AMD Framework, and this seems to be fixed in kernel 6.14.8-300.fc42. Hooray!