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: writeback: Document behaviour for framebuffer size mismatch Date: Thu, 04 Jun 2026 12:17:50 +1000 Message-ID: In-Reply-To: <20260602191754.79047-1-derek.foreman@collabora.com> References: <20260602191754.79047-1-derek.foreman@collabora.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Overall Series Review Subject: drm: writeback: Document behaviour for framebuffer size mismatch Author: Derek Foreman Patches: 1 Reviewed: 2026-06-04T12:17:50.607491 --- This is a single documentation-only patch (v2) to the DRM writeback connect= or subsystem. It adds six lines of kernel-doc commentary to the `WRITEBACK_= FB_ID` property documentation in `drm_writeback.c`, specifying what should = happen when the writeback framebuffer dimensions differ from the attached C= RTC dimensions. The patch is well-motivated: the existing documentation left this behavior = entirely undefined, which is a problem for both driver implementers and use= rspace (compositors like Weston). The chosen policy =E2=80=94 allow scaling= , forbid cropping, and require failure over partial fills =E2=80=94 is reas= onable and pragmatic: - **Scaling** is the natural operation for hardware with scaler blocks in t= he writeback path. - **Cropping** is correctly excluded since there's no property to specify a= crop origin. - **Failure over partial fill** is the safe default, preventing garbage dat= a in the output buffer. The v2 change (making it explicit that partial fills must not occur) is a g= ood improvement. No functional code changes, no risk of regressions. This is straightforward= UAPI documentation clarification. **Verdict: Looks good.** Minor wording nit below, but nothing blocking. --- Generated by Claude Code Patch Reviewer