From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 03D8BC98318 for ; Sat, 26 Sep 2026 12:14:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=pIy9qRNuk+I1H9PIzez1apYez2z7kj17yUhUZu4CB0I=; b=QjkDdUV49HxEhU 6yqLry84WzdFKBi/P80F0gOCcYhztTWnhnsuMqeC/i5r+gOPLpLTn1sFh8AHj+qLtpcDETuqilGgX mgTGhC9QPqD9CuMaTqb4N/JB2XSaiT3JFAMisPLjDFZ56uZhh1tHWzyZreHutBM6IegYKrL43dkSJ zYtXsURrQFur5sw+sK2HHyXxCWmsek6oaO9fjp1rTZ3LKhno9F0RN+5N+8prKpDJ2GhGLfMMFsYC8 A6upSF1Uor1obw/5KiC1AqNXs48xcpyZATX3BzSynvZsU7If1MVwJi+HhxFc5eHsGJ4cqe4ysVslT FYjtCGaVpsrJb4FGHbfw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xARIM-0000000FMWw-3B5P; Sat, 26 Sep 2026 12:14:22 +0000 Received: from sender4-pp-f112.zoho.com ([136.143.188.112]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xARIJ-0000000FMVT-3CKR; Sat, 26 Sep 2026 12:14:21 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1790424821; cv=none; d=zohomail.com; s=zohoarc; b=nasoSrIl9KcUqK0DT8SzV5nVDXuxQRhCTTDweswR05ZrmYaXHn3oz9PlTU3oA5BvzEo1i9/OrERg6U/HNFW93k8Y1FFVHeNeLOk8fTw/1O/PiFtLVHvMrvWnGp9JbPR28G4UP3uNujBwxR1jPTFTHnysG9c7Y84viUOakjicA7o= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1790424821; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; bh=NeIgan50r491jqmuR3ZRoobvDzKxm124IC7JCVTX4Hg=; b=U473Jxzs+gWttpqIClZECT9YHH0jfQMLHBhh78p2EE/W09lZmOmZbbuci6brvPYwSv1By9IHwDx+JZpVloBKcVbjxeL7eJy6mkILltw/k7pXJMKxzeIhH7FzyccCAXI+kOhoZInEaqVNHPdnZCr/kfNNHgTlLDl4ZBY8ng5k1Wc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=collabora.com; spf=pass smtp.mailfrom=nicolas.frattaroli@collabora.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1790424821; s=zohomail; d=collabora.com; i=nicolas.frattaroli@collabora.com; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:MIME-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Reply-To; bh=NeIgan50r491jqmuR3ZRoobvDzKxm124IC7JCVTX4Hg=; b=iPv2CDHqWUGmUCmjfvIt2UOD5Nt5e7yhBJIBrktXvKsWVZr4Ffm4/i3FnSCBsc4s lE69f5fnxybJi3c8wAATYcUHA0sXHztWAWr36Hczs6UzJ0wzxOGdyAhhsIlM6Wv2MgP 3p00SA60uTQWk8DmNWDlt8XbFNXG8n3Py8lS/njo= Received: by smtp.zohomail.com with SMTPS id 179042481925589.85921556278674; Sat, 26 Sep 2026 05:13:39 -0700 (PDT) From: Nicolas Frattaroli To: "Borah, Chaitanya Kumar" , Daniel Stone , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Helge Deller , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Luca Ceresoli , Sandy Huang , Heiko =?UTF-8?B?U3TDvGJuZXI=?= , Andy Yan , Leo Li Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, kernel@collabora.com, Derek Foreman , wayland-devel@lists.freedesktop.org Subject: Re: [PATCH RFC 13/25] drm: Add VRR target frame rate properties Date: Sat, 26 Sep 2026 14:13:32 +0200 Message-ID: In-Reply-To: <8a3b2902-3255-4dd9-82f0-75a7747b710e@amd.com> References: <20260921-vrr-limiter-uapi-v1-0-2fcd7d011646@collabora.com> <8a3b2902-3255-4dd9-82f0-75a7747b710e@amd.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260926_051419_838856_81BAF71E X-CRM114-Status: GOOD ( 30.02 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org On Friday, 25 September 2026 20:42:05 Central European Summer Time Leo Li wrote: > > On 2026-09-22 11:26, Nicolas Frattaroli wrote: > >>> + * VRR Limiter/Target Properties > >>> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>> + * > >>> + * The ``VRR_{MIN,MAX}_{NUMERATOR,DENOMINATOR}`` properties expose a mechanism > >>> + * through which userspace can control the desired range of refresh rates in > >>> + * which VRR is allowed to operate. Each rate is expressed as a > >>> + * numerator/denominator fraction of refresh rates in Hz, allowing for rational > >>> + * target rates like 24/1.001 Hz with no loss of precision or ambiguity. > >>> + * > >>> + * If the minimum and maximum rate are set to the same value (and not 0), they > >>> + * are understood as a fixed target rate. This is especially useful for media > >>> + * playback, where the content's frame rate is both constant and known in > >>> + * advance. In such cases, a refresh rate that is not an integer multiple of the > >>> + * content's frame rate will introduce judder, since not every frame is > >>> + * displayed for the same amount of time. A modeset of the display with a > >>> + * compatible rate may in those cases be either undesirable or impossible, but > >>> + * the rate can still effectively be reached through VRR. > >>> + * > >>> + * .. _VRR-MIN-NUMERATOR: > >>> + * > >>> + * "VRR_MIN_NUMERATOR": > >>> + * Default &drm_crtc integer property forming the numerator of a > >>> + * numerator/denominator pair of a frame rate to set as the minimum VRR > >>> + * target rate. Set to 0 to disable. > >>> + * > >>> + * "VRR_MIN_DENOMINATOR": > >>> + * Default &drm_crtc integer property forming the denominator of a > >>> + * numerator/denominator pair of a frame rate to set as the minimum VRR > >>> + * target rate. If :ref:`VRR_MIN_NUMERATOR ` is not > >>> + * zero, it must be non-zero. > >>> + * Otherwise, must also be zero. > >>> + * > >>> + * .. _VRR-MAX-NUMERATOR: > >>> + * > >>> + * "VRR_MAX_NUMERATOR": > >>> + * Default &drm_crtc integer property forming the numerator of a > >>> + * numerator/denominator pair of a frame rate to set as the maximum VRR > >>> + * target rate. Set to 0 to disable. > >>> + * > >>> + * "VRR_MAX_DENOMINATOR": > >>> + * Default &drm_crtc integer property forming the denominator of a > >>> + * numerator/denominator pair of a frame rate to set as the maximum VRR > >>> + * target rate. If :ref:`VRR_MAX_NUMERATOR ` is not > >>> + * zero, it must be non-zero. Otherwise, must also be zero. > >>> */ > >> If VRR_MIN_NUMERATOR == 0 && VRR_MAX_NUMERATOR > 0, do we interpret that as > >> vrr limiting is disabled? > > You can picture VRR limiting as always being active, but with a limit rational > > of 0 it uses the display's limit as per the EDID, which is what unlimited game > > mode is. So with how it's implemented right now in hdmi_validate_vrr(), your > > example would set a maximum target, but leave the minimum at whatever the > > display defaults to. > > > > Now that I'm thinking through this, a possible problem is that > > drm_crtc_helper_vrr_is_fixed_rate() operates on the user supplied limits, but > > if the display supplied lower limit is equal to the user supplied upper limit, > > then we have a fixed rate scenario without recognising it as such. I think I > > need to have a ponder on what the least surprising behaviour for userspace > > is in that instance. The display limit stuff gets a bit complex due to > > CinemaVRR and QMS TFRmin/TFRmax. > > > > I'll improve the documentation on the next revision to make the meanings more > > explicit. > > Perhaps a simple way is to require simultaneous setting MIN and MAX pairs? > IOW, require userspace to set MIN and MAX simultaneously to >0, or =0. For example: > > if ((vrr_min_n == 0 || vrr_min_d == 0 || > vrr_max_n == 0 || vrr_max_d == 0) && > (vrr_min_n > 0 || vrr_max_n > 0)) > return -EINVAL; > > That way, it's never ambiguous what userspace has requested for the range. > They can copy the EDID supported range if they don't care about limiting > one side, rather than leaving it at 0. It's then also clear if they requested > a static Hz. That's a good thought. It makes a lot of the logic simpler to catch bad conditions, and it's the kind of thing that can definitely be checked in connector-agnostic shared CRTC atomic_check code. Thanks for the suggestion, I'll likely adopt it for the next revision! Kind regards, Nicolas Frattaroli > > Thanks, > Leo > _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip