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;
Message-ID: <03f6fd9ff6a757f6d1cb6cc552efcb0b94327104.camel@ndufresne.ca>
Subject: Re: [RFC PATCH v6 02/11] media: v4l2: Extend pixel formats to unify
 single/multi-planar handling (and more)
From:   Nicolas Dufresne <nicolas@ndufresne.ca>
To:     Hsia-Jun Li <Randy.Li@synaptics.com>,
        Helen Koike <helen.koike@collabora.com>
Cc:     mchehab@kernel.org, hans.verkuil@cisco.com,
        laurent.pinchart@ideasonboard.com, sakari.ailus@iki.fi,
        boris.brezillon@collabora.com, hiroh@chromium.org,
        Brian.Starkey@arm.com, kernel@collabora.com,
        narmstrong@baylibre.com, linux-kernel@vger.kernel.org,
        frkoenig@chromium.org, stanimir.varbanov@linaro.org,
        tfiga@chromium.org, Hans Verkuil <hverkuil@xs4all.nl>,
        linux-media@vger.kernel.org
Date:   Thu, 10 Nov 2022 12:06:59 -0500
In-Reply-To: <708221e8-a805-c394-6958-6c7ec24bfe66@synaptics.com>
References: <20210114180738.1758707-1-helen.koike@collabora.com>
         <20210114180738.1758707-3-helen.koike@collabora.com>
         <d0d1f74f-7e77-1b18-0529-dbbec8889584@xs4all.nl>
         <577c56bf-146c-f34a-2028-075170076de7@collabora.com>
         <708221e8-a805-c394-6958-6c7ec24bfe66@synaptics.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) 
MIME-Version: 1.0
Precedence: bulk

Le samedi 05 novembre 2022 =C3=A0 23:19 +0800, Hsia-Jun Li a =C3=A9crit=C2=
=A0:
> > > VIDIOC_ENUM_EXT_PIX_FMT would report NV12 and NV12M, while=20
> > > VIDIOC_ENUM_FMT
> > > would just report NV12M.
> >=20
> > If NV12 and NV12M are equivalent in Ext API, I don't see why we would
> > report both (unless I'm missing something, which is probably the case).
> >=20
> > The idea was to deprecate the M-variants one day.
> I was thinking the way in DRM API is better, always assuming it would=20
> always in a multiple planes. The only problem is we don't have a way to=
=20
> let the allocator that allocate contiguous memory for planes when we=20
> need to do that.

Its not too late to allow this to be negotiated, but I would move this out =
of
the pixel format definition to stop the explosion of duplicate pixel format=
s,
which is a nightmare to deal with. If I simplify the discussion, we want to
negotiate contiguity with the driver. The new FMT structure should have a
CONTIGUOUS flag. So if userpace sets:

  S_FMT(NV12, CONTIGUOUS)

The driver can accepts, and return the unmodified structure, or may drop th=
e
CONTIGUOUS flag, which would mean its not supported. Could be the other way
around too. As for allocation, if you have CONTIGUOUS flag set, userspace d=
oes
not have to export or map memory for each planes, as they are the same. We
simply need to define the offset as relative to their allocation, which I t=
hink
is the most sensible thing.

Nicolas