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ä <[email protected]> >>>> >>>> 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. (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. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
