From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8745BC0015E for ; Thu, 27 Jul 2023 17:11:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230331AbjG0RLF (ORCPT ); Thu, 27 Jul 2023 13:11:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43606 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229870AbjG0RLD (ORCPT ); Thu, 27 Jul 2023 13:11:03 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C7BC30E3; Thu, 27 Jul 2023 10:11:00 -0700 (PDT) Received: from nicolas-tpx395.localdomain (unknown [IPv6:2606:6d00:10:580::7a9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nicolas) by madras.collabora.co.uk (Postfix) with ESMTPSA id AB2A666015A0; Thu, 27 Jul 2023 18:10:56 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1690477858; bh=E2DEXdpIOFGoKjwDPsij+hvboO8PwGO9KDMyYSS8/g8=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=PO2HdFdaDesVZug0aiSrvrGIcYwCWh0/En+KEJmYoLDvpbf3y5clLKeL7Qx9leBy4 SvmCFI2bqj0dUTPWpxWoOI7N5a7ed+DUHs1igWV+rVHtyzrZ9OlxKPJzBKCBgzlXdB WkTitGe2C0HzOy1B1dHDm4W/PL6YmfOnIID1VCWZ2SYCUYUCo820L2krj2z18mQ6Ga OdBGNJHUSWtvmRZk16cveAszn809lMB/unrCyFDDY2+HRtRf3dFkVy/OpEGxM024pY oIKP16WG/UyofGetUUb1mel9zsTkKSyGq5IDWHNNm+hSAnuphkCf2S85utev9dYYT3 K6rMPkvvzE8JQ== Message-ID: <8f0fbb7c3c18c211b4d407dc1b45539a1ce41766.camel@collabora.com> Subject: Re: Stateless Encoding uAPI Discussion and Proposal From: Nicolas Dufresne To: Hsia-Jun Li Cc: linux-kernel@vger.kernel.org, Paul Kocialkowski , linux-media@vger.kernel.org, Hans Verkuil , Sakari Ailus , Andrzej Pietrasiewicz , Michael Tretter , Jernej =?UTF-8?Q?=C5=A0krabec?= , Chen-Yu Tsai , Samuel Holland , Thomas Petazzoni Date: Thu, 27 Jul 2023 13:10:47 -0400 In-Reply-To: References: <87cfcdfadee89984496c3f52d01b4f1e10c12cae.camel@collabora.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 List-ID: X-Mailing-List: linux-media@vger.kernel.org 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