On 2025-09-23 04:37, Michel Dänzer wrote:
> On 22.09.25 21:06, Leo Li wrote:
>> On 2025-09-18 04:33, Tseng, Chuan Yu (Max) wrote:
>>> 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.
>>
>> Static video/desktop frame rates was indeed one of the motivations for
>> proposing this API, so it is worth discussing.
>>
>> For amdgpu (and I think most HW are like this), hardware VRR granularity is
>> at # of total vertical scanlines (vtotal). So if that isn't precise enough,
>> then the driver will have to do record-keeping to alternate between some
>> vtotal and vtotal+1 to avoid drift.
>>
>> It's not impossible to do, though I'm not sure at what point the driver is
>> considered to be doing "unexpected adjustments of refresh rate", which was
>> something we were also trying to address with this new API. Today, drivers
>> are free to do unexpected things with the vtotal, such as frame-doubling to
>> handle rates below the supported vrr min, and frame-ramping to prevent panel
>> flicker. We discussed at the display hackfest that this was not something
>> compositors liked, and that compositors would like to handle that themselves.
>>
>> Now, memory fails me, and I don't remember the exact motivation for why
>> compositors want transparent vrr control. Was it because of unexpected
>> driver-reported vblank timestamps messing with compositor internal record
>> keeping? Or something else entirely?
>
> AFAIR it's mostly about the compositor being able to control the refresh rate
> in general (e.g. keeping it low to save power) and allowing it to handle LFC
> & ramping without interference by the kernel's corresponding handling.
I seem to recall a good reason mentioned for why compositors would like to
handle LFC & ramping, but I don't recall the details. Otherwise, would it not
be simpler for the compositor to leave that to the kernel, and have one
additional "static_refresh" property to handle low hz desktop and static hz
content scenarios?
Thanks,
Leo
>
>
>> Another way of putting it: Would the compositor rather:
>>
>> 1. Specify a min_vtotal + 1 == max_vtotal so driver doesn't do any
>> unexpected adjustments out of the specified range, or
>> 2. Specify a min_frame_ns == max_frame_ns (or some other highly-precise
>> unit), and have driver correct for drift by alternating between two vtotals,
>> and hence adjust refresh rate beyond the specified range?
>
> FWIW, I'd be fine with option 2.
>
>
