Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm: __drm_atomic_helper_set_config unconditionally disables VRR for legacy clients --
commit 353fccdd37726114a8ead2ac16a0d6cf9e239631 Author: Nicolas Frattaroli <[email protected]> drm/atomic: Disable VRR in helper_set_config This commit explicitly sets crtc_state->vrr_enabled to false in __drm_atomic_helper_set_config. The goal is to prevent a non-functional KMS fbdev console if a DRM client exits without properly cleaning up its VRR state. > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index 9bb761eda59f4..1d3c35f7788eb 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -2051,6 +2051,8 @@ int __drm_atomic_helper_set_config(struct drm_mode_set > *set, > > crtc_state->active = true; > > + crtc_state->vrr_enabled = false; > + [Severity: High] Does this unconditionally disable VRR for legacy clients that use DRM_IOCTL_MODE_SETCRTC? If a legacy KMS client (like X.org) enables VRR via DRM_IOCTL_MODE_OBJ_SETPROPERTY and later calls DRM_IOCTL_MODE_SETCRTC (for DPMS, panning, or resolution changes), won't this unconditionally clear their persistent state by setting crtc_state->vrr_enabled to false? Additionally, can this cause unnecessary full hardware modesets? If drm_atomic_helper_check_modeset() sees vrr_enabled transition from true to false, it sets mode_changed = true. This could force a slow, full modeset (with screen blanking/flicker) during what would normally be a fast, seamless display update. > ret = drm_atomic_set_crtc_for_plane(primary_state, crtc); > if (ret != 0) > return ret; -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=25
