Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i8771445c:Fastmail
Date:   Thu, 24 Nov 2022 12:49:45 +0100
From:   Maxime Ripard <maxime@cerno.tech>
To:     Samuel Holland <samuel@sholland.org>,
        Jernej Skrabec <jernej.skrabec@gmail.com>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@intel.com>,
        Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
        Ben Skeggs <bskeggs@redhat.com>, Chen-Yu Tsai <wens@csie.org>,
        David Airlie <airlied@linux.ie>,
        Jani Nikula <jani.nikula@linux.intel.com>,
        Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
        Emma Anholt <emma@anholt.net>,
        Karol Herbst <kherbst@redhat.com>,
        Lyude Paul <lyude@redhat.com>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Dave Stevenson <dave.stevenson@raspberrypi.com>,
        Hans de Goede <hdegoede@redhat.com>,
        nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
        Noralf =?utf-8?Q?Tr=C3=B8nnes?= <noralf@tronnes.org>,
        dri-devel@lists.freedesktop.org,
        Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-sunxi@lists.linux.dev, Dom Cobley <dom@raspberrypi.com>,
        Phil Elwell <phil@raspberrypi.com>,
        Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [PATCH v10 00/19] drm: Analog TV Improvements
Message-ID: <20221124114945.oqilsc7zjth4jwso@houat>
References: <20220728-rpi-analog-tv-properties-v10-0-256dad125326@cerno.tech>
 <Y3uQbuQotGxh+XPS@phenom.ffwll.local>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="apvrjccnplb3u7fu"
Content-Disposition: inline
In-Reply-To: <Y3uQbuQotGxh+XPS@phenom.ffwll.local>
Precedence: bulk


--apvrjccnplb3u7fu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 21, 2022 at 03:51:26PM +0100, Daniel Vetter wrote:
> On Thu, Nov 17, 2022 at 10:28:43AM +0100, Maxime Ripard wrote:
> > Hi,
> >=20
> > Here's a series aiming at improving the command line named modes suppor=
t,
> > and more importantly how we deal with all the analog TV variants.
> >=20
> > The named modes support were initially introduced to allow to specify t=
he
> > analog TV mode to be used.
> >=20
> > However, this was causing multiple issues:
> >=20
> >   * The mode name parsed on the command line was passed directly to the
> >     driver, which had to figure out which mode it was suppose to match;
> >=20
> >   * Figuring that out wasn't really easy, since the video=3D argument o=
r what
> >     the userspace might not even have a name in the first place, but
> >     instead could have passed a mode with the same timings;
> >=20
> >   * The fallback to matching on the timings was mostly working as long =
as
> >     we were supporting one 525 lines (most likely NSTC) and one 625 lin=
es
> >     (PAL), but couldn't differentiate between two modes with the same
> >     timings (NTSC vs PAL-M vs NSTC-J for example);
> >=20
> >   * There was also some overlap with the tv mode property registered by
> >     drm_mode_create_tv_properties(), but named modes weren't interacting
> >     with that property at all.
> >=20
> >   * Even though that property was generic, its possible values were
> >     specific to each drivers, which made some generic support difficult.
> >=20
> > Thus, I chose to tackle in multiple steps:
> >=20
> >   * A new TV mode property was introduced, with generic values, each dr=
iver
> >     reporting through a bitmask what standard it supports to the usersp=
ace;
> >=20
> >   * This option was added to the command line parsing code to be able to
> >     specify it on the kernel command line, and new atomic_check and res=
et
> >     helpers were created to integrate properly into atomic KMS;
> >=20
> >   * The named mode parsing code is now creating a proper display mode f=
or
> >     the given named mode, and the TV standard will thus be part of the
> >     connector state;
> >=20
> >   * Two drivers were converted and tested for now (vc4 and sun4i), with
> >     some backward compatibility code to translate the old TV mode to the
> >     new TV mode;
> >=20
> > Unit tests were created along the way.
> >=20
> > One can switch from NTSC to PAL now using (on vc4)
> >=20
> > modetest -M vc4  -s 53:720x480i -w 53:'TV mode':1 # NTSC
> > modetest -M vc4  -s 53:720x576i -w 53:'TV mode':4 # PAL
> >=20
> > Let me know what you think,
> > Maxime
>=20
> Maxime asked me to drop an Ack-in-principle on this, and I'm not sure I
> have any useful input here with my utter lack of understanding for TV
> things (I never even had one in my entire life, that's how much I don't
> care). But it seems to check all the design boxes around solving annoying
> uapi/kms-config issues properly, so
>=20
> Acked-in-principle-or-something-like-that-by: Daniel Vetter <daniel.vette=
r@ffwll.ch>

Thanks!

I jumped the gun a bit too fast and forgot to amend the TV property
commit message before pushing it out.

For the record though, that property is usable through xrandr, xorg.conf
or any equivalent compositor mechanism

Maxime

--apvrjccnplb3u7fu
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCY39aWQAKCRDj7w1vZxhR
xacgAP9NPkwQFyz0CvvFS5SzvELVnj6t9GBuTq/qrHpTLaRyaAD9GJpLyjLeg7Jy
Z0pnBngL2vXGtvYVUCMQy5VhVkMtuAg=
=fhxt
-----END PGP SIGNATURE-----

--apvrjccnplb3u7fu--