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. > 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. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
