I’m glad you’ve asked about cables, I need to buy some good quality USB-C cables and not sure which brand would be best (not much experience with buying cables recently and virtually no experience with USB-C especially for video output).
I bought a few CableMatters cables rated for PD and display output a while ago. Wasn’t using them because they were pretty long, but they worked for me once I swapped over.
Most thunderbolt 3 and 4 cables are definitely also display alt capable, though not all PD cables necessarily are. Don’t really have much recommendation in terms of manufacturer though.
Alright, gonna order some USB4/TB4 cables, which say they support DP Alt Mode, and see if that works. Pretty sure all cables I already had were USB 3.
Here’s what I ordered, since I liked the fact they have angled plugs.
is the iGPU disabled when using the dGPU? I’m wondering if that’s why you’re not getting any output from the USB-C ports on the sides (they are connected to the iGPU). when you have the dGPU enabled (to drive the internal display).
Try disabling the dGPU (running just the iGPU) and see if the side outputs are working in that configuration.
It’s slots 1,2 and 4. 5 doesn’t support display out.
It works on mine with a USB-C to DP cable. On both GPUs.
Corrected. I guess I misread the chart. Even so, haven’t gotten it to work yet. I’ll see what happens when these new cables arrive.
For what it’s worth, only port 4 (rear right) works for me on Linux; no other ports including the one on the dGPU successfully output video over USB-C with my current monitor + cable pair.
All of the other ports worked as expected under Windows.
I have a Lenovo L15 external USB-C monitor that works on a MacBook Pro 13 and a NUC11 with the included C-to-C cable.
On FW16 running Arch with Kernel version 6.8.1, I only get an output when connected to the dGPU, and only if it is not “suspended”.
When I connect the monitor to USB-C expansion card in slots 1,2 or 4 I get journal messages like
ar 24 22:39:16 framework kernel: amdgpu 0000:c4:00.0: [drm] Alt mode has timed out after 218 ms
Mar 24 22:39:17 framework boltd[521]: probing: timeout, done: [2315826] (2000000)
Mar 24 22:39:19 framework kernel: ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
Edit:
FW16 behaves the same with the LG 29UM69G-B monitor that is usually connected to my NUC
Alright, just got that new cable in… and still no video out from ports 1, 2, or 4.
Update:
had some time and tested again. This time with DP and HDMI extension modules as well as with USB-C and the C-to-C cable mentioned:
- Woke laptop from suspend as usual
- No matter which module, no ouput @ ports 1/2/4
- decided to plug the HDMI module into dGPU USBC port and wake the dGPU → sensors (from lm-sensors) hung, had to hard-reset…
- On first reboot, no module worked
- Power down + reboot: modules were recognized again, but still no output
Here I wanted to try an older 6.5.x kernel.
- since I didn’t install one in my Arch install, I fired up a Fedora 39 live usb (on ventoy)
- Modules were recognized and external displays WORKED! (yes, had two connected)
- checked journalctl and found similar messages as in Arch (+ GNOME finding the monitors)
I then rebooted into Arch with everything still connected and now have working external displays. I also tried the modules in different slots as well as suspend with and without displays connected.
I have no idea why, but it all works now
Does one need to set something in the BIOS (or UEFI for the pedantic) to say both GPUs should be enabled?
All Drivers installed?
Windows + P
select duplicate.
These problems might be due to bugs in DP link training.
In that bug, it failed in some kernels and worked in others e.g.:
5.16.0-rc5 works.
5.17.1 fails
5.18.0-rc3 works.
The AMD GPU drivers change so often and all the code gets moved around so often, it seems that old bugs get re-introduced quite easily.
Maybe the bug has come back in some more recent kernels.
For example, the patch I wrote for 5.17.1 won’t apply to more recent kernels as their code paths and behaviour is quite different.
So, I cannot help you at the moment, but this might be an explanation as to why some kernels work and some do not.
I’m not sure. I’ve checked the BIOS, and I didn’t see any settings that would’ve been relevant.
I’ve installed the driver package from Framework’s knowledge base, but I’m not aware of any other drivers I need to install? And there haven’t been any updates to that yet.
I’ve tried the different Projection options, and the second monitor does nothing (except turn on) if not connected to the dGPU USB-C port.
Heyo! Just want to flag up my experiences given I’m getting the same error as @undermark5, but have more data points. Specifically, the error of ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
- both are LG 24MK430H-B (I hit my link limit lol)
On the StarTech 132N-TB4USB4DOCK (Thunderbolt 4 Multi-Display Dock, 7x USB - Thunderbolt Docking Stations | Universal Laptop Docking Stations | StarTech.com), on both back left + right, the monitors appear to the system, but error out with the same error. Plugging into the GPU expansion port they don’t even show up.
On the Anker 568 USB-C docking station (Anker 568 USB-C Docking Station (11-in-1, USB4) - Anker US), plugging in a single monitor (in this case, HDMI via a DP-to-HDMI adapter) causes the display to show up, but periodically blank/disconnect and reconnect. Both displays work perfectly off the expansion bay GPU’s USB-C port, but I can’t charge my laptop through it.
I have verified it’s not the cables, I have now bought 12 different pairs of cables, with different combos of ports they work with.
Additionally, through the framework official DP input module, I can’t ever get the displays to work, no matter where it’s plugged in, even with TLP disabled to confirm it’s not a factor.
System is Arch Linux, running 6.8.1-zen1-1-zen with amd-ucode 20240312.3b128b60-1 and mesa 1:24.0.3-2 + amdvlk 2024.Q1.2-1
I can also confirm that on a dell XPS 15 with an intel iGPU, all of these docks work flawlessly with both monitors across all ports.
So… update to this… Just got a new monitor today (16" 2560x1600, just like the built-in display)… and it works through USB-C on the side ports!
I’m not sure if this means there was something wrong with the previous monitor I was using (not configured correctly? Not supported?), but as to why it worked on my previous laptop and not the FW16… no idea. At least this new one works.
Only issue now is I can only seem to set it up to 144Hz refresh, even though the monitor should support 165Hz.
Depending on the monitor you may need to enable 165hz in the monitor’s settings. I have a Viewsonic monitor and it needs to be “overclocked” in order to select 165hz in Windows or NVIDIA control panel (I use that monitor on my desktop).
Part of this issue is the mix of dependencies from different standards trying to filter everything through whatever interface is being driven.
Older video outputs were mostly one-way (i.e. the video card just put out timing for Horizontal, Vertical, Polarity, and Clock rate [this is overly simplified])
Now monitors will only display if they can “negotiate” some signal that they want from the video output. If the interface (i.e. USB-C) doesn’t talk the way the monitor is expecting it the feed is shutdown rather than rolling back to a known “Safe mode”.
Similarly, the interface is expecting data to come back in some format and if it doesn’t understand it it just bails and shuts down the output signal all together because the fear is driving an output the monitor can not handle.
Ideally you should be able to force an output at a certain resolution, clock rate, and polarity from an output and let the monitor decide if it can display it or not. Old CRT monitors would just sit blank, or show overscan lines indicating it couldn’t understand the signal being fed.
Some of it is a crapshoot to see if X monitor works with Y output. Standards were intended to eliminate this gambling and instead have made it too complicated to work at most anything beyond basic levels. All ports should be capable of driving outputs but there are so many layers it just takes one hiccup and all that is left is a blank screen.
This probably does not help resolve the display output via USB-C being discussed on this topic. I would like to know that a feature touted (Video over USB-C) reliably worked as long as the Monitor had X Standard to take the guesswork out of trial and error. Maybe I missed that in the specifications of Framework devices (i.e. DisplayPort works with anything 1.1 or later monitors, USB-C works with Primary or Alternate USBC-Video Mode 1.X or whatever it might be, etc.)
Thank you for the testing and updates.
I had the EXACT same problem… I’ve gone through 3 monitors and cables - NO GO - NO VIDEO signal. Can you tell me what’s the MAKE / MODEL of the usb display that did work for you. Thanks
I finally purchased a usb-c cable specifically for running 4k@144hz, and my Framework 16 still only goes to 60hz on my monitor at 4k. I double checked the monitors manual, it lists 4k@144 as supported over usb-c.
This is what I got.
https://www.amazon.com/dp/B09YM3V7NX?psc=1
Has anyone gotten 144hz to work with a 4k external monitor on the iGPU over usb-c?