Trigger 6 clock config

[rhgndf]

I think I figured out partially what the unknowns 8 and 10 mean in the Trigger 6 video mode struct:

u16 offset;
u16 unknown9;
u8 multiplier;
u8 clock_base;

Example where clock_base = 0, the base clock is 1.25MHz

Mode: 640*480
Data: [8c 00][e8 03][14][00]
Clock: 25175 = 0x14 * 1250 + 0x8c * 1.25

Example where clock_base = 1, the base clock is 5MHz

Mode: 1400*1050
Data is: [5e 01][e8 03][18][01]
Clock is: 121750 = 0x18 * 5000 + 0x15e * 5

Example where clock_base = 2, the base clock is 2.5MHz

Mode: 1360*768
Data: [c8 00][e8 03][22][02]
Clock: 85500 = 0x18 * 2500 + 0xc8 * 2.5

Example where clock_base = 3, the base clock is 10MHz

Mode: 2560*1200
Data: [52 03][e8 03][1a][03]
Clock: 268500 = 0x1a * 10000 + 0x352 * 10

But there are some modes which are off by one? Not sure why. Mode: 38402160 Data: [bb 02][e8 03][1d][03] Clock calculated: 296990 = 0x1d 10000 + 0x2bb 10 Clock actual: 297000 = 0x1d 10000 + 0x2bc * 10

Unknown 9 seems to be always 1000, maybe it has something to do with the ratios of the both values to be multiplied by which are also 1000?

For Unknown 11, I have not fully checked but this might be the meaning when comparing mode values with https://tomverbeure.github.io/video_timings_calculator: 0: DMT 1: CVT-RB 512: CVT

[cyrozap]

I think I figured out partially what the unknowns 8 and 10 mean in the Trigger 6 video mode struct:

Thank you for doing this, I really appreciate your efforts!

Example where clock_base = 0, the base clock is 1.25MHz

If we assume the main base clock is 1.25 MHz, then based purely on the values you've presented here, the clock_base value looks like it may actually be a bit field to enable some clock multipliers, where bit 0 enables an ×4 multiplier and bit 1 enables an ×2 multiplier.

And with this in mind, I think the formula is more like (offset + unknown9 × multiplier) × base clock.

But there are some modes which are off by one? Not sure why.

I have no evidence to support this, but my best guess is that this may have been caused by rounding errors in whatever code generated the video mode data (the code may either be in the firmware itself or in the program that builds the firmware images). I've seen a similar phenomenon in UART baudrate/clock divisor calculation code: when all the calculations are performed using integer operations and no care has been taken to preserve the precision, intermediate results get truncated/rounded toward zero early, causing the result to be off by one (or more). And the errors usually don't get noticed because the error is small enough that it doesn't really matter in practice--for instance, the error in the example you provided is only approximately 0.003367% (33.67 ppm), which I assume is rather tiny for an HDMI pixel clock.

For Unknown 11, I have not fully checked but this might be the meaning when comparing mode values with https://tomverbeure.github.io/video_timings_calculator:

The values make me think this might be a bit field, but with only three distinct values seen in packet captures (same as what you've seen: 0, 1, and 512), it's difficult to say for certain that that's the pattern.

[rhgndf]

With this it means custom modes might be supported! Maybe this can be 'overclocked'.

[cyrozap]

With this it means custom modes might be supported!

That's probably true! The control request that sets the video mode specifies all the parameters, which wouldn't be necessary if only certain modes were supported. With some analysis of the pre-configured video modes and some experimentation, we could probably derive an algorithm to calculate PLL/clock configuration parameters dynamically for arbitrary video modes.

Maybe this can be 'overclocked'.

I wouldn't bet on that. Pixel clocks up to at least 297 MHz are already supported, and that's already close to the max (340 MHz) that can be done using versions of HDMI below 2.0, which requires link training in order to achieve higher speeds (max 600 MHz). And even if it was possible to overclock the signal, there's no reason to assume there would be enough memory bandwidth to support transmitting so much pixel data at once.

[rhgndf]

In http://www.mct.com.tw/edcontent_d.php?lang=en&tb=1&id=80 it mentions needing a transmitter chip for 4K. I think maybe it's possible to overclock the VGA or HDMI without a transmitter chip.

[cyrozap]

For Unknown 11, I have not fully checked but this might be the meaning when comparing mode values with https://tomverbeure.github.io/video_timings_calculator:

For the 3840 x 2160 @ 30 Hz video mode, the value of "Unknown 11" for that configuration is "1", but its timings match up with CEA-861 (not CVT-RB) so I don't think that field indicates the standard the configuration comes from. And now that I look at my packet captures a bit closer, maybe "Unknown 11" isn't a single 16-bit bit field, but two 8-bit integer values: The first byte is always either zero or one, and the second is always either zero or two.

[rhgndf]

I noticed this discrepancy too, I guess statically analyzing the wireshark captures can only get us so far.