Where’d you get that effective bandwidth number for DSC?
Also if we are doing bandwidth math, you should not mention the DP spec versions as they have nothing to do with that directly. That is what the speeds are for together with the amount of lanes (i.e. 4xHBR3).
And I can recommend Video Timings Calculator for anybody that wants to estimate how much bandwidth is available and how much of it a specific monitor takes up. Note that this does not account for MST situations which can get quite complicated, so always leave buffer for the overheads not accounted there for multiple displays.
Frameworks official specs more or less guarantee 4xHBR3 support on every port that does support DP. Since they themselves never mention the speed of the dGPUs output it could be throttled. Afterall AMD also specs it’s iGPUs as supporting UHBR10 and Intel has specced support for UHBR10 and UHBR20 since 13th gen and we know both are not supported by FW.
(With Intel, the USB4/TB ReTimers only support up to HBR3. For the AMD boards nothing has been said that it actually supports higher DP speeds. Mentions of UHBRx on the DP expansion card were quickly removed)
As far as I know, the USB-C on the dGPU, as well as DESIGNATED USB-C expansion cards should give you full resolution and refresh rates.
I have a CalDigit TS4 TB4/USB4 dock that doesn’t have a built-in MST hub, so I get up to DP 1.4 out of the native DP port. I should be getting the same out of the 2nd and 3rd TS4 USB-C downlinks but that relies on the support of the USB4 implementation of the host.
Right now I’m a bit confused because we were told that AMD Ryzen 7040 series USB4 implementation does not support multiple transport streams, so it only supports a single monitor natively. You’ll need a MST hub to allow for multiple monitors.
The Caldigit TS4 doesn’t have a MST hub, but I am able to get 2 external monitors working at native resolutions and refresh rates along with the internal display (total 3 displays) - Viewsonic 1080p @ 75 Hz, Asus ROG 1440p @ 165 Hz, and the internal display 1600p @ 165 Hz. BUT only in Windows.
In Fedora 39, the Viewsonic 1080p @ 75 Hz gets stuck at 640x480 @ 30 Hz, and there’s no other resolutions or refresh rates to choose from.
The TS4, just like any other Goshen Ridge implementation is limited to max. 2 outputs of DP. (It could forward an unlimited number through outgoing TB/USB4 connections, but it can only extract max. 2 DP connections from them to output as native DP).
If anybody said that, that would be a lie. It is well confirmed that MST is supported.
The thing that is a little up in the air is if a 2nd DP tunnel through USB4/TB3 is supported and with which limitations.
AMD itself never confirmed the 2nd DP tunnel, that TB4 requires. And I loaned out a AMD 6000 notebook to test and it simply could not do it (at all, behavior was identical to hosts that simply do not have the 2nd DP tunnel).
But there have been some reports on this forum that some people are getting a 2nd DP tunnel, even with a TS4 etc, for which there MUST be a 2nd DP tunnel available.
But here and on other forums I have also seen reports of this being weird / unreliable. Like that AMD throttles the 2nd DP tunnel to the point where its not much useful anymore, or it does not work with specific docks or under Linux. Your report is a perfect example of that already.
Since I have no AMD host to experiment with and many people reporting on it are not familiar with what USB4 could do and the topology of their docks, it is hard to compile all of the reports into a coherent thing.
At the start, due to my experiences with the 6000 host, I guessed, that AMD would not support the 2nd tunnel as well, but that has definitely been proven wrong. It seems it is there but highly problematic depending on OS, drivers, firmware, dock, MST topology, monitors. So it probably cannot be really relied upon right now. Maybe AMD manages to fix that in the future… Ideally, they’d just speak on what it is they built into their own CPUs so we do not have to guess what is a hardware limitation and what is a software bug.
I suspect you are correct on that, only because the TS4 works perfectly fine in Windows 11. Only in Fedora 39 do the 2nd external display is stuck at 640x480, so it must be a driver/software related issue, not a hardware limitation.
Yeah. The fascinating thing is: I have seen Linux having trouble with MST, specifically with the Synaptics MST hubs I have (common in Dell, Lenovo, HP docks). Linux seems to not support DSC at all with them and is very erratic what it allows compared to Windows, even on Intel.
But the 2 DP tunnels that USB4/TB support seem to work much more reliably. And there are even users reporting DSC working with other MST hubs or monitors directly.
So just fascinating that its the part that is managed by the same “thunderbolt” drivers in Linux that is being weird. Although if I had to guess, I’d guess that at least part of the MST & DSC stuff is also shared between Intel and AMD GPUs, because the debugging reports look so similar.
Maybe @Mario_Limonciello can point you in the right direction of where to report this issue so that Linux developers can take a look at it, or maybe where it is already being tracked with possible workarounds (sorry for the mention, if you don’t know because that is not your department).
I am not up to speed on the layers of Linux involved in producing graphics output and which group maintains which parts of that. I still use far to much Windows for that.
A large chunk of MST code is shared between Intel and AMD but DSC code is not.
But yes bugs crop up all the time with different MST and DSC combos. There is a large test suite (IGT) that runs in automation and catches a lot, as well as manual testing run before pull requests are made for the next development kernel off the development tree (amd-staging-drm-next).
I suggest if you have DSC + MST problems you first reproduce on the latest RC kernel or if you can amd-staging-drm-next. Then file them into the AMD Gitlab bug tracker with as much detail as you can provide about the docks and monitors and isolation you’ve done on your issue.
If it’s esoteric hardware that’s hard to come by, that of course means it going to be hard to reproduce.
As you can see a majority of the cases remaining are corner cases so turning up DRM debug logging will be crucial to find the problem.
Another really useful data point is if you happen to have other AMD hardware without USB4 (like a dGPU or a steam deck) you might be able to provide more data points about what is happening with MST + DSC in that problematic hardware without adding the extra USB 4 tunneling complexity and bandwidth/speed limitations.
I can’t commit the display team will be able to reproduce or solve the issue, but the more details you gather the better a chance.
I’m pretty new to Linux and have NO idea how to report issues in a manner that makes sense to developers. I have no idea where to even start (where, who, how, etc).
With smaller projects on GitHub, I’ve been able to submit issues and have someone walk me through getting what they need (ex: reproduction, logs, things to try, etc). But never had I had to do a formal bug report on something for Linux or Fedora itself.
I was probably less clear than I should have, because I talked about both USB4 and MST in the same post.
The problems @Techie_Zeddie is reporting are about USB4.
The TB4 Dock in question is using a straight Intel Goshen Ridge Controller. It can only “forward”, the DP connections as the host provides them. And according to the user, such 2 separate DP connections work under Windows, but under Linux, the 2nd DP connection is ridiculously bottlenecked.
I can often help a lot of people by explaining the bandwidth limitations of 2 DP connections inside a single TB/USB4 connection, but in this case, the user reported being limited to 640x480. Which is way below any bandwidth limitation that should be enforced by USB4 according to my knowledge (even a 4xRBR connection, that I have never seen in the wild, should still easily do FullHD or at least sth. more than VGA).
And because it seems like such a weird bandwidth limitation, I guessed, that it could not just be that the Linux USB4 drivers distribute bandwidth among to competing DP tunnels differently (but justifiably) than Windows, because, even with the fastest DP tunnel supported by the Intel Goshen Ridge controller (4xHBR3) for connection A, there is still at least enough bandwidth left for a 4xHBR1 connection B that should easily fit even WQHD@60 still.
So I am guessing the problem lies somewhere between the USB4 parts and the AMD GPU parts that filter the allowed resolutions based on the DP connection & bandwidth that they managed to secure (which should be 2 separate SST connections). But I am not deep enough in the Linux stuff to have a good handle on where to look next to narrow that down to either driver. And sadly, I do not own any AMD USB4 hardware to test this myself. While I have no problems poking through source code if I am interested and trying various things out, I cannot walk other users through that stumbling process.
I appreciate the other info on the MST parts though. That explains my own personal bugs (although I have not cared enough to report / debug those so far, because on my personal and mobile PCs I am still using Windows and only boot up Linux to cross check / play around. And the serious and permanent Linux setups I use, do not require docks and do not have that problem).
I believe the reason for 640x480 is very likely caused by a failure for the hardware to report the correct EDID. You may see similar messages in the logs about this.
If it’s unique to USB4 it should still be filed but that is absolutely an extra dimension to worry about with USB4. I think it really is best to try to connect the dock to a non USB4 port and compare.
USB4 docks will downgrade to DP alt mode instead of DP over the USB4 tunnel when connected to such a port. Then you removed one element from the chain.
But that is a problem with this specific case. Because the first DP connection seems to work just fine. And the 2nd though the same dock can only exist on top of USB4 or TB. With only DP Alt mode, there won’t be a 2nd DP output. And you are changing the DP negotiation, because you will also force the downgrade to 2x Lanes at the host side.
But I believe you are right. i think I read from some other AMD user in passing, that they managed to override the EDID info to force it to work in a similar situation.
So there is some things to try for @Techie_Zeddie: 2 attempts: each of your 2 monitors behind the TS4 and the other connected separately from the Framework out of the non-USB4 port. And look if there is some behavior that is moving with the monitor or not.
Attempt 1: Both monitors behind the TS4.
Attepmpt 2: 1 behind the TS4, the other behind a non-USB4 port (I guess that means not the two ports closest to the rear?)?
Once I do this, what shoud I be observing or gathering as far as logs (if any)?
No. Both times, just one monitor behind the dock. Just a different one. And the other monitor each time connected directly to the iGPU without any USB4 involved. To check if it is the combination of a specific monitor and the dock that causes problems under Linux.
A completely different test would be to plug the dock in without any monitors attached and then plug the monitors in in different order. Each time checking the first monitor runs at max capabilities (thereby reserving its bandwidth) and then plugging in the 2nd monitor into the dock as well.
This forces a specific order of connecting to the monitors, whereas connecting the dock with both monitors plugged in will let the host choose which monitor to connect/negotiate with first (Intel & Windows handle this automatic order very deterministically, but not everthing might).
These would be just about checking that no monitor is being throttled and still supporting full capabilities as expected. To find common elements of when it fails, to maybe guess at the point where it might fail.
Like I said, I sadly don’t have access to any AMD+USB4 hosts. So I cannot test and provide you with commandlines that will show you debug reports or specific logs of negotiating those connections. I have not even found those for my Intel systems (also, I have not looked that hard, but still). If I had such an AMD system, I’d probably already reported the stuff and would try fixing it myself.
I am just very curious about what the actual capabilities and implementation of AMDs USB4 controllers are compared to what Intel has, that I have looked into a lot.
If I just have one monitor behind the dock, no issues. The 1440p @ 165 Hz works as it should. The 1080p @ 75 Hz also works as it should.
That’s also fine on their own when connected to the iGPU without the USB4 involved (using the DP expansion card).
Doing this, as long as one monitor is connected, the full capabilities are fine. While the 1440p monitor is working, if I plug in the 1080p monitor, it gets hard-stuck on 640x480. Same for the other way around.
So am I. Again, no issues in Windows 11 though, so again, I think hardware-wise it’s fine. Just something going on with either Fedora 39 or Linux in general.
I haven’t tried booting into a different distro via a Live USB to testing it out that way. I guess I can try Ubuntu. My next favorite distro is PopOS personally.
Ok. That at least, to my ears points to a problem involving USB4 / the thunderbolt driver. Somehow. Because the problem does not follow the monitor in any way.
One next step (where my knowledge ends) is finding the debug flags, with which to enable more logging of the thunderbolt driver. Because that should include the “connection manager” that manages and decides what tunnels to establish and with what parameters. As Windows’ connection manager does, it should see the reported features of the docks DP output and the monitor behind it (only DP features, so speeds, lanes, etc. Not resolution. Though it might also see the used resolution etc. But at a later point, once the GPU driver has started using the display).
One would need to compare the log messages from that to what one would expect or if it somehow explains how the EDID Data is lost in that driver.
Maybe one can even find a debug report showing all that info, but I have not seen any.
And if there is no issue in there, then one would need to do pretty much the same on the AMD GPU driver side. Which would be the other step (where my knowledge also ends):
Like the mechanism, by which the GPU driver is notified of a new monitor being plugged in into a new port. And more specifically how that happens with USB4. Because the DP connection between the USB4 controller and the iGPU is at least in part virtual, more likely like 80% virtual.
The debug reports I know of for the GPU driver would be /sys/kernel/debug/dri/1/amdgpu_dm_dtn_log and its neighbors. For example there should be a folder for each connector of the GPU and one could try to understand which of them will be the one that is used through a USB4 connection (for the 2nd tunnel).
And then also kernel logs of that driver when it detects a new device (“hpd” for example refers to DPs Hot-Plug-Detect, which should be how the GPU notices that a new monitor was connected. And then it should establish a DP aux link, query the display, EDID, DPCD and then proceed to establish the main link (at 4xHBR2 for the WQHD@165 display, 4xHBR(1) or 4xRBR for the FHD display).
If you can actually override the EDID info and then have it working like Mario suggested (by capturing the EDID info form when it works), then that for sure has to be some esoteric bug in the depths of the GPU driver. Because EDID is barely involved in negotiating the actual DP connection. DP has a lot of communication outside of EDID that would not be affected directly and is used to discover what the monitor can do in terms of DP connection etc.
And if the issue is there, then that would be sth. that could be reported against the gitlab amdgpu driver with pretty much that information to get them started.