Today I did a bit of playing around calculating the effective video pixel clock, when you pack a given number of pixels into a DisplayPort "Transfer Unit". A TU is block of 32 to 64 bytes, packed with pixel data and padding bytes. I guess that the ideas the use of TUs limits the depth of the FIFO required in the receiving DisplayPort sink, because a 64-byte the FIFO should be all you need.
It turns out that if you pack 11 pixels (33 bytes) into a 40 byte transfer unit it gives an effective pixel clock of 74.25 MHz (for one lane) or 148.5 MHz (for two lanes) and 297 MHz (when using four lanes). This is perfect for implementing standards-compliant 720p @ 60Hz, 1080p @ 60Hz and 2080p@30Hz, depending on how many lanes you chose to use.
Although blinding obvious in retrospect, it was hidden because DP is a complex spec with so much flexibility that it is hard to see the easiest implementation path. This is really neat because you don't have to rely on variable size TU packing, splitting pixels between TUs or generating 'fractions of a pixel' numbers within the data stream.
The upshot being that the Github project now includes a single-lane 720p colour bar test pattern, and should have a dual-lane 1080p one tomorrow (time willing).
In case somebody walking the same path finds themselves here I've attached a screen grab of my spreadsheet to this post. Yes, I know that this is not quite XKCD '.norm' format, but it is pretty close
- (
https://xkcd.com/2116/).