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 11:08:59AM +0200, Michel Dänzer wrote:
> 
> Adding wayland-devel list for awareness, see also https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/5091.
> 
> 
> 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.

We pick the actual mode from the set of "fixed modes" (ie. the modes
that the panel/system itself has reported as supported via
EDID/VBT/ACPI/etc.). 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). For VRR panels we
can avoid that rejection part by adjusting the vtotal appropriately,
assuming the user specified mode's refresh rate is withing the
VRR range of the panel.

> > 
> > 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).

-- 
Ville Syrjälä
Intel