kms_color_chamelium - comparison is way too lax
Cc: @KunalJoshi95
kms_color_chamelium uses the following call to do the dump vs reference comparison:
chamelium_frame_match_or_dump(data->chamelium, port,
frame_fullcolors, &fbref,
CHAMELIUM_CHECK_ANALOG);
which causes this comparison function to be run:
/** igt_check_analog_frame_match:
* @reference: The reference cairo surface
* @capture: The captured cairo surface
*
* Checks that the analog image contained in the chamelium frame dump matches
* the given framebuffer.
*
* In order to determine whether the frame matches the reference, the following
* reasoning is implemented:
* 1. The absolute error for each color value of the reference is collected.
* 2. The average absolute error is calculated for each color value of the
* reference and must not go above 60 (23.5 % of the total range).
* 3. A linear fit for the average absolute error from the pixel value is
* calculated, as a DAC-ADC chain is expected to have a linear error curve.
* 4. The linear fit is correlated with the actual average absolute error for
* the frame and the correlation coefficient is checked to be > 0.985,
* indicating a match with the expected error trend.
*
* Most errors (e.g. due to scaling, rotation, color space, etc) can be
* reliably detected this way, with a minimized number of false-positives.
* However, the brightest values (250 and up) are ignored as the error trend
* is often not linear there in practice due to clamping.
*
* Returns: a boolean indicating whether the frames match
*/
We can see from the description it's designed to deal with the issues caused by doing DAC-ADC chain, which is valid for analog outputs, e.g.: VGA.
I think the checks performed here are way too lax. Error caused by pipe rounding/truncation for gamma/degamma on digital connectors should not be even close.
New comparison method target should be introduced that specifically targets this rounding behavior which should be just off-by-one.