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...
