Re: [PATCH 0/4] drm/i915: Work harder to enable VRR based refresh rate changes on eDP

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Mon, Jun 15, 2026 at 03:30:00PM +0200, Michel Dänzer wrote:
> On 6/15/26 15:06, Ville Syrjälä wrote:
> > On Mon, Jun 15, 2026 at 11:08:59AM +0200, Michel Dänzer wrote:
> >> On 6/15/26 11:06, Michel Dänzer wrote:
> >>> On 6/12/26 16:41, Ville Syrjala wrote:
> >>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>>
> >>>> Tweak the eDP fixed mode selection algorithm to allow
> >>>> userspace to do refresh rate changes on VRR capable
> >>>> eDP panels without full modesets.
> >>>>
> >>>> Ville Syrjälä (4):
> >>>>   drm/modes: Add DRM_MODE_MATCH_TIMINGS_VRR
> >>>>   drm/i915: Pass the full atomic state to .compute_config()
> >>>>   drm/i915/panel: Adjust intel_panel_compute_config() calling convention
> >>>>   drm/i915/panel: Attempt VRR based refresh rate change for
> >>>>     !allow_modeset
> >>>
> >>> What's the motivation for this approach?
> >>>
> >>> Per https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/5091#note_2784749 , it comes as a bit of a surprise. The approach we've been discussing at display hackfests instead is to add properties for controlling the maximum & minimum refresh rates.
> > 
> > This has nothing to do with limiting the VRR range. What we're doing
> > here is selecting the actual timings to drive an internal laptop panel,
> > given some random cooked up modeline from userspace.
> 
> This use case would be covered by setting the same values for both properties.

It's all irrelevant here. We might not even have VRR enabled in this
case. All we want is to set the mode (or something close enough) to what
userspace has requested.

> 
> (There are other use cases where changing mode alone isn't enough though, e.g. involving the compositor setting a narrow range between maximum & minimum refresh rate)
> 
> 
> > For non-VRR panels we just pick the fixed mode whose refresh rate is closest to the
> > user specified mode, and reject the commit if it's not close enough (<= 1 Hz).
> 
> Sounds like that wouldn't be good enough for some video use cases I'm afraid.
> 
> 
> >>> While the approach in this series could be considered an alternative for the maximum, AFAICT it doesn't allow enforcing a minimum refresh rate which differs from the maximum and default minimum.
> > 
> > The timings specify the absolute max refresh rate you can achieve. So
> > a separate max VRR refresh rate knob would be mostly redundant, but as
> > we've discussed before, it could have its uses for the non-integer
> > vtotal use cases (CMRR in Intel parlance).
> 
> None of that addresses the lack of control of the minimum refresh range.

We've been over this before. Yes, a new property would be needed to
limit the min refresh rate if someone wants to do that.

-- 
Ville Syrjälä
Intel