Elaboration on porch timing trick: Most displays operate on a fixed pixel clock, with some subdivision of it used for horisontal and vertical refresh frequencies. Let’s examine, for example, 3840x2160 at 90 Hz, using CVT Reduced Blanking version 2.
$ ./cvt12 3840 2160 90 -b -v
1: [V FIELD RATE RQD] : 90.000000
2: [H PIXELS RND] : 3840.000000
2.5: [ASPECT_RATIO] : 16:9
2.5: [V SYNC] : 5.000000
3: [LEFT MARGIN (PIXELS)] : 0.000000
3: [RIGHT MARGIN (PIXELS)] : 0.000000
4: [TOTAL ACTIVE PIXELS] : 3840.000000
5: [V LINES RND] : 2160.000000
6: [TOP MARGIN (LINES)] : 0.000000
6: [BOT MARGIN (LINES)] : 0.000000
7: [INTERLACE] : 0.000000
8: [H PERIOD EST] : 4.931070
9: [Actual VBI LINES] : 93.286041
9: [VBI LINES] : 94.000000
10: [Minimum VBI Lines] : 34.000000
10: [ACT VBI LINES] : 94.000000
11: [TOTAL V LINES] : 2254.000000
12: [TOTAL PIXELS] : 4000.000000
13: [Non-rounded PIXEL FREQ] : 811.440002
13: [ACT PIXEL FREQ] : 811.439026
14: [ACT H FREQ] : 202.859756
15: [ACT FIELD RATE] : 89.999886
16: [ACT FRAME RATE] : 89.999886
20: [H BACK PORCH] : 80.000000
21: [H SYNC RND] : 32.000000
22: [H FRONT PORCH] : 48.000000
23: [V FRONT PORCH] : 23.000000
# 3840x2160 @ 90.000 Hz Reduced Blank (CVT) field rate 90.000 Hz; hsync: 202.860 kHz; pclk: 811.44 MHz
Modeline "3840x2160_90.00_rb" 811.44 3840 3888 3920 4000 2160 2183 2188 2254 +hsync -vsync
In this example, we have 4000 pixels per scanline, of which only 3840 are used; only they are actually read out of the line buffer in the ANX7530, for instance. The unused cycles are spent on back porch, sync pulse, and front porch (rows 20-22). However, in common readout modes (e.g. not the Command Mode mentioned above), there’s nothing in the signalling to distinguish the porch and active regions; it’s merely that the active regions end up displayed.
If we have, for instance, optics that only manage to display 80% of the screen, but are shifted so the optical center may end up in a variety of positions on the screen, we can reduce the active region by changing our front and back porch. For instance, we could grow the front porch and reduce the active pixels, adding a black band on the left side of the panel and reducing the input pixel rate required. We could thus tell the DisplayPort receiver, which is rate limited to 720MHz pixel clock, that the panel is smaller than it really is. The panel would receive the same signal, only the band seen as image by the panel but porch by the bridge chip would be entirely black. The neat thing about this porch tuning is that it has no alignment limits and could be done symmetrically on both displays without issue.
We won’t reach exactly 720MHz effective (active/visible) pixel clock because we still need to spend some time on sync and audio transfer (which is typically done during the vertical retrace in DisplayPort - a whopping 376000 cycles in this example, which is admittedly too fast at 811.44MHz). But by altering effective horisontal resolution between buses while keeping horisontal sync frequency, we can probably get pretty far.
If we work backwards from this mode and HBR2 transfer rate we get a total horisontal pixel count of 5.4e948/10/24/90/2254 = 3549 (and some change) instead of 4000. If we then assume we can squeeze the horisontal sync and porches into just 13 cycles of the pixel clock (this is only between GPU and DP receiver, so not restricted by panel limits) instead of 80+32+48=160, we reach a possible resolution of 3536 (221*16), which is 92% of 3840, easily over the 80% horisontal utilisation suggested in the FAQ (under pixels per degree). On the 8K similar tweaks are possible but should preferably also be done in the scaler, to get the most out of what pixels are sent.