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.
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? We probably don't need a num/den pair for it, it's not like panels
advertise fractional VRR ranges (right?).
Fun fact: vrr_range is exposed today over debugfs for IGT testing
https://elixir.bootlin.com/linux/v7.3-rc5/source/drivers/gpu/drm/drm_debugfs.c#L586
Thanks,
Leo
>
>
> -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer
> https://redhat.com \ Libre software enthusiast
