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
