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:   Wed, 7 Sep 2022 16:34:21 +0200
From:   Maxime Ripard <maxime@cerno.tech>
To:     Mateusz Kwiatkowski <kfyatek@gmail.com>
Cc:     Ben Skeggs <bskeggs@redhat.com>, David Airlie <airlied@linux.ie>,
        Chen-Yu Tsai <wens@csie.org>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Jani Nikula <jani.nikula@linux.intel.com>,
        Lyude Paul <lyude@redhat.com>,
        Philipp Zabel <p.zabel@pengutronix.de>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@intel.com>,
        Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
        Jernej Skrabec <jernej.skrabec@gmail.com>,
        Samuel Holland <samuel@sholland.org>,
        Karol Herbst <kherbst@redhat.com>,
        Noralf =?utf-8?Q?Tr=C3=B8nnes?= <noralf@tronnes.org>,
        Emma Anholt <emma@anholt.net>, Daniel Vetter <daniel@ffwll.ch>,
        Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
        Hans de Goede <hdegoede@redhat.com>,
        linux-arm-kernel@lists.infradead.org,
        Phil Elwell <phil@raspberrypi.com>,
        intel-gfx@lists.freedesktop.org,
        Dave Stevenson <dave.stevenson@raspberrypi.com>,
        dri-devel@lists.freedesktop.org, Dom Cobley <dom@raspberrypi.com>,
        linux-kernel@vger.kernel.org, nouveau@lists.freedesktop.org,
        linux-sunxi@lists.linux.dev,
        Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [PATCH v2 10/41] drm/modes: Add a function to generate analog
 display modes
Message-ID: <20220907143421.4iopqwhp3yfircsh@houat>
References: <20220728-rpi-analog-tv-properties-v2-0-459522d653a7@cerno.tech>
 <20220728-rpi-analog-tv-properties-v2-10-459522d653a7@cerno.tech>
 <242d272b-5b79-986c-9aaf-64e62f6b37ff@gmail.com>
 <20220905133755.gcmmntg3wnecyqjq@houat>
 <10ce686a-d7c8-9ce4-3979-735ad8eab3b5@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="xs3njf2uogpsrjq3"
Content-Disposition: inline
In-Reply-To: <10ce686a-d7c8-9ce4-3979-735ad8eab3b5@gmail.com>
Precedence: bulk


--xs3njf2uogpsrjq3
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 05, 2022 at 06:44:42PM +0200, Mateusz Kwiatkowski wrote:
> Hi Maxime,
>=20
> W dniu 5.09.2022 o 15:37, Maxime Ripard pisze:
> >>> +=A0=A0=A0 vfp =3D vfp_min + (porches_rem / 2);
> >>> +=A0=A0=A0 vbp =3D porches - vfp;
> >>
> >> Relative position of the vertical sync within the VBI effectively move=
s the
> >> image up and down. Adding that (porches_rem / 2) moves the image up of=
f center
> >> by that many pixels. I'd keep the VFP always at minimum to keep the im=
age
> >> centered.
> >
> > And you would increase the back porch only then?
>=20
> Well, increasing vbp only gives a centered image with the default 480i/57=
6i
> resolutions. However, only ever changing vbp will cause the image to be a=
lways
> at the bottom of the screen when the active line count is decreased (e.g.
> setting the resolution to 720x480 but for 50Hz "PAL" - like many game con=
soles
> did back in the day).
>=20
> I believe that the perfect solution would:
>=20
> - Use the canonical / standard-defined blanking line counts for the stand=
ard
> =A0 vertical resolutions (480/486/576)
> - Increase vfp and vbp from there by the same number if a smaller number =
of
> =A0 active lines is specified, so that the resulting image is centered
> - Likewise, decrease vfp and vbp by the same number if the active line nu=
mber
> =A0 is larger and there is still leeway (this should allow for seamless h=
andling
> =A0 of 480i vs. 486i for 60 Hz "NTSC")

I'm not sure I understand how that's any different than the code you
initially commented on.

I would start by taking the entire blanking area, remove the sync
period. We only have the two porches now, and I'm starting from the
minimum, adding as many pixels in both (unless it's not an even number,
in which case the backporch will have the extra pixel).

Isn't it the same thing?

> - If even more active lines are specified, once the limit for vfp is hit,=
 then
> =A0 decrease vbp only - the resulting image will definitely be off-center=
, but
> =A0 there's no other way

Unless you only want me to consider the front porch maximum?

Maxime

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

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

iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYxir7QAKCRDj7w1vZxhR
xYnUAQDKFDkrZV/fLpjtD+btaCpKvPKkEUm37bnBk3TyD3SBTAD+I0kVAytjVinQ
y5KTIrc3dKg0llXX1SWgrvw0OE2vMAI=
=QW9g
-----END PGP SIGNATURE-----

--xs3njf2uogpsrjq3--