On 2025-09-24 03:50, Michel Dänzer wrote:
> On 15.09.25 12:01, Michel Dänzer wrote:
>> On 12.09.25 15:45, Derek Foreman wrote:
>>> On 9/12/25 2:33 AM, Chuanyu Tseng wrote:
>>>>
>>>> This is done through 2 new CRTC properties, along with a client
>>>> cap. See the docstrings in patch for details.
>>
>> Not sure why a client cap would be needed for this.
>
> According to
> https://hwentland.github.io/work/2025hackfest-notes.html#vrr-for-desktop-use-cases
> the client cap was intended for disabling LFC & ramping in the kernel
> driver. It's not really needed for that though:
>
> If the min/max property values differ, the kernel driver can vary the
> effective refresh range between the limits and perform ramping, otherwise it
> can't.
>
> If the effective maximum value is at least twice the effective minimum value,
> the kernel driver can perform LFC, otherwise it can't.
In this case, would the kernel be handling LFC and ramping still? Or would it
be a team effort between compositor and kernel?
For example, say the compositor wishes to adjust (min, max) from (48, 48) to
(60, 120), and we're using FPS as the unit. I could imagine the following
scenarios:
1) Compositor does LFC/ramping
------------------------------
The compositor can make a sequence of atomic commits where (min, max) is set to
(50, 60), (60, 75), ..., (100, 120). The difference between (min_1, max_1)
itself and subsequent (min_2, max_2) will have to be small enough to avoid
panel flicker. IOW, setting (60, 120) is bad because the range is too wide and
may cause flicker, and going from (48, 48) to (120, 120) is also bad for the
same reason. The compositor has to be fully aware of ramping here.
For LFC, compositor has to be fully aware too, and ramp to the calculated LFC
fps. IOW if going from 24fps to 30fps and the panel supports a min of 48hz, the
compositor has to ramp from (48, 48) to (60, 60). Setting a (min, max) outside
of the panel supported range would be rejected.
2) Kernel does LFC/ramping
--------------------------
The compositor can request a change from (48, 48) to (60, 120) directly. There
will be a period of a few frames where FPS would ramp up to the requested
range. IOW, the requested (min, max) is not guaranteed to be applied
immediately. Since the kernel handles ramping, we would have the same
challenges as prior to this API if the (min, max) range is large. Though that
might be ok, as long as the compositor is aware.
If the requested min happens to be below the panel supported rate, then kernel
can enable LFC, but only if the calculated LFC fps is within the requested
(min, max) range. I guess if it happens that the requested min is not possible,
i.e.:
* min or max is < min_panel_supported, and
* max is < an int multiple of min,
Then the kernel would have to reject that commit?
3) Team effort
--------------
The compositor can make a sequence of atomic commits where (min, max) is set to
(50, 60), (55, 75), ... (60, 120). The kernel will apply the new range
immediately, but still apply ramping within the requested (min, max) values.
Also, the same challenge mentioned in 2) applies here.
For LFC, I guess it would be the same as 2). The compositor has to know when
the min < min_panel_supported, and make sure max is set to be at least double
that, and within the panel supported range. The compositor would have to ramp
to that target though.
--------
I suppose either 2) or 3) aligns with your thought Michel, but I'm undecided on
which is best. Or maybe there's another method of operation that I haven't
thought of.
Thanks,
Leo
>
>
