On Fri, 25 Sep 2026, Daniel Stone <[email protected]> wrote: > Hi Vidith, > > On Fri, 25 Sept 2026 at 04:49, Vidith Madhu <[email protected]> wrote: >> On Mon, 21 Sep 2026, Nicolas Frattaroli wrote: >> > + if (!crtc_state->vrr_enabled) { >> I don't think we should use the vrr_enabled CRTC property to determine >> VRR_EN in the VTEM EMP. Transitioning the VRR mode sink-side typically causes >> blanking, and it was discussed in patch [03/25] that drivers should be >> free to handle vrr_enabled changes as a seamless switch since it only >> concerns source-side VRR state (this is how the NVIDIA driver handles it). >> Maybe it would make sense to extend the qms_enabled connector property >> introduced in this patchset to an enum of {Off, Gaming, QMS}? This would >> allow >> a standard path to control the VRR state on the sink, separately from >> vrr_enabled. > > I remain cautious of putting this amount of policy inside the kernel > and/or left to individual IHV choices. It's relatively obvious for > NVIDIA and AMD to say 'we'll always enable FRL/VRR to smash the > maximum rate (unless it's contraindicated by USB-C bandwidth somehow) > because the power burn is inconsequential', but if you were MediaTek > or Rockchip you'd probably make a different decision. Then again, if > you were an MTK device living on AC power, maybe you'd make the same > decision. Or maybe AMD would want to make a different decision on > laptop parts because the bandwidth is noticeable then. > > The point is that I don't think we should bury this down in implicit > kernel state. I'm with you on surfacing this as an explicit connector > property. Possibly a bitmask of modes the user will use? e.g. { > frr_only = 0, maybe_gaming_vrr = (1 << 0), maybe_qms = (1 << 1), ... > }? Or perhaps just a flag for whether the link should be negotiated as > wide as possible or tight to the existing mode params?
On a tangent, Ville and I have been tossing around an idea to introduce a drm device level property to control device "power mode" policy, mapping to the kind of setting userspace already provides. Could start of with the typical "performance", "balanced/default", and "power saver". It could be a single high-level knob to choose policy in the drm core and drivers, instead of exposing a plethora of fine grained policy that don't necessarily map well between drivers and may have conflicts between them. And end up with a lot of ABI to maintain. Policy decisions like this crop up all the time, even on things like how to choose Display Port link config and DSC and color depth, and my gut feeling is that just having e.g. those three options would help with design decisions massively. The user and userspace could use AC power or battery level or whatever to decide which power mode to choose at the high level, and you wouldn't have to have every desktop environment tweak every little thing at the detailed level. BR, Jani. -- Jani Nikula, Intel
