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/amd: fix force_yuv420/422_output being ignored Date: Mon, 16 Mar 2026 11:48:52 +1000 Message-ID: In-Reply-To: <20260315223307.45807-5-johanneswueller@gmail.com> References: <20260315223307.45807-1-johanneswueller@gmail.com> <20260315223307.45807-5-johanneswueller@gmail.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review **Correctness concern:** The original code gated `force_yuv420_output` on `drm_mode_is_420_also()` and `force_yuv422_output` on `DRM_COLOR_FORMAT_YCBCR422`. These guards existed to prevent forcing a pixel encoding the display genuinely cannot accept. Removing them means: ```c else if (aconnector && aconnector->force_yuv420_output) timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420; ``` This will now force YCbCr 4:2:0 even for modes that are not 420-capable at all (not just "420_also" but completely 420-incompatible). This could cause a black screen or signal errors on displays that truly don't support 4:2:0 for a given mode. The commit message frames this as "the flag becomes ineffective" when the display doesn't advertise the capability, but the `force_` prefix in the debugfs attribute does suggest "force regardless." Still, this is a user-facing behavior change that removes safety checks. It would be better to either: 1. Gate on `edid_overridden` (only bypass the check when an override is active), or 2. Add a warning log when forcing an unadvertised encoding so users can diagnose issues. **Interaction with Patch 2:** This patch is listed as fixing issues with EDID overrides, but it unconditionally changes behavior for all displays, not just those with overrides. This seems like an overly broad change for the stated problem. --- Generated by Claude Code Patch Reviewer