Skip to content

Incorrect vback porch width on 320x240@60, due to not using CVT_MIN_V_BPORCH

When I run cvt 320 240 60, I get result:

# 320x240 59.52 Hz (CVT 0.08M3) hsync: 15.00 kHz; pclk: 6.00 MHz
Modeline "320x240_60.00"    6.00  320 336 360 400  240 243 247 252 -hsync +vsync

(As a sidenote, the hsync start of 336 is also incorrect, it should be 328. another case of #6 (closed).)

The vtotal of 252 is incorrect; https://tomverbeure.github.io/video_timings_calculator returns a value of 253. The bug arises because you calculate vsync_and_back_porch using vsync + CVT_MIN_V_PORCH instead of vsync + CVT_MIN_V_BPORCH (link):

        /* 9. Find number of lines in sync + backporch */
        if (((int) (CVT_MIN_VSYNC_BP / hperiod) + 1) <
            (vsync + CVT_MIN_V_PORCH))
            vsync_and_back_porch = vsync + CVT_MIN_V_PORCH;
        else
            vsync_and_back_porch = (int) (CVT_MIN_VSYNC_BP / hperiod) + 1;

The PDF says you should use V_BPORCH:

IF (V_SYNC_BP < V_SYNC_RND + MIN_V_BPORCH)
    V_SYNC_BP = V_SYNC_RND + MIN_V_BPORCH

Which brings us to the value of MIN_V_BPORCH. Currently libxcvt uses #define CVT_MIN_V_BPORCH 6, which matches the PDF, tomverbeure, and Apple's IOGraphics. Unfortunately for some reason, the spreadsheet uses a value of 7, resulting in generating a vtotal of 254. I'm going to assume our current value of MIN_V_BPORCH=6 is correct. In my local copy of the spreadsheet, I've even changed the value to 6 (against the spreadsheet's loud protests that the value must equal 7).

Just as a sidenote, I'd also rename CVT_MIN_V_PORCH to CVT_MIN_V_FPORCH to reduce the likelihood of confusing it for a back porch value (like how this bug happened) in the future. This matches the spreadsheet but not the PDF.

Future steps

Should I file a pull request? What about renaming to CVT_MIN_V_FPORCH?

I think libxcvt would benefit from a unit test suite, which runs libxcvt_gen_mode_info on hand-picked resolutions, and verifies the resulting modelines match "golden truth" values saved from tomverbeure or the spreadsheet. Perhaps it could also automatically generate resolutions, calculate modelines, and compare them against an alternative CVT implementation (like my recent https://codeberg.org/nyanpasu64/auto-modeline/src/branch/cvt/src/cvt.rs, though this is in Rust and difficult to integrate into a C/Meson project).

I think Meson has support for unit tests (https://mesonbuild.com/Unit-tests.html). I know PipeWire uses Meson and has a unit test suite too. I'm not sure how it sets up their tests. Do they use meson test? Is it one executable for all tests, one executable per test, or (IIRC, confusingly) several executables with multiple tests each?

Links