On Wed, 23 Sep 2026, Nicolas Frattaroli wrote:
> On Wednesday, 23 September 2026 11:51:45 Central European Summer Time Michel > Dänzer wrote: > > On 9/21/26 17:51, Nicolas Frattaroli wrote: > > > > > > + * .. _VRR-MIN-NUMERATOR: > > > + * > > > + * "VRR_MIN_NUMERATOR": > > > + * Default &drm_crtc integer property forming the numerator of a > > > + * numerator/denominator pair of a frame rate to set as the > > > minimum VRR > > > + * target rate. Set to 0 to disable. > > > + * > > > + * "VRR_MIN_DENOMINATOR": > > > + * Default &drm_crtc integer property forming the denominator of a > > > + * numerator/denominator pair of a frame rate to set as the > > > minimum VRR > > > + * target rate. If :ref:`VRR_MIN_NUMERATOR <VRR-MIN-NUMERATOR>` is > > > not > > > + * zero, it must be non-zero. > > > + * Otherwise, must also be zero. > > > + * > > > + * .. _VRR-MAX-NUMERATOR: > > > + * > > > + * "VRR_MAX_NUMERATOR": > > > + * Default &drm_crtc integer property forming the numerator of a > > > + * numerator/denominator pair of a frame rate to set as the > > > maximum VRR > > > + * target rate. Set to 0 to disable. > > > + * > > > + * "VRR_MAX_DENOMINATOR": > > > + * Default &drm_crtc integer property forming the denominator of a > > > + * numerator/denominator pair of a frame rate to set as the > > > maximum VRR > > > + * target rate. If :ref:`VRR_MAX_NUMERATOR <VRR-MAX-NUMERATOR>` is > > > not > > > + * zero, it must be non-zero. Otherwise, must also be zero. > > > */ > > > > Is there a reason that DENOMINATOR must be 0 when the corresponding > > NUMERATOR is? 0 divided by any number is still 0. > > No, I think that's an arbitrary convention I settled on and don't enforce. I > guess it should be "Otherwise, may also be zero", because the only situation > I'm making userspace avoid is x/0 where x != 0. > > > > Either way, should these rules be enforced in > > > drm_atomic_crtc_set_property? > > > > Or rather in atomic_check. > > Due to complicating factors like EDID, CinemaVRR, and QMS TFRmin/TFRmax, > checking > the properties for sensible values is done in the HDMI state helpers at the > moment. > > If/when there is a similar mechanism for DP, we can probably factor the common > parts out. I really do hope all drivers (including those that don't use the > HDMI > state helpers) can at least share the hdmi_validate_vrr() logic, but I haven't > factored this out into an exported function yet because I don't know how > similar > the DisplayPort-equivalent mechanisms requirements are, or how much of the > state > derivation non-state-helper drivers (i.e. i915 and amdgpu) need. > > Kind regards, > Nicolas Frattaroli Thanks for bringing up support for VRR features on DP. Concerning the frame rate limits themselves, as I mentioned in patch [02/25] I don't think there's a reason to limit the validation to HDMI. There is in fact an analog of QMS for DP, called DP-FAVT mode - this is quite a bit more streamlined than QMS and the validation should be simpler. Would be nice to see these properties support that as well (this was briefly discussed at DisplayNext HackFest, if I understood access to the DP spec is the main blocker here?). > > >
