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: <8f0fbb7c3c18c211b4d407dc1b45539a1ce41766.camel@collabora.com>
Subject: Re: Stateless Encoding uAPI Discussion and Proposal
From:   Nicolas Dufresne <nicolas.dufresne@collabora.com>
To:     Hsia-Jun Li <Randy.Li@synaptics.com>
Cc:     linux-kernel@vger.kernel.org,
        Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
        linux-media@vger.kernel.org, Hans Verkuil <hverkuil@xs4all.nl>,
        Sakari Ailus <sakari.ailus@iki.fi>,
        Andrzej Pietrasiewicz <andrzej.p@collabora.com>,
        Michael Tretter <m.tretter@pengutronix.de>,
        Jernej =?UTF-8?Q?=C5=A0krabec?= <jernej.skrabec@gmail.com>,
        Chen-Yu Tsai <wens@csie.org>,
        Samuel Holland <samuel@sholland.org>,
        Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Date:   Thu, 27 Jul 2023 13:10:47 -0400
In-Reply-To: <b2d75cf6-2e57-65ab-ebf1-caaa17f479e0@synaptics.com>
References: <ZK2NiQd1KnraAr20@aptenodytes>
         <c46d0c53b7e5dc8dcdf7925f3d892024390a8b2b.camel@collabora.com>
         <ZK6zjaJtulRSrn7P@aptenodytes>
         <bbd62e1b-dd0b-e351-110e-040b42d02974@synaptics.com>
         <ZL-8yBhWWChKBDHM@aptenodytes>
         <c15805b0-261b-114a-c29d-b63f00dd8da4@synaptics.com>
         <87cfcdfadee89984496c3f52d01b4f1e10c12cae.camel@collabora.com>
         <b2d75cf6-2e57-65ab-ebf1-caaa17f479e0@synaptics.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

Le jeudi 27 juillet 2023 =C3=A0 10:45 +0800, Hsia-Jun Li a =C3=A9crit=C2=A0=
:
>=20
> On 7/27/23 03:53, Nicolas Dufresne wrote:
> > CAUTION: Email originated externally, do not click links or open attach=
ments unless you recognize the sender and know the content is safe.
> >=20
> >=20
> > Hi,
> >=20
> > Le mercredi 26 juillet 2023 =C3=A0 10:49 +0800, Hsia-Jun Li a =C3=A9cri=
t :
> > > > I am strongly against this approach, instead I think we need to kee=
p all
> > > > vendor-specific parts in the kernel driver and provide a clean unif=
ied userspace
> > > > API.
> > > >=20
> > > We are driving away vendor participation. Besides, the current design=
 is
> > > a performance bottleneck.
> >=20
> >=20

. . .=20

> Or we just define an interface that only FOSS would use.

We explicitly favour FOSS and make API that guaranty you can use the driver=
 with
FOSS. This is not something we do in secret, this is fundamental to being a=
 GPL
project. On DRM side, were the API is a lot more flexible, they explicitly
reject drivers without an actual FOSS user. We don't strictly have to do th=
at in
V4L2, because the API is done at a higher level. But if we were to come up =
with
a lower level abstraction, we'd certainly have this rules.

. . .
>=20

>=20
> Please DO ***NOT*** make a standard that occupied many memory behinds=20
> usersace and a standard that user has to handle the reconstruction=20
> buffer holding with a strange mechanism(I mean reconstruction buffer=20
> lifetime would be manged by userspace manually).

In all fairness, people have limited time, and builds on top of existing
infrastructure. The reason reconstruction buffers won't be exposed is reall=
y
simple to understand. We don't have API in current framework to support all=
 the
allocations happening in codec drivers. If we could not progress without th=
at,
I've sure finding solution would become a priority. But the trith is that w=
e can
live without, and are aiming to move forward without.

We can certainly start a thread on the subject, I even have plenty of ideas=
 how
to introduce these without throwing away all the existing stuff. But only i=
f
there is a clear intention to actually implement it. We have plenty on our =
plate
and exposing reconstruction buffers can certainly wait.

regards,
Nicolas
>=20