8 ms·
DisplayPort: Taming the Altmode
- chx 3y ago> apparently, the protocol allows for building bidirectional DP devices, which is certainly idea-provoking https://dancharblog.wordpress.com/2020/05/10/bi-directional-usbc-dp-cables/ https://dancharblog.wordpress.com/2020/05/10/bi-directional-...
- dietr1ch 3y agoSo, does that mean that all the sketchy USB cable applies to DP ports too?
- chx 3y agoMy English sentence parser gave up. Could you please reword your question?
- dietr1ch 3y agoYeah, I dropped a word by rewriting it, but you can only edit it for so long So, does that mean that all the sketchy USB cable VULNERABILITIES apply to DP ports too?
- chx 3y agoYou can't transmit data through DisplayPort, so no. The blog post I linked has a list of cables which you can plug into a DisplayPort host and a USB C monitor and it'll transmit the video data. Some might add power and even data from other USB source(s). But that doesn't make DP carry data, no.
- edhelas 3y agoI'm always impressed by how well designed Display-Port is, as a connector and as a protocol.
- ianlevesque 3y agoI really want to feel that way too (particularly compared to HDMI) but I seem to have so many weird issues that just never existed with DVI. On my work issued M1 Studio for example my displays (bog standard Dell 4K) commonly come up at 30hz or don’t get detected at all until an unplug and replug. I’ve tried all manner of cables and adapters and it’s just not reliable.
- russelg 3y agoThis is a macOS issue. In my experience macOS handles DP much worse than windows. Windows will keep asking the device for its information, while macOS waits for the device to inform the OS. This can cause issues with monitor detection, as you're experiencing.
- feitingen 3y agoDoes macOS still not support DP-MST properly?
- ComputerGuru 3y agoProperly? I thought not at all.
- feitingen 3y agoApparently, if you connect two identical monitors to a mac via dp-mst, it will display the same image on both monitors. I'm not sure if it's intentional, but it is at least giving an image.
- p_l 3y agoDoesn't support on purpose, though on intel macs alternative OSes could use it. DDC is also fraught with peril when you want to change settings from OS on non-Apple display.
- philsnow 3y ago
- jagrsw 3y agoIn the spirit of times - does anybody know what room-temp supercoductors would do to the transmission lines, like DP/HDMI? Would 0 resistance have positive influence on signal degradation/coherence (ie. increasing maximum cable lengths or their reliability), or maybe it's already limited by various forms of capacitance/inductance or other problems in cables?
- Waterluvian 3y agoAssuming you could produce viable consumer cables that are superconductors, my understanding is that there would be no signal loss, so your hypothetical cable could have infinite length. Digital is digital so this would be true for any data use case. Maybe someone smarter can chime in about how electromagnetic interference affects or doesn’t affect a hypothetical “superconductor cable.”
- mycall 3y agoThe longer the cable, the longer duration loopback signals take. This can affect timing of any synchronous specification. If it is too long, it could be out of scope of the spec and thus stop working. Maybe you can solve this with a transceiver MITM device.
- Waterluvian 3y agoOh right I forgot about that! So yeah… probably longer than you’d need but not infinitely long. Unless the protocol is fine with it.
- Filligree 3y agoSuperconductors only have zero resistance when measured in DC. AC still faces impedance, high frequency AC like DisplayPort especially so.
- mschuster91 3y agoLine length would not be limited any more in theory, but it's not like you can do ridiculous length even with a HTSC wire. The most obvious factor is protocols, you can't get faster than light which means protocols with a tight response timeout won't work out. The second one is capacitance, as most transmission is something very closely resembling AC, so IIRC even at zero resistance you'd still have a capacitance between the lines and a resulting reactive power.
- jagrsw 3y agoIn the "old times" a video mode descriptor included things like "front porch", "sync width" and similar unpleasantries. I believe they're still used with DP/HDMI, as it's possible to play with "modelines" in Linux and adjust those params. My naive understanding is that it's a legacy thing from CRT times, where there was a need to allow for the electron gun to adjust itself for a new line/frame. Do those terms have still meaning in HDMI/DP/LCDs times, or they're preserved but serve no purpose now?
- toast0 3y agoCRT tvs with dvi-d and hdmi exist, where I'd imagine all those things in the mode line are still useful. I gather DisplayPort signaling is significantly different, however.
- 65a 3y agoI recently managed to overclock a pair of xreal air AR glasses (USB-C DP altmode based) to 90hz using custom modelines, so it's still relevant.
- formerly_proven 3y agoThe innovation of DP is that it's the first video standard to virtualize the physical interface of video. All standards before it directly represented the video timing on the physical layer (e.g. DVI/HDMI bit-clock = bit-depth × pixel clock). DP takes the same video signal (including blanking intervals) and chops it up into packets with some stuffing so as to not change average timing, then transmits them over fixed-rate physical links.
- projektfu 3y agoI had a WEGA driven by HDMI and overscan was important. The TV didn't fake it, the pixels were drawn outside the bezel, and they could be brought in by adjusting the picture. However, they were very distorted. Everything was fine when compensated for overscan, but some things like Amazon video's menu used every pixel and were cropped. I had never thought about overscan until I used that TV.
- 3y ago
- snvzz 3y agoDP is lauded as an open specification. I am sad to hear altmode is "semi-proprietary". A stain on this reputation.
- WhyNotHugo 3y agoI think that it’s mostly in comparison to HDMI. The latest versions of HDMI don’t really even allow open source implementations. It’s a shame that all these protocols are gradually closing themselves up. We’re evolving backwards.
- nuker 3y agoMacOS broke the Display Stream Compression (DSC) in Big Sur, and has not fixed it since. I can have 4k@144Hz in Catalina but only 4k@60Hz in Big Sur - Ventura. On the same hardware, applies to all Intel based macbooks. Tried support, geniuses, no luck.
- FireBeyond 3y agoI believe they broke it for the Pro Display XDR. I had the same. 4K 144Hz HDR10. When it came out people were wondering how they were driving it at 6K HDR10. If you can dial your monitor back to DSC 1.2 things get slightly better.... I could do 4K 120 SDR, or 75 HDR. Also applies to Mac Pro - my 2019 cheesegrater was affected, too.
- nuker 3y ago> they broke it for the Pro Display XDR What do you mean, they had to kill DSC for Pro Display XDR to work?
- Retr0id 3y agoThey had to kill it for Pro Display XDR to be a compelling upgrade.
- FireBeyond 3y agoAt the time of the release, people were wondering how the Pro Display had sufficient bandwidth to drive it. Big Sur came out at the same time. Everyone using monitors with DSC 1.4 to the extent of their monitors capabilities saw those capabilities crippled and remain crippled ever since. Those devices continued to work fine under Catalina. Downgrading DSC from 1.4 to 1.2 on those monitors gave "better" performance (i.e. higher than without DSC, and higher than they were with DSC 1.4 with Big Sur+). Hundreds or more bug reports were filed. This affected users of different Macs, different GPUs, different monitors. The only common thread was DSC 1.4 and Big Sur (Ventura, Monterey... this still hasn't been 'fixed'). Given that the Pro Display and Big Sur came out 'together', it's very hard not to draw the conclusion that Apple found "sufficient bandwidth to drive the Pro Display XDR" by making changes to their "DSC 1.4" implementation that only the Pro Display understands.