From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7DACB3D3332; Wed, 18 Mar 2026 19:22:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773861770; cv=none; b=MYCGAUY+E6OoR+NEe1tYy/9Ng9mWfo+z4nwqESwW3SRph+5LcvX59otBUpg0iu1w+ycyI3VibtUWZN7BnzDRd9bGfFEh1fp6bhsqhOdnweBRA6GTDfD5hG8PJHbBdXAKhsHF+rwK7e+jF8MqEFsusprMybzIdt7ltTWmsj2xTFQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773861770; c=relaxed/simple; bh=Ll45WhgwMYa6zBIyUrJW5YnmEgb6jJL3rc7OwY763ug=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bCn/9CdyiZNpp8j9DtgEWr0AOHaiRpjLHMUV54nuTW5DiKRJQexmG6FgP3PK/kBBNDjGHFUsYkP/vhRYiJGyCLPNY62NToBW1C/F4nTgcx9YlhBwS6FEqutzkXNKXOWW+T3FXhVq/qcSxOX2+hpuNqBW0z+HoyV8ccp7KdTtfow= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=rECeKDh8; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="rECeKDh8" Received: from killaraus.ideasonboard.com (2001-14ba-703d-e500--2a1.rev.dnainternet.fi [IPv6:2001:14ba:703d:e500::2a1]) by perceval.ideasonboard.com (Postfix) with UTF8SMTPSA id 8EF38308; Wed, 18 Mar 2026 20:21:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1773861694; bh=Ll45WhgwMYa6zBIyUrJW5YnmEgb6jJL3rc7OwY763ug=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rECeKDh8pBqWIBLttPOutyaChTiYtzEuTk6Vk3cP0O93mw2h3sl8igc4UKDWSVJhb zZ4ejgIx4CylQoUKC0cqgNd09u5fY/2GGPCk33lIZJ5Ep+ExOymHSbQ3kYl4J7Chpo TAirh1tla1PfF6vQg6ejewGvDeaZp0q6N2KjHnFQ= Date: Wed, 18 Mar 2026 21:22:46 +0200 From: Laurent Pinchart To: Ricardo Ribalda Cc: Hans de Goede , Mauro Carvalho Chehab , Guennadi Liakhovetski , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Yunke Cao Subject: Re: [PATCH 3/3] media: uvcvideo: Allow userspace to increase the meta buffersize Message-ID: <20260318192246.GC718539@killaraus.ideasonboard.com> References: <20260309-uvc-metadata-dmabuf-v1-0-fc8b87bd29c5@chromium.org> <20260309-uvc-metadata-dmabuf-v1-3-fc8b87bd29c5@chromium.org> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260309-uvc-metadata-dmabuf-v1-3-fc8b87bd29c5@chromium.org> On Mon, Mar 09, 2026 at 03:01:56PM +0000, Ricardo Ribalda wrote: > Now we have the metadata size hardcoded to 10 KiB, this is a value that > works fine for bulk cameras or frames with no extra metadata. But not > for all usecases. > > We have seen some cameras that produce more metadata per frame. Eg: Can you tell what camera that is ? > Frame 1 captured (Bytes: 11154) > Frame 2 captured (Bytes: 11616) > Frame 3 captured (Bytes: 11374) > Frame 4 captured (Bytes: 11132) > Frame 5 captured (Bytes: 11594) > Frame 6 captured (Bytes: 11352) > Frame 7 captured (Bytes: 11110) > Frame 8 captured (Bytes: 11572) > Frame 9 captured (Bytes: 11308) > > When this happens, the driver (correctly) marks the metadata as ERROR. Is the maximum metadata size queryable through an XU on your devices ? > This patch let userspace set bigger buffersize via S_FMT. > > Signed-off-by: Ricardo Ribalda > --- > drivers/media/usb/uvc/uvc_metadata.c | 9 +++++++-- > drivers/media/usb/uvc/uvc_queue.c | 2 +- > drivers/media/usb/uvc/uvcvideo.h | 3 ++- > 3 files changed, 10 insertions(+), 4 deletions(-) > > diff --git a/drivers/media/usb/uvc/uvc_metadata.c b/drivers/media/usb/uvc/uvc_metadata.c > index 0a906ae3f971..9de8aba1229e 100644 > --- a/drivers/media/usb/uvc/uvc_metadata.c > +++ b/drivers/media/usb/uvc/uvc_metadata.c > @@ -50,7 +50,7 @@ static int uvc_meta_v4l2_get_format(struct file *file, void *priv, > return -EINVAL; > > fmt->dataformat = stream->meta.format; > - fmt->buffersize = UVC_METADATA_BUF_SIZE; > + fmt->buffersize = stream->meta.buffersize; > > return 0; > } > @@ -63,6 +63,7 @@ static int uvc_meta_v4l2_try_format(struct file *file, void *priv, > struct uvc_device *dev = stream->dev; > struct v4l2_meta_format *fmt = &format->fmt.meta; > u32 fmeta = V4L2_META_FMT_UVC; > + u32 buffersize; > > if (format->type != vfh->vdev->queue->type) > return -EINVAL; > @@ -74,10 +75,12 @@ static int uvc_meta_v4l2_try_format(struct file *file, void *priv, > } > } > > + buffersize = max(UVC_METADATA_BUF_MIN_SIZE, fmt->buffersize); > + > memset(fmt, 0, sizeof(*fmt)); > > fmt->dataformat = fmeta; > - fmt->buffersize = UVC_METADATA_BUF_SIZE; > + fmt->buffersize = buffersize; > > return 0; > } > @@ -103,6 +106,7 @@ static int uvc_meta_v4l2_set_format(struct file *file, void *priv, > return -EBUSY; > > stream->meta.format = fmt->dataformat; > + stream->meta.buffersize = fmt->buffersize; > > return 0; > } > @@ -229,6 +233,7 @@ int uvc_meta_register(struct uvc_streaming *stream) > struct uvc_video_queue *queue = &stream->meta.queue; > > stream->meta.format = V4L2_META_FMT_UVC; > + stream->meta.buffersize = UVC_METADATA_BUF_MIN_SIZE; > > return uvc_register_video_device(dev, stream, queue, > V4L2_BUF_TYPE_META_CAPTURE, > diff --git a/drivers/media/usb/uvc/uvc_queue.c b/drivers/media/usb/uvc/uvc_queue.c > index 68ed2883edb2..89206f761006 100644 > --- a/drivers/media/usb/uvc/uvc_queue.c > +++ b/drivers/media/usb/uvc/uvc_queue.c > @@ -83,7 +83,7 @@ static int uvc_queue_setup(struct vb2_queue *vq, > > switch (vq->type) { > case V4L2_BUF_TYPE_META_CAPTURE: > - size = UVC_METADATA_BUF_SIZE; > + size = stream->meta.buffersize; > break; > > default: > diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h > index 9b4849fda12f..5ba698d2a23d 100644 > --- a/drivers/media/usb/uvc/uvcvideo.h > +++ b/drivers/media/usb/uvc/uvcvideo.h > @@ -409,7 +409,7 @@ struct uvc_stats_stream { > unsigned int max_sof; /* Maximum STC.SOF value */ > }; > > -#define UVC_METADATA_BUF_SIZE 10240 > +#define UVC_METADATA_BUF_MIN_SIZE 10240 I wondered if we should have a max limit to avoid letting userspace starve system memory, but that can already be done through allocation of arbitrarily large image buffers anyway. We need proper memory accounting in V4L2. Reviewed-by: Laurent Pinchart > > /** > * struct uvc_copy_op: Context structure to schedule asynchronous memcpy > @@ -482,6 +482,7 @@ struct uvc_streaming { > struct { > struct uvc_video_queue queue; > u32 format; > + u32 buffersize; > } meta; > > /* Context data used by the bulk completion handler. */ > -- Regards, Laurent Pinchart