From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: Add new general DRM property "color format" Date: Wed, 25 Mar 2026 06:44:25 +1000 Message-ID: In-Reply-To: <20260324-color-format-v11-0-605559af4fb4@collabora.com> References: <20260324-color-format-v11-0-605559af4fb4@collabora.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Overall Series Review Subject: Add new general DRM property "color format" Author: Nicolas Frattaroli Patches: 26 Reviewed: 2026-03-25T06:44:25.872599 --- This is a well-structured v11 series adding a "color format" DRM connector property allowing userspace to explicitly request RGB, YCbCr 4:4:4, 4:2:2, or 4:2:0 output. The series is mature with multiple reviewed-by tags and extensive testing across i915, amdgpu, and rockchip hardware. The architecture is sound: a new `drm_connector_color_format` enum with AUTO default, framework support in atomic helpers, bridge chain format selection, HDMI state helper integration, and driver implementations. **Key strengths:** - Clean separation of `drm_output_color_format` (internal) vs `drm_connector_color_format` (UAPI with AUTO) - Errors are bubbled up to userspace rather than silently falling back, which is the right design - Good KUnit test coverage - Well-documented AUTO semantics per display protocol **Key concerns:** - Several instances of uninitialized variable usage in switch statements - Redundant `hdmi_colorformats` / `dp_colorformats` definitions - i915 HDMI path drops the `has_hdmi_sink` check from the YCbCr420 fallback path - Some duplicated format conversion switch-case logic that could benefit from a shared helper --- --- Generated by Claude Code Patch Reviewer