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/display: Fix gamma 2.2 colorop TFs Date: Fri, 13 Mar 2026 14:43:47 +1000 Message-ID: In-Reply-To: <20260311211837.2482799-1-alex.hung@amd.com> References: <20260311211837.2482799-1-alex.hung@amd.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/amd/display: Fix gamma 2.2 colorop TFs Author: Alex Hung Patches: 2 Reviewed: 2026-03-13T14:43:47.091244 --- This is a single-patch fix that corrects the gamma 2.2 transfer function as= signments in the AMD display colorop code. The fix is straightforward, well= -motivated by a bug report, and already has a `Tested-by` tag from the KDE = compositor developer who reported the issue. The change is **correct**. The existing code had `GAMMA22` and `GAMMA22_INV= ` swapped relative to what degamma/shaper/blend operations require. Looking= at the pattern of the other transfer functions in the same lists: - **degamma** and **blend** use linearizing (EOTF) curves: `SRGB_EOTF`, `PQ= _125_EOTF`, `BT2020_INV_OETF` - **shaper** uses de-linearizing (inverse EOTF / OETF) curves: `SRGB_INV_EO= TF`, `PQ_125_INV_EOTF`, `BT2020_OETF` Per the header documentation (`drm_colorop.h:116-117`), `GAMMA22` "applies = a power curve with gamma value of 2.2" =E2=80=94 i.e., it linearizes gamma-= encoded values (an EOTF-like operation). Its inverse `GAMMA22_INV` de-linea= rizes. So `GAMMA22` belongs with degamma/blend, and `GAMMA22_INV` belongs w= ith shaper =E2=80=94 exactly what this patch does. No concerns with the patch. It should be safe to apply. --- Generated by Claude Code Patch Reviewer