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: detect panel type from DisplayID 2.x Date: Sat, 16 May 2026 11:17:30 +1000 Message-ID: In-Reply-To: <20260514065606.1151834-1-chen-yu.chen@amd.com> References: <20260514065606.1151834-1-chen-yu.chen@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: detect panel type from DisplayID 2.x Author: Chenyu Chen Patches: 5 Reviewed: 2026-05-16T11:17:30.013253 --- This 2-patch series adds DisplayID v2.x Display Parameters Data Block parsi= ng to detect LCD vs OLED panels, and wires it into amdgpu_dm as a fallback = panel type detection path. The general approach is sound: it fills a longst= anding TODO in the amdgpu_dm code. **However, there is a significant gap across the series:** `DRM_MODE_PANEL_= TYPE_LCD` is added to the UAPI header (`drm_mode.h`) but: 1. The `drm_panel_type_enum_list` in `drm_connector.c` is not updated to in= clude LCD, so the `panel_type` property enum doesn't recognize value 2. 2. The property-setting code at the end of `dm_set_panel_type()` is not upd= ated to expose LCD =E2=80=94 it only maps `PANEL_TYPE_OLED` =E2=86=92 `DRM_= MODE_PANEL_TYPE_OLED` and everything else =E2=86=92 `DRM_MODE_PANEL_TYPE_UN= KNOWN`. This means a DID2-detected LCD panel will correctly set `link->panel_type = =3D PANEL_TYPE_LCD` internally, but userspace will see `DRM_MODE_PANEL_TYPE= _UNKNOWN` from the property, and the enum property likely cannot even accep= t value 2. The new UAPI constant is effectively dead code. --- --- Generated by Claude Code Patch Reviewer