[PATCH RFC 13/25] drm: Add VRR target frame rate properties

[Michel Dänzer]

On 9/29/26 16:34, Leo Li wrote:
> 
> 
> On 2026-09-28 04:10, Michel Dänzer wrote:
>>>> You can picture VRR limiting as always being active, but with a limit rational
>>>> of 0 it uses the display's limit as per the EDID, which is what unlimited game
>>>> mode is. So with how it's implemented right now in hdmi_validate_vrr(), your
>>>> example would set a maximum target, but leave the minimum at whatever the
>>>> display defaults to.
>>>>
>>>> Now that I'm thinking through this, a possible problem is that
>>>> drm_crtc_helper_vrr_is_fixed_rate() operates on the user supplied limits, but
>>>> if the display supplied lower limit is equal to the user supplied upper limit,
>>>> then we have a fixed rate scenario without recognising it as such. I think I
>>>> need to have a ponder on what the least surprising behaviour for userspace
>>>> is in that instance. The display limit stuff gets a bit complex due to
>>>> CinemaVRR and QMS TFRmin/TFRmax.
>>>>
>>>> I'll improve the documentation on the next revision to make the meanings more
>>>> explicit.
>>> Perhaps a simple way is to require simultaneous setting MIN and MAX pairs?
>>> IOW, require userspace to set MIN and MAX simultaneously to >0, or =0. For example:
>>>
>>> if ((vrr_min_n == 0 || vrr_min_d == 0 ||
>>>      vrr_max_n == 0 || vrr_max_d == 0) &&
>>>     (vrr_min_n > 0 || vrr_max_n > 0))
>>> 	return -EINVAL;
>>> That way, it's never ambiguous what userspace has requested for the range.
>>> They can copy the EDID supported range if they don't care about limiting one side, rather than leaving it at 0.
>> Determining the actual limits can be non-trivial (though I guess that might be fine as long as libdisplay-info can work them out), if user space gets them wrong, it might accidentally apply a narrower limit than intended.
>>
>>
>>> It's then also clear if they requested a static Hz.
>> I do see the benefit of your suggestion for this though.
> 
> Xaver and I were chatting about this at XDC, and yeah it'll be difficult to match KMD's monitor range, especially if KMD decides to patch it with quirks and whatnot.

That's a good point.


> Since we are handing compositors control over vrr range, does it sound sensible to expose KMD's monitor range as a read-only property pair on the drm connector?

Sounds good to me, I actually had a similar idea after sending my previous post above. :)

(I have vague recollection of something like this having been suggested before, can't remember by whom / where / when though)


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast