> 2) Kernel does LFC/ramping I don't think that would be a good idea. The kernel doing ramping would mean the user can't (easily) configure it, and it would complicate the compositor doing ramping with a different strategy (like reducing the allowed change at lower refresh rates).
Min and max refresh rate / duration is enough for compositors to implement the features we need, let's not make it more complicated than necessary please. > It's possible that compositor set the value which is not acceptable to sink > vrr range. It would be better to clamp the false value. >From time to time a user asks about how to override the EDID-provided VRR range, without having to resort to manually patching an EDID and overriding it. I think it would be best if the kernel just applies the value the compositor sets, so that we can allow the user to configure the minimum refresh rate without having to jump through so many hoops. If a compositor wants to make sure it adheres to the limits, it can clamp the value itself very easily.
