On 15.09.25 17:37, 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.
Interesting, maybe your suggestion of numerator / denominator properties is better then. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
