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 Škrabec" <jernej.skrabec@gmail.com>,
	"Chen-Yu Tsai" <wens@csie.org>,
	"Samuel Holland" <samuel@sholland.org>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
Subject: Re: Stateless Encoding uAPI Discussion and Proposal
Date: Thu, 27 Jul 2023 13:10:47 -0400	[thread overview]
Message-ID: <8f0fbb7c3c18c211b4d407dc1b45539a1ce41766.camel@collabora.com> (raw)
In-Reply-To: <b2d75cf6-2e57-65ab-ebf1-caaa17f479e0@synaptics.com>

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

. . . 

> 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 that 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.

. . .
> 

> 
> Please DO ***NOT*** make a standard that occupied many memory behinds 
> usersace and a standard that user has to handle the reconstruction 
> buffer holding with a strange mechanism(I mean reconstruction buffer 
> 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 really
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 that,
I've sure finding solution would become a priority. But the trith is that we 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 if
there is a clear intention to actually implement it. We have plenty on our plate
and exposing reconstruction buffers can certainly wait.

regards,
Nicolas
> 