Interesting observation I noticed today. I am powering my portable monitor with a USB-C to USB-C cable and 65 watt wall charger. Then I connected my laptop to the display with another USB-C to USB-C cable. The display works and is actually also charging the laptop.
So its like my portable monitor is passing power through to the laptop while simultaneously accepting the video signal on the same cable. Hadn’t seen a connection setup like this before.
But I tried to power the monitor with a non-Displayport USB-C cable, and use a HDMI at the same time, and it actually works! (EVICIV 17,3", supposed to consume 7w)
It’s still 2 cables instead of one, but at least it removes a power adapter
@Matt_Hartley, any news about the investigations?
Thanks!
I wonder if this requires a firmware update… and if so if Frameworks recent commitment to better supporting their devices with software/firmware updates gives me hope this could get addressed at some point. That would be awesome, it’s frustrating not being able to use my portable monitors as easily as I would like. I’m not sure if this issue is on Framework’s radar though and whether it’s prioritized at all…
Doesn’t seem like it… They put out new drivers/BIOS a few weeks ago and didn’t address it at all even though this thread was started back in November of 2023. Getting really frustrated with this issue along with all the other problems I’ve had with this laptop.
We test extensively against HDMI to HDMI expansion card and DP to DP expansion card. We do not test as heavily with USB-C displays. As indicated previously, best course of action is to make sure you are using the guides below:
After a bunch of testing it seems to be an odd issue with powering & displaying. If I plug in power to the display first via it’s other USB-C port, then plug it into the FW, the FW will send display signal to the monitor and the monitor will pass through power to the FW. If I disconnect the power from the monitor, the FW will power the display, but not send signal.
I can also connect any combination of ports using 2 USB-C ports from the FW and it seems like the external monitor just changes which port is providing power, no display output at all. I even tried powering monitor first with port 2 (no display output) and then connecting ports 1/3 for display.
I wonder if this is at all related (or just a coincidence) to the power negotiating oddities with connecting devices that can send and receive power. Connecting a current generation iPhone with USB-C using a C to C cable causes the phone and the FW to get stuck in a connection loop.
I am having this same issue, support is offering to take my laptop for diagnostics. Should I do that or just leave it for now and see if it fixes with updates?
Hi, I’m facing a similar issue as well. I’m using the Framework Laptop 13 with AMD 7840U. My Dell external display doesn’t always extend my screen when connected to my laptop via USB-C on ports 1 and 3 (USB4 ports).
I’ve tested a few scenarios, there are only 2 scenarios where I can use my external display with my framework laptop. 1) When my laptop has 95% and above, or 2) When I have a power source charging my laptop on a different port. When I’m in either one of these scenarios, then my framework 13 can charge and project/extend to the external display at the same time. Else it will show an error message at the bottom right corner “Display connection might be limited”. The laptop will attempt to project/extend to the external display when connected. The screen on my laptop will become smaller during the attempt to connect to the external display and maximize back to full size. But the external display will remain blank, and my framework laptop will try to project/extend to the external display again repeatedly.
I’ve tested it with different laptops, cables, monitors, the latest drivers, updates & BIOS 3.05, but the issue persists. Has anyone found any other way to solve this issue?
It seems like this is down to how the boards for the AMD models specifically handle the usb negotiation- they seem to favor power first, and data second, but not both.
My particular portable monitor (a CNBANAN P16TA10 1080p display + touch) works wonderfully on my intel mainboard with a single usb cable, whereas my AMD mainboard does not- it has the same behavior as outlined in this thread, where the monitor works great if powered first, and then connected to the laptop. (even if said power is coming from the laptop itself via a USB-A port with a power-only cable) But, if the usb c ↔ usb c cable (or thunderbolt) is connected first, it only runs power. (At which point the monitor can take HDMI input from the laptop, but not another usb/thunderbolt cable)
My portable monitor (FlipGo 13) works fine off either of the USB-C 4 ports on my FW13 AMD. The monitor can be externally-powered or power from the USB port, and either works.
Been wishing this worked correctly since I got my FW16 - is their any more comment to be made on this? Any progress or are we just “out of luck” for the external monitor thing without buying a half dozen on amazon and hoping for the best?
Agreed. We have a few AMD 13 and 16’s in our office as a trial before Win10 goes EOS. I know some of team have usb powered monitors. Not a show-stopper, but will be a frustration for our users we’d need to deal with.
Yeah not that this helps much but I have tried 3 different portable monitors, and I have 3 different Ryzen devices (FW13, Asus rog ally w/ 7840u and GPD win max 2 with 8840u) and the framework is the only one with this behaviour. I’m guessing some kind of bios or firmware thing?
Seems like the Kernal version 6.9+ seems to have issues with USB-C devices but 6,8.9 and below don’t seem to have the issue.
For some people powering the display separate from the laptop without using DP/HDMI Alt mode gets external displays working.
For me leaving the framework 65 watt usb-c power plugged in, plugging in the external monitor then unplugging the framework power cord and replugging it back in allows it to be detected on Fedora 41. Can’t speak for if any of the workarounds work for Windows.