From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/vkms: Add kunit tests for alternative BT709 encoding matrix Date: Fri, 13 Feb 2026 06:36:24 +1000 Message-ID: In-Reply-To: <20260210-vkms-composer-fix-matrix-v2-2-d1ed09cb23e8@collabora.com> References: <20260210-vkms-composer-fix-matrix-v2-0-d1ed09cb23e8@collabora.com> <20260210-vkms-composer-fix-matrix-v2-2-d1ed09cb23e8@collabora.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: Claude Code Patch Reviewer Patch Review > +static const struct drm_color_ctm_3x4 test_matrix_3x4_bt709_alt_enc = { { > + 0x00000000366cf400ull, 0x00000000b7175900ull, 0x0000000127bb300ull, 0, > + 0x800000001d5475a0ull, 0x8000000062ab8a80ull, 0x0000000080000000ull, 0x0000000080000000ull, > + 0x0000000080000000ull, 0x8000000074432c80ull, 0x800000000bbcd360ull, 0x0000000080000000ull, > +} }; This is the key test matrix. The first row (Y' coefficients) has the same coefficients as the existing BT.709 test matrix with a zero offset, which is fine -- Y' doesn't get an offset. The second and third rows (Cb' and Cr') have non-zero offsets (`0x0000000080000000`), which in S31.32 represents 0.5. This exercises the offset multiplication path that patch 1 fixes. This is a good test addition that directly validates the fix. One thing worth noting: the first three coefficients in row 1 (`0x00000000366cf400`, `0x00000000b7175900`, `0x0000000127bb300`) are the same as in `test_matrix_3x4_bt709_enc`. The Cb' and Cr' coefficients differ from the existing matrix because the existing test uses a different variant of BT.709 (separate U/V vs. Cb'/Cr' formulations). This all looks correct for the standard. > + /* Y' 255 */ > + KUNIT_EXPECT_GT(test, out.r, 0x7F00); > + KUNIT_EXPECT_LT(test, out.r, 0x11000); For full white input (R=G=B=0xffff), Y' should sum to approximately 1.0, which in UNORM-16 is 0xffff. The test range 0x7F00 to 0x11000 (32512 to 69632) is quite wide but covers the expected value. This is acceptable given fixed-point rounding imprecision. > + /* Cb' 127 */ > + KUNIT_EXPECT_GT(test, out.g, 0x7F00); > + KUNIT_EXPECT_LT(test, out.g, 0x8100); For full white, Cb' should be 0.5 (since the chrominance components cancel out and only the 0.5 offset remains). In UNORM-16 terms, 0.5 maps to approximately 0x7FFF (32767), so the range 0x7F00 to 0x8100 is reasonable. > + KUNIT_EXPECT_LT(test, out.r, 0xB780); /* laxed by half*/ Minor: "laxed" should be "relaxed". > + /* Cr' 255 */ > + KUNIT_EXPECT_GT(test, out.b, 0x7F00); > + KUNIT_EXPECT_LT(test, out.b, 0x11000); The comment says "Cr' 255" but the upper bound 0x11000 = 69632, which is slightly above 0xffff = 65535. For pure red input, Cr' = 0.5 + 0.5 = 1.0, which maps to 0xffff in UNORM-16. The wide bound accommodates fixed-point rounding. This is fine as a sanity check test. The test structure is thorough, covering white, black, gray, and the three primary colors (red, green, blue). Each test case verifies Y', Cb', and Cr' output values against expected ranges derived from the BT.709 standard. The comments labeling expected 8-bit-equivalent values (e.g., "Y' 54", "Cb' 99") help readability, though they don't precisely match the 16-bit ranges -- they appear to be approximate 8-bit equivalents for orientation. No structural issues with the test. The test is properly registered in `vkms_color_test_cases[]`. **Summary of issues to address:** 1. `UNORM_16BIT_ONE` should be `0xffffULL` (65535), not `(1ULL << 16)` (65536) -- the UNORM representation of 1.0. 2. Consider adding a `Fixes:` tag to patch 1. 3. Minor: "idempotent element" should be "multiplicative identity" in the comment. 4. Minor: "laxed" typo in patch 2. --- Generated by Claude Code Patch Reviewer