Hacker News Reader

Comment by rasz | Hacker News Reader

>DisplayPort does away with all that legacy.

You wish. DP sends exactly same bytes DVI does (blanking and all), just broken up into packets.

The important difference is that (like VGA) DVI and HDMI still dedicate particular physical wires to separate red, green, and blue channels. Display port does not shard individual pixels across multiple channels: all bits (all colours) of a pixel are sent on the same diffpair. If a DP link has multiple lanes then the bits of different successive pixels are sent on each lane.

This is great, but then they drop the ball by forcing garbage (“interspersed stuffing symbols”) between the packets instead of letting you use that BW.

I think that you can actually transmit audio, or other displays' signals (DisplayPort Multi-Stream Transport), in place of stuffing symbols.

Afaik its a no-no zone. You can only use blanking periods.

You may be correct (and I was mistaken in my previous post) for audio. The leaked (DP isn't really an open standard) DP-1.2.pdf on glenwing's site says that "The dummy stuffing data symbols during the video blanking periods (both vertical and horizontal) may be substituted either with main stream attributes data or a secondary-data packet", and the public 1.1a PDF indicates similarly.

MST is quite complicated and appears to interleave bytes from different video streams within 64-byte packets (rather than solely during blanking):

> The MTP (Multi-stream Transport Packet) is 64 link-symbol (1 byte of video data or special symbols) cycles (that is, 64 time slots) long, starting with MTP Header in the first time slot (or Time Slot 0), and is constantly transported regardless of the presence/absence of streams.

> The Payload Bandwidth Manager of each uPacket TX in the path from a DP Source to a target Sink device allocates time slots within the MTP to a VC (Virtual Channel) Payload to establish the virtual channel for transporting a stream.

You are not giving the full picture in this trade. The people making the spec knew the trade well. You add a lot of complexity to a receiver by forcing it to generate its own timing information from whatever video signal is sent. That work has to be done somewhere and it is most robust when done at the source.

That optional infrastructure on the receiving end is already provisioned in the standard in form of eDP PSR (self refresh).

Panel Self-Refesh is an optional feature, is it not?

Why isnt there an optional matching DP mode where you could just transfer screen data without timing? Why are you forced to sent fake blanking to PSR displays?

Reply on news.ycombinator.com