From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wnew2-smtp.messagingengine.com (wnew2-smtp.messagingengine.com [64.147.123.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 08B8215A7 for ; Thu, 18 Aug 2022 14:54:44 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.west.internal (Postfix) with ESMTP id 01D4F2B05FC5; Thu, 18 Aug 2022 10:54:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 18 Aug 2022 10:54:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1660834481; x=1660841681; bh=dPX9hXeCy6 yKTnRmZoO6RMIl8noeu+daJnSyaEODPnQ=; b=ICKzLeV9qiOuOqiD3gZpMPLDAm VopW9x7Yud0hY2YkD1D1wPjg6LOPc+ccq6gPG0quHxhjhpsLPeF1o2Y9DhtgYaFh 46BU7z1WbxqfeTsqgqHPq+GOxrupa0qDWX/Y2Syz4ZSiV6pSOHq358XmYyCIw2u/ SmLzoGbsPKfUuh5lf80MIZkmUijMep9qslXjhZGwl1laHWrTdmBsTf6/1JYEMIVh aeUUYqFNm2zb8CzRmb3I4uh8c3rtrl3u1ieoM8t2Q10RwC0NlPPrcLXZPEyqqykB 5KOwLeIZDnafnfciCbYT9WiVDncaHHoTmtWwbAGlTWt6j5dD5QIPyc/TycPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1660834481; x=1660841681; bh=dPX9hXeCy6yKTnRmZoO6RMIl8noe u+daJnSyaEODPnQ=; b=VRnogI9eKVOUowQt1qjzRFHTEVI5kpt8dDDdSzKRC/X5 bRgGe32rHxmxPVEAZvEEjVLuu6eV/s+xsvilUK4n/7KPF59XBiAnv8LNVLn9yRlH RRDvj94NOCXcycKGTJ48i3oaxWM63vqrPlUsP58PNd6tBYleZOQ0vyAMexcp+jud F/zLcankqKpacLDKmFn4iqLktv0pWE+Y1j+VC5KtOtOIBB17tSVXLKTMFevfL2ta s7yot5w4u0Q7dEs3sI8VWle5sFF2sOn7g7A7Bi6EHzOcBVU5hO7S0R4IOBM6j8qN 4y8ZWX7ve1Kn3sTR7n0xf3lk6bHltGCDjfcS8WqiJw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdehledgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofgrgihi mhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrg htthgvrhhnpedtleekjeeiudefvdfhieffteelhfeivdeliefgieeugffhvdelieffjeei geetjeenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnhhordhtvggt hh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 18 Aug 2022 10:54:39 -0400 (EDT) Date: Thu, 18 Aug 2022 16:54:36 +0200 From: Maxime Ripard To: Geert Uytterhoeven Cc: Jernej Skrabec , Martin Blumenstingl , Chen-Yu Tsai , Philipp Zabel , Jerome Brunet , Samuel Holland , Thomas Zimmermann , Daniel Vetter , Emma Anholt , David Airlie , Maarten Lankhorst , Noralf =?utf-8?Q?Tr=C3=B8nnes?= , Kevin Hilman , Neil Armstrong , linux-sunxi@lists.linux.dev, Linux Kernel Mailing List , Phil Elwell , Mateusz Kwiatkowski , Linux ARM , Dave Stevenson , "open list:ARM/Amlogic Meson..." , DRI Development , Dom Cobley Subject: Re: [PATCH v1 05/35] drm/connector: Add TV standard property Message-ID: <20220818145436.vqojnhmvhjxdzooe@houat> References: <20220816141116.5nuszmilqv2exdb3@houat> <20220816154956.pkdpxmmw27mia5ix@houat> <20220817074710.w4c4xwj7edly2b5p@houat> <20220817111454.pn2iltvyo2drebq7@houat> <20220817131854.jwmhqvhfhp77bbr3@houat> Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rgjjcrwq24n3fk6k" Content-Disposition: inline In-Reply-To: --rgjjcrwq24n3fk6k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 17, 2022 at 04:04:24PM +0200, Geert Uytterhoeven wrote: > Hi Maxime, >=20 > On Wed, Aug 17, 2022 at 3:19 PM Maxime Ripard wrote: > > On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote: > > > On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard wro= te: > > > > On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote: > > > > > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard = wrote: > > > > > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wr= ote: > > > > > > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard wrote: > > > > > > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeve= n wrote: > > > > > > > > > > > > > Either you have to add them here (e.g. "hd720p50"= and "hd720p60"), or > > > > > > > > > > > > > handle them through "@". The latter wou= ld impact "[PATCH v1 > > > > > > > > > > > > > 09/35] drm/modes: Move named modes parsing to a s= eparate function", as > > > > > > > > > > > > > currently a named mode and a refresh rate can't b= e specified both. > > > > > > > > > > > > > > > > > > > > > > > > I think the former would make more sense. It simpli= fies a bit the > > > > > > > > > > > > parser, and we're going to use a named mode anyway. > > > > > > > > > > > > > > > > > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_= mode property as a > > > > > > > > > > > > > command-line option" uses a separate "tv_mode" op= tion, and not the main > > > > > > > > > > > > > mode name, I think you want to add them here. > > > > > > > > > > > > > > > > > > > > > > > > It's a separate story I think, we could have a name= d mode hd720p50, > > > > > > > > > > > > which would be equivalent to 1280x720,tv_mode=3Dhd7= 20p > > > > > > > > > > > > > > > > > > > > > > So where's the field rate in "1280x720,tv_mode=3Dhd72= 0p"? > > > > > > > > > > > > > > > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=3Dhd720p > > > > > > > > > > > > > > > > > > Above you said "I think the former would make more sense"= , so that > > > > > > > > > should be "1280x720,tv_mode=3Dhd720p50"? > > > > > > > > > > > > > > > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv= _mode=3Dhd720p > > > > > > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=3Dhd720p > > > > > > > > > > > > > > I disagree: hd720p50 and hd720p60 are different TV modes. > > > > > > > > > > > > I agree, and I don't see how that command-line doesn't express = that? > > > > > > > > > > Oh, I see what you mean: yes, it expresses that. > > > > > But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] mo= des, > > > > > where the TV mode specifies both number of lines and frame rate. > > > > > > > > Only if we're using a named mode, and naming is hard :) > > > > > > That's not true: "640x480,tv_mode=3DPAL-N" would give me a mode with > > > 625 lines and 25 frames/s, "640x480,tv_mode=3DPAL-M" would give me a > > > mode with 525 lines and 30 frames/s. > > > > In that series, "640x480,tv_mode=3DPAL-N" would be rejected as invalid: > > > > https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v1-= 14-3d53ae722097@cerno.tech/ >=20 > It would become supported once the ideas from thread "[PATCH v1 04/35] > drm/modes: Introduce 480i and 576i modes" are implemented... Indeed, but I'm still not sure what your concern is here. "640x480,tv_mode=3DPAL-N" and "640x480,tv_mode=3DPAL-M" are both fairly obvious. You were initially saying that you had concern over the inconsistency of NTSC/PAL/SECAM where the TV mode would specify a number of lines and frame rate, but hd720p50 also specifies a number of line and frame rate? Maxime --rgjjcrwq24n3fk6k Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYv5SrAAKCRDj7w1vZxhR xXOeAP4xRmnMVN7/AVY7/uaHcHK2PeXpYI7/wh8vab/NDtQGWAD+LBoFZbUfz3kt HC6p3zpvWUaMbbbcZkWajF4mKGTE3QE= =VOq1 -----END PGP SIGNATURE----- --rgjjcrwq24n3fk6k-- 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 822D9C2BB41 for ; Thu, 18 Aug 2022 14:55:07 +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-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=5K1q+wsrorqLNRF7VNXPWQYNBVbt4IBFXCouhVjsQIg=; b=FcP1CdJ1xbYs/YYUkY65Cf7AdL xZlwidwf6Xso1q77eDOObVUePVBiEZUYQ5s3Hitz9Ox19BB/cna4a4s9iP/JM3c9Hi7CAOYD7EKxf QZH7QnputRV8cvMHlKQaJx9pozpzu4qrl3StryuA76//rJl6lHNDAa6spriHPZEbUze8DzrNmshNz UgLP3Riiei415uRTxaNOXOaxbd7zO+zUBy+rYr9iVDIX4SBjBQ2wGUe7EOKpjlSUZb+aMJ7SkSn1l cr2435FKEcMBdRxSnct8+ohD9M2/uDiOQloYRZUXM/JhW9XGT/dA4oIG8aVU3g0GyJHFBia5jezUH st2FyJgA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oOgv8-006JdU-7X; Thu, 18 Aug 2022 14:54:54 +0000 Received: from wnew2-smtp.messagingengine.com ([64.147.123.27]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oOgv2-006JXW-5J; Thu, 18 Aug 2022 14:54:51 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.west.internal (Postfix) with ESMTP id 01D4F2B05FC5; Thu, 18 Aug 2022 10:54:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 18 Aug 2022 10:54:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1660834481; x=1660841681; bh=dPX9hXeCy6 yKTnRmZoO6RMIl8noeu+daJnSyaEODPnQ=; b=ICKzLeV9qiOuOqiD3gZpMPLDAm VopW9x7Yud0hY2YkD1D1wPjg6LOPc+ccq6gPG0quHxhjhpsLPeF1o2Y9DhtgYaFh 46BU7z1WbxqfeTsqgqHPq+GOxrupa0qDWX/Y2Syz4ZSiV6pSOHq358XmYyCIw2u/ SmLzoGbsPKfUuh5lf80MIZkmUijMep9qslXjhZGwl1laHWrTdmBsTf6/1JYEMIVh aeUUYqFNm2zb8CzRmb3I4uh8c3rtrl3u1ieoM8t2Q10RwC0NlPPrcLXZPEyqqykB 5KOwLeIZDnafnfciCbYT9WiVDncaHHoTmtWwbAGlTWt6j5dD5QIPyc/TycPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1660834481; x=1660841681; bh=dPX9hXeCy6yKTnRmZoO6RMIl8noe u+daJnSyaEODPnQ=; b=VRnogI9eKVOUowQt1qjzRFHTEVI5kpt8dDDdSzKRC/X5 bRgGe32rHxmxPVEAZvEEjVLuu6eV/s+xsvilUK4n/7KPF59XBiAnv8LNVLn9yRlH RRDvj94NOCXcycKGTJ48i3oaxWM63vqrPlUsP58PNd6tBYleZOQ0vyAMexcp+jud F/zLcankqKpacLDKmFn4iqLktv0pWE+Y1j+VC5KtOtOIBB17tSVXLKTMFevfL2ta s7yot5w4u0Q7dEs3sI8VWle5sFF2sOn7g7A7Bi6EHzOcBVU5hO7S0R4IOBM6j8qN 4y8ZWX7ve1Kn3sTR7n0xf3lk6bHltGCDjfcS8WqiJw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdehledgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofgrgihi mhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrg htthgvrhhnpedtleekjeeiudefvdfhieffteelhfeivdeliefgieeugffhvdelieffjeei geetjeenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnhhordhtvggt hh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 18 Aug 2022 10:54:39 -0400 (EDT) Date: Thu, 18 Aug 2022 16:54:36 +0200 From: Maxime Ripard To: Geert Uytterhoeven Cc: Jernej Skrabec , Martin Blumenstingl , Chen-Yu Tsai , Philipp Zabel , Jerome Brunet , Samuel Holland , Thomas Zimmermann , Daniel Vetter , Emma Anholt , David Airlie , Maarten Lankhorst , Noralf =?utf-8?Q?Tr=C3=B8nnes?= , Kevin Hilman , Neil Armstrong , linux-sunxi@lists.linux.dev, Linux Kernel Mailing List , Phil Elwell , Mateusz Kwiatkowski , Linux ARM , Dave Stevenson , "open list:ARM/Amlogic Meson..." , DRI Development , Dom Cobley Subject: Re: [PATCH v1 05/35] drm/connector: Add TV standard property Message-ID: <20220818145436.vqojnhmvhjxdzooe@houat> References: <20220816141116.5nuszmilqv2exdb3@houat> <20220816154956.pkdpxmmw27mia5ix@houat> <20220817074710.w4c4xwj7edly2b5p@houat> <20220817111454.pn2iltvyo2drebq7@houat> <20220817131854.jwmhqvhfhp77bbr3@houat> MIME-Version: 1.0 In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220818_075448_755871_E08794F2 X-CRM114-Status: GOOD ( 28.67 ) X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4775407154558186693==" Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org --===============4775407154558186693== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rgjjcrwq24n3fk6k" Content-Disposition: inline --rgjjcrwq24n3fk6k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 17, 2022 at 04:04:24PM +0200, Geert Uytterhoeven wrote: > Hi Maxime, >=20 > On Wed, Aug 17, 2022 at 3:19 PM Maxime Ripard wrote: > > On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote: > > > On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard wro= te: > > > > On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote: > > > > > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard = wrote: > > > > > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wr= ote: > > > > > > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard wrote: > > > > > > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeve= n wrote: > > > > > > > > > > > > > Either you have to add them here (e.g. "hd720p50"= and "hd720p60"), or > > > > > > > > > > > > > handle them through "@". The latter wou= ld impact "[PATCH v1 > > > > > > > > > > > > > 09/35] drm/modes: Move named modes parsing to a s= eparate function", as > > > > > > > > > > > > > currently a named mode and a refresh rate can't b= e specified both. > > > > > > > > > > > > > > > > > > > > > > > > I think the former would make more sense. It simpli= fies a bit the > > > > > > > > > > > > parser, and we're going to use a named mode anyway. > > > > > > > > > > > > > > > > > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_= mode property as a > > > > > > > > > > > > > command-line option" uses a separate "tv_mode" op= tion, and not the main > > > > > > > > > > > > > mode name, I think you want to add them here. > > > > > > > > > > > > > > > > > > > > > > > > It's a separate story I think, we could have a name= d mode hd720p50, > > > > > > > > > > > > which would be equivalent to 1280x720,tv_mode=3Dhd7= 20p > > > > > > > > > > > > > > > > > > > > > > So where's the field rate in "1280x720,tv_mode=3Dhd72= 0p"? > > > > > > > > > > > > > > > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=3Dhd720p > > > > > > > > > > > > > > > > > > Above you said "I think the former would make more sense"= , so that > > > > > > > > > should be "1280x720,tv_mode=3Dhd720p50"? > > > > > > > > > > > > > > > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv= _mode=3Dhd720p > > > > > > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=3Dhd720p > > > > > > > > > > > > > > I disagree: hd720p50 and hd720p60 are different TV modes. > > > > > > > > > > > > I agree, and I don't see how that command-line doesn't express = that? > > > > > > > > > > Oh, I see what you mean: yes, it expresses that. > > > > > But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] mo= des, > > > > > where the TV mode specifies both number of lines and frame rate. > > > > > > > > Only if we're using a named mode, and naming is hard :) > > > > > > That's not true: "640x480,tv_mode=3DPAL-N" would give me a mode with > > > 625 lines and 25 frames/s, "640x480,tv_mode=3DPAL-M" would give me a > > > mode with 525 lines and 30 frames/s. > > > > In that series, "640x480,tv_mode=3DPAL-N" would be rejected as invalid: > > > > https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v1-= 14-3d53ae722097@cerno.tech/ >=20 > It would become supported once the ideas from thread "[PATCH v1 04/35] > drm/modes: Introduce 480i and 576i modes" are implemented... Indeed, but I'm still not sure what your concern is here. "640x480,tv_mode=3DPAL-N" and "640x480,tv_mode=3DPAL-M" are both fairly obvious. You were initially saying that you had concern over the inconsistency of NTSC/PAL/SECAM where the TV mode would specify a number of lines and frame rate, but hd720p50 also specifies a number of line and frame rate? Maxime --rgjjcrwq24n3fk6k Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYv5SrAAKCRDj7w1vZxhR xXOeAP4xRmnMVN7/AVY7/uaHcHK2PeXpYI7/wh8vab/NDtQGWAD+LBoFZbUfz3kt HC6p3zpvWUaMbbbcZkWajF4mKGTE3QE= =VOq1 -----END PGP SIGNATURE----- --rgjjcrwq24n3fk6k-- --===============4775407154558186693== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic --===============4775407154558186693==-- 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 CD733C2BB41 for ; Thu, 18 Aug 2022 14:56:19 +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-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Vr8qAHFFxfaGaS4QHw7nXNOiuewtJY8SSnX7VAzO4/Y=; b=gkaKJj66OBkV/icK8oblPaZFkw PiOGEM4e4bE4cQDi9rbvRw0w3aYUgmD1Ck9DOy7BYRIPygA79zI4XGOGRzogU5+J5dLHJliKoXlln EMyEecMQUhKvgbeMXKgmgN3mdt26RLMlXCqJISnxVI4HInVtXazdUqYDA5+4b3lLs0ssiO59iaetu oshlGMezFhaXXAhvBeHvNwA88HpLlWgQ6c1o/4NravzthzEOM5ZaEeWzi/XT7bn8bLX2G26/HEswg NWx0xmQFdZUpTJqGwMQCkUIbtTYAWfXXx4CMBbdDqBMbbso07AWmTTUZokFANfYG0a9RztLH8rbe5 y5x/V0+Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oOgv9-006Jdy-N4; Thu, 18 Aug 2022 14:54:55 +0000 Received: from wnew2-smtp.messagingengine.com ([64.147.123.27]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oOgv2-006JXW-5J; Thu, 18 Aug 2022 14:54:51 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.west.internal (Postfix) with ESMTP id 01D4F2B05FC5; Thu, 18 Aug 2022 10:54:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 18 Aug 2022 10:54:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1660834481; x=1660841681; bh=dPX9hXeCy6 yKTnRmZoO6RMIl8noeu+daJnSyaEODPnQ=; b=ICKzLeV9qiOuOqiD3gZpMPLDAm VopW9x7Yud0hY2YkD1D1wPjg6LOPc+ccq6gPG0quHxhjhpsLPeF1o2Y9DhtgYaFh 46BU7z1WbxqfeTsqgqHPq+GOxrupa0qDWX/Y2Syz4ZSiV6pSOHq358XmYyCIw2u/ SmLzoGbsPKfUuh5lf80MIZkmUijMep9qslXjhZGwl1laHWrTdmBsTf6/1JYEMIVh aeUUYqFNm2zb8CzRmb3I4uh8c3rtrl3u1ieoM8t2Q10RwC0NlPPrcLXZPEyqqykB 5KOwLeIZDnafnfciCbYT9WiVDncaHHoTmtWwbAGlTWt6j5dD5QIPyc/TycPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1660834481; x=1660841681; bh=dPX9hXeCy6yKTnRmZoO6RMIl8noe u+daJnSyaEODPnQ=; b=VRnogI9eKVOUowQt1qjzRFHTEVI5kpt8dDDdSzKRC/X5 bRgGe32rHxmxPVEAZvEEjVLuu6eV/s+xsvilUK4n/7KPF59XBiAnv8LNVLn9yRlH RRDvj94NOCXcycKGTJ48i3oaxWM63vqrPlUsP58PNd6tBYleZOQ0vyAMexcp+jud F/zLcankqKpacLDKmFn4iqLktv0pWE+Y1j+VC5KtOtOIBB17tSVXLKTMFevfL2ta s7yot5w4u0Q7dEs3sI8VWle5sFF2sOn7g7A7Bi6EHzOcBVU5hO7S0R4IOBM6j8qN 4y8ZWX7ve1Kn3sTR7n0xf3lk6bHltGCDjfcS8WqiJw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdehledgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofgrgihi mhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrg htthgvrhhnpedtleekjeeiudefvdfhieffteelhfeivdeliefgieeugffhvdelieffjeei geetjeenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnhhordhtvggt hh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 18 Aug 2022 10:54:39 -0400 (EDT) Date: Thu, 18 Aug 2022 16:54:36 +0200 From: Maxime Ripard To: Geert Uytterhoeven Cc: Jernej Skrabec , Martin Blumenstingl , Chen-Yu Tsai , Philipp Zabel , Jerome Brunet , Samuel Holland , Thomas Zimmermann , Daniel Vetter , Emma Anholt , David Airlie , Maarten Lankhorst , Noralf =?utf-8?Q?Tr=C3=B8nnes?= , Kevin Hilman , Neil Armstrong , linux-sunxi@lists.linux.dev, Linux Kernel Mailing List , Phil Elwell , Mateusz Kwiatkowski , Linux ARM , Dave Stevenson , "open list:ARM/Amlogic Meson..." , DRI Development , Dom Cobley Subject: Re: [PATCH v1 05/35] drm/connector: Add TV standard property Message-ID: <20220818145436.vqojnhmvhjxdzooe@houat> References: <20220816141116.5nuszmilqv2exdb3@houat> <20220816154956.pkdpxmmw27mia5ix@houat> <20220817074710.w4c4xwj7edly2b5p@houat> <20220817111454.pn2iltvyo2drebq7@houat> <20220817131854.jwmhqvhfhp77bbr3@houat> MIME-Version: 1.0 In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220818_075448_755871_E08794F2 X-CRM114-Status: GOOD ( 28.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1334861405921130140==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============1334861405921130140== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rgjjcrwq24n3fk6k" Content-Disposition: inline --rgjjcrwq24n3fk6k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 17, 2022 at 04:04:24PM +0200, Geert Uytterhoeven wrote: > Hi Maxime, >=20 > On Wed, Aug 17, 2022 at 3:19 PM Maxime Ripard wrote: > > On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote: > > > On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard wro= te: > > > > On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote: > > > > > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard = wrote: > > > > > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wr= ote: > > > > > > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard wrote: > > > > > > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeve= n wrote: > > > > > > > > > > > > > Either you have to add them here (e.g. "hd720p50"= and "hd720p60"), or > > > > > > > > > > > > > handle them through "@". The latter wou= ld impact "[PATCH v1 > > > > > > > > > > > > > 09/35] drm/modes: Move named modes parsing to a s= eparate function", as > > > > > > > > > > > > > currently a named mode and a refresh rate can't b= e specified both. > > > > > > > > > > > > > > > > > > > > > > > > I think the former would make more sense. It simpli= fies a bit the > > > > > > > > > > > > parser, and we're going to use a named mode anyway. > > > > > > > > > > > > > > > > > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_= mode property as a > > > > > > > > > > > > > command-line option" uses a separate "tv_mode" op= tion, and not the main > > > > > > > > > > > > > mode name, I think you want to add them here. > > > > > > > > > > > > > > > > > > > > > > > > It's a separate story I think, we could have a name= d mode hd720p50, > > > > > > > > > > > > which would be equivalent to 1280x720,tv_mode=3Dhd7= 20p > > > > > > > > > > > > > > > > > > > > > > So where's the field rate in "1280x720,tv_mode=3Dhd72= 0p"? > > > > > > > > > > > > > > > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=3Dhd720p > > > > > > > > > > > > > > > > > > Above you said "I think the former would make more sense"= , so that > > > > > > > > > should be "1280x720,tv_mode=3Dhd720p50"? > > > > > > > > > > > > > > > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv= _mode=3Dhd720p > > > > > > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=3Dhd720p > > > > > > > > > > > > > > I disagree: hd720p50 and hd720p60 are different TV modes. > > > > > > > > > > > > I agree, and I don't see how that command-line doesn't express = that? > > > > > > > > > > Oh, I see what you mean: yes, it expresses that. > > > > > But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] mo= des, > > > > > where the TV mode specifies both number of lines and frame rate. > > > > > > > > Only if we're using a named mode, and naming is hard :) > > > > > > That's not true: "640x480,tv_mode=3DPAL-N" would give me a mode with > > > 625 lines and 25 frames/s, "640x480,tv_mode=3DPAL-M" would give me a > > > mode with 525 lines and 30 frames/s. > > > > In that series, "640x480,tv_mode=3DPAL-N" would be rejected as invalid: > > > > https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v1-= 14-3d53ae722097@cerno.tech/ >=20 > It would become supported once the ideas from thread "[PATCH v1 04/35] > drm/modes: Introduce 480i and 576i modes" are implemented... Indeed, but I'm still not sure what your concern is here. "640x480,tv_mode=3DPAL-N" and "640x480,tv_mode=3DPAL-M" are both fairly obvious. You were initially saying that you had concern over the inconsistency of NTSC/PAL/SECAM where the TV mode would specify a number of lines and frame rate, but hd720p50 also specifies a number of line and frame rate? Maxime --rgjjcrwq24n3fk6k Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYv5SrAAKCRDj7w1vZxhR xXOeAP4xRmnMVN7/AVY7/uaHcHK2PeXpYI7/wh8vab/NDtQGWAD+LBoFZbUfz3kt HC6p3zpvWUaMbbbcZkWajF4mKGTE3QE= =VOq1 -----END PGP SIGNATURE----- --rgjjcrwq24n3fk6k-- --===============1334861405921130140== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============1334861405921130140==-- 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 B59B0C00140 for ; Thu, 18 Aug 2022 14:56:26 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B8546A6B20; Thu, 18 Aug 2022 14:56:22 +0000 (UTC) Received: from wnew2-smtp.messagingengine.com (wnew2-smtp.messagingengine.com [64.147.123.27]) by gabe.freedesktop.org (Postfix) with ESMTPS id E3DB5A4ED0 for ; Thu, 18 Aug 2022 14:54:46 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.west.internal (Postfix) with ESMTP id 01D4F2B05FC5; Thu, 18 Aug 2022 10:54:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 18 Aug 2022 10:54:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1660834481; x=1660841681; bh=dPX9hXeCy6 yKTnRmZoO6RMIl8noeu+daJnSyaEODPnQ=; b=ICKzLeV9qiOuOqiD3gZpMPLDAm VopW9x7Yud0hY2YkD1D1wPjg6LOPc+ccq6gPG0quHxhjhpsLPeF1o2Y9DhtgYaFh 46BU7z1WbxqfeTsqgqHPq+GOxrupa0qDWX/Y2Syz4ZSiV6pSOHq358XmYyCIw2u/ SmLzoGbsPKfUuh5lf80MIZkmUijMep9qslXjhZGwl1laHWrTdmBsTf6/1JYEMIVh aeUUYqFNm2zb8CzRmb3I4uh8c3rtrl3u1ieoM8t2Q10RwC0NlPPrcLXZPEyqqykB 5KOwLeIZDnafnfciCbYT9WiVDncaHHoTmtWwbAGlTWt6j5dD5QIPyc/TycPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1660834481; x=1660841681; bh=dPX9hXeCy6yKTnRmZoO6RMIl8noe u+daJnSyaEODPnQ=; b=VRnogI9eKVOUowQt1qjzRFHTEVI5kpt8dDDdSzKRC/X5 bRgGe32rHxmxPVEAZvEEjVLuu6eV/s+xsvilUK4n/7KPF59XBiAnv8LNVLn9yRlH RRDvj94NOCXcycKGTJ48i3oaxWM63vqrPlUsP58PNd6tBYleZOQ0vyAMexcp+jud F/zLcankqKpacLDKmFn4iqLktv0pWE+Y1j+VC5KtOtOIBB17tSVXLKTMFevfL2ta s7yot5w4u0Q7dEs3sI8VWle5sFF2sOn7g7A7Bi6EHzOcBVU5hO7S0R4IOBM6j8qN 4y8ZWX7ve1Kn3sTR7n0xf3lk6bHltGCDjfcS8WqiJw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdehledgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofgrgihi mhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrg htthgvrhhnpedtleekjeeiudefvdfhieffteelhfeivdeliefgieeugffhvdelieffjeei geetjeenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnhhordhtvggt hh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 18 Aug 2022 10:54:39 -0400 (EDT) Date: Thu, 18 Aug 2022 16:54:36 +0200 From: Maxime Ripard To: Geert Uytterhoeven Subject: Re: [PATCH v1 05/35] drm/connector: Add TV standard property Message-ID: <20220818145436.vqojnhmvhjxdzooe@houat> References: <20220816141116.5nuszmilqv2exdb3@houat> <20220816154956.pkdpxmmw27mia5ix@houat> <20220817074710.w4c4xwj7edly2b5p@houat> <20220817111454.pn2iltvyo2drebq7@houat> <20220817131854.jwmhqvhfhp77bbr3@houat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rgjjcrwq24n3fk6k" Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Emma Anholt , Neil Armstrong , David Airlie , DRI Development , Phil Elwell , Jerome Brunet , Samuel Holland , Kevin Hilman , Jernej Skrabec , Chen-Yu Tsai , linux-sunxi@lists.linux.dev, Martin Blumenstingl , "open list:ARM/Amlogic Meson..." , Linux ARM , Dom Cobley , Dave Stevenson , Linux Kernel Mailing List , Mateusz Kwiatkowski , Noralf =?utf-8?Q?Tr=C3=B8nnes?= , Thomas Zimmermann Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --rgjjcrwq24n3fk6k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 17, 2022 at 04:04:24PM +0200, Geert Uytterhoeven wrote: > Hi Maxime, >=20 > On Wed, Aug 17, 2022 at 3:19 PM Maxime Ripard wrote: > > On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote: > > > On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard wro= te: > > > > On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote: > > > > > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard = wrote: > > > > > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wr= ote: > > > > > > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard wrote: > > > > > > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeve= n wrote: > > > > > > > > > > > > > Either you have to add them here (e.g. "hd720p50"= and "hd720p60"), or > > > > > > > > > > > > > handle them through "@". The latter wou= ld impact "[PATCH v1 > > > > > > > > > > > > > 09/35] drm/modes: Move named modes parsing to a s= eparate function", as > > > > > > > > > > > > > currently a named mode and a refresh rate can't b= e specified both. > > > > > > > > > > > > > > > > > > > > > > > > I think the former would make more sense. It simpli= fies a bit the > > > > > > > > > > > > parser, and we're going to use a named mode anyway. > > > > > > > > > > > > > > > > > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_= mode property as a > > > > > > > > > > > > > command-line option" uses a separate "tv_mode" op= tion, and not the main > > > > > > > > > > > > > mode name, I think you want to add them here. > > > > > > > > > > > > > > > > > > > > > > > > It's a separate story I think, we could have a name= d mode hd720p50, > > > > > > > > > > > > which would be equivalent to 1280x720,tv_mode=3Dhd7= 20p > > > > > > > > > > > > > > > > > > > > > > So where's the field rate in "1280x720,tv_mode=3Dhd72= 0p"? > > > > > > > > > > > > > > > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=3Dhd720p > > > > > > > > > > > > > > > > > > Above you said "I think the former would make more sense"= , so that > > > > > > > > > should be "1280x720,tv_mode=3Dhd720p50"? > > > > > > > > > > > > > > > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv= _mode=3Dhd720p > > > > > > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=3Dhd720p > > > > > > > > > > > > > > I disagree: hd720p50 and hd720p60 are different TV modes. > > > > > > > > > > > > I agree, and I don't see how that command-line doesn't express = that? > > > > > > > > > > Oh, I see what you mean: yes, it expresses that. > > > > > But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] mo= des, > > > > > where the TV mode specifies both number of lines and frame rate. > > > > > > > > Only if we're using a named mode, and naming is hard :) > > > > > > That's not true: "640x480,tv_mode=3DPAL-N" would give me a mode with > > > 625 lines and 25 frames/s, "640x480,tv_mode=3DPAL-M" would give me a > > > mode with 525 lines and 30 frames/s. > > > > In that series, "640x480,tv_mode=3DPAL-N" would be rejected as invalid: > > > > https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v1-= 14-3d53ae722097@cerno.tech/ >=20 > It would become supported once the ideas from thread "[PATCH v1 04/35] > drm/modes: Introduce 480i and 576i modes" are implemented... Indeed, but I'm still not sure what your concern is here. "640x480,tv_mode=3DPAL-N" and "640x480,tv_mode=3DPAL-M" are both fairly obvious. You were initially saying that you had concern over the inconsistency of NTSC/PAL/SECAM where the TV mode would specify a number of lines and frame rate, but hd720p50 also specifies a number of line and frame rate? Maxime --rgjjcrwq24n3fk6k Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYv5SrAAKCRDj7w1vZxhR xXOeAP4xRmnMVN7/AVY7/uaHcHK2PeXpYI7/wh8vab/NDtQGWAD+LBoFZbUfz3kt HC6p3zpvWUaMbbbcZkWajF4mKGTE3QE= =VOq1 -----END PGP SIGNATURE----- --rgjjcrwq24n3fk6k--