On 24.09.25 10:34, Ville Syrjälä wrote: > On Mon, Sep 15, 2025 at 03:37:07PM +0000, Derek Foreman wrote: >> On 9/15/25 5:01 AM, Michel Dänzer wrote: >>> On 12.09.25 15:45, Derek Foreman wrote: >>>> On 9/12/25 2:33 AM, Chuanyu Tseng wrote: >>>>> Introduce a DRM interface for DRM clients to further restrict the >>>>> VRR Range within the panel supported VRR range on a per-commit >>>>> basis. >>>>> >>>>> The goal is to give DRM client the ability to do frame-doubling/ >>>>> ramping themselves, or to set lower static refresh rates for power >>>>> savings. >>>> I'm interested in limiting the range of VRR to enable HDMI's QMS/CinemaVRR >>>> features - ie: switching to a fixed rate for media playback without >>>> incurring screen blackouts/resyncs/"bonks" during the switch. >>>> >>>> I could see using an interface such as this to do the frame rate limiting, >>>> by setting the lower and upper bounds both to a media file's framerate. >>>> However for that use case it's not precise enough, as video may have a >>>> rate like 23.9760239... FPS. >>>> >>>> Would it be better to expose the limits as a numerator/denominator pair so >>>> a rate can be something like 24000/1001fps? >>> I was thinking the properties could allow directly specifying the minimum >>> and maximum number of total scanlines per refresh cycle, based on the >>> assumption the driver needs to program something along those lines. >> >> Surprisingly, this would also not be precise enough for exact media >> playback, as the exact intended framerate might not result in an integer >> number of scan lines. When that happens a QMS/CinemaVRR capable HDMI >> source is expected to periodically post a frame with a single extra scan >> line to minimize the error. > > Intel VRR hardware has a "CMRR" feature where it can automagically > tweak the vtotal between frames to maintain a non integer average.
Neat. > As for knobs to limit the min/max refresh rates, technically you > wouldn't need the max knob because that is ultimately defined by > the vtotal of the supplied timings. But I guess if you have a > knob to limit the min then a max knob might be convenient as well. It allows the compositor to limit the maximum refresh rate without changing the mode (which can involve visual glitches). -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
