3 ms·

>DisplayPort does away with all that legacy. You wish. DP sends exactly same bytes DVI does (blanking and all), just broken up into packets.

by rasz 3y ago

fanf2 3y ago
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.
- rasz 3y ago
  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.
  - nyanpasu64 3y ago
    I think that you can actually transmit audio, or other displays' signals (DisplayPort Multi-Stream Transport), in place of stuffing symbols.
    - rasz 3y ago
      Afaik its a no-no zone. You can only use blanking periods.
      - nyanpasu64 3y ago
        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.
  - willis936 3y ago
    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.
    - rasz 3y ago
      That optional infrastructure on the receiving end is already provisioned in the standard in form of eDP PSR (self refresh).
      - tremon 3y ago
        Panel Self-Refesh is an optional feature, is it not?
        rasz 3y ago
        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?

>DisplayPort does away with all that legacy. You wish. DP sends exactly same bytes DVI does (blanking and all), just broken up into packets.

by rasz 3y ago

>DisplayPort does away with all that legacy. You wish. DP sends exactly same bytes DVI does (blanking and all), just broken up into packets.

fanf2 3y ago

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.

rasz 3y ago
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.
- nyanpasu64 3y ago
  I think that you can actually transmit audio, or other displays' signals (DisplayPort Multi-Stream Transport), in place of stuffing symbols.
  - rasz 3y ago
    Afaik its a no-no zone. You can only use blanking periods.
    - nyanpasu64 3y ago
      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.
- willis936 3y ago
  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.
  - rasz 3y ago
    That optional infrastructure on the receiving end is already provisioned in the standard in form of eDP PSR (self refresh).
    - tremon 3y ago
      Panel Self-Refesh is an optional feature, is it not?
      - rasz 3y ago
        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?