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 Fri, Jun 19, 2026 at 10:48:45AM +0200, Michel Dänzer wrote:
> On 6/18/26 20:39, Ville Syrjälä wrote:
> > On Tue, Jun 16, 2026 at 09:21:01AM +0200, Michel Dänzer wrote:
> >> On 6/15/26 15:06, Ville Syrjälä wrote:
> >>>
> >>> What we're doing here is selecting the actual timings to drive an internal laptop 
> >>> panel, given some random cooked up modeline from userspace.
> >>
> >> How can user space know what cooked-up modes it can (not) expect to work with this?
> > 
> > Without VRR support it can only expect modes that have the same refresh
> > rate as one of the modes on the connector's mode list to work.
> 
> This seems to contradict "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)" below.
> 
> 
> >>> 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).
> >>
> >> Can't programming different mode timings result in the panel blanking intermittently?
> > 
> > Userspace can specify that a modeset is not allowed, thus if the
> > driver can't achieve the refresh rate change without blinks the
> > commit will be rejected.
> 
> How can the refresh rate change without a modeset (without VRR)?

Given a capable eDP panel we can reprogram the dotclock/Mvid/Nvid
atomically so that the refresh rate changes from one frame to another.

-- 
Ville Syrjälä
Intel