On 23.09.25 16:35, Leo Li wrote: > > > 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. E.g. the current UAPI doesn't allow the compositor to take advantage of refresh cycles inserted by the kernel for LFC, e.g. for moving the cursor plane:
The compositor has to guess if and when the kernel inserts refresh cycles for LFC, there's no way to know. If the compositor tries anyway, but its atomic commit is too late for the LFC refresh cycle, it results in bad latency and possibly an application frame drop. To avoid this, the compositor would need to aim early, which isn't great for latency. Either way, the additional compositor commits will interfere with the kernel's LFC / ramping calculations. To avoid such issues, the idea is to give the compositor full control over the effective refresh rate range, allowing it to perform LFC & ramping itself, among other things. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
