[AMD Official Use Only - AMD Internal Distribution Only] On 9/16/25 4:56 PM, Xaver Hugl wrote: > Am Mo., 15. Sept. 2025 um 17:49 Uhr schrieb Michel Dänzer > <[email protected]>: >> 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. > API wise, I'd much prefer just using nanoseconds instead of two > properties that compositors will in practice just use the same way.
>Yeah, I hear you. Period is generally much nicer than frequency, and every >other time I'd unconditionally agree, but QMS is awkward in this regard. > >The media file I start with will have a fraction specified in integers for the >rate, eg: something like 24000/1001 fps. That will map to an index in an array >of QMS blessed target framerates (24000/1001, 24, 25, 48/1001, 48...) and the >index ends up in a bitfield in the HDMI QMS infoframe. That infoframe also has >a bit to indicate that the framerate is currently constant, with constant >defined as "constant number of scanlines but may be exactly 1 scanline longer >occasionally". > >In the constant state we'd need to maintain that fixed rate within that >constraint, and the integer math to do that needs to start from 24000/1001. > >So if we used a nanosecond period for the interface, we'd need to take the >media file's values and convert them to nanoseconds, then in the kernel >convert back to something like milliframes per second (so we could get >something near 23976), then look that up in the QMS accepted rates array, have >some manner of epsilon to decide if we're close enough to one of them to use >it, and then use the integer representation (back to 24000/1001) to setup the >scanline temporal dithering algorithm to do the +1 extra line every few frames >to hit the exact rate. > >In effect we'd throw away the precise values we started with and try to >reconstruct them later. > >QMS also has the added strange feature of being able to set a fixed rate below >the display's normal VRR minimum, so I'm undecided as to whether this range >control interface is an ideal match for setting up QMS anyway, or whether I >should propose a separate fixed rate property later. I just don't want to >ignore this discussion and show up proposing another non-orthogonal property >later. > >Sorry to be speaking in hypotheticals, I do have a working QMS implementation >to share soonish, it's just not quite ready for review yet... Thanks for the input. For the QMS support, it's related to HDMI 2.1 spec. From my knowledge, it's not open to everyone. We might sperate this QMS support into different discussions. To support FPS/1.001, I think we can augment 1 more property in this patch, once it's set, we can divide this FPS with 1.001, vise versa. Thanks, -- Chuanyu.
