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.