Message ID | 20210430112611.475039-1-senozhatsky@chromium.org (mailing list archive) |
---|---|
Headers |
Received: from vger.kernel.org ([23.128.96.18]) by www.linuxtv.org with esmtp (Exim 4.92) (envelope-from <linux-media-owner@vger.kernel.org>) id 1lcRHq-00Eiy2-TZ; Fri, 30 Apr 2021 11:26:23 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231615AbhD3L1I (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Fri, 30 Apr 2021 07:27:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229543AbhD3L1H (ORCPT <rfc822;linux-media@vger.kernel.org>); Fri, 30 Apr 2021 07:27:07 -0400 Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7AD7BC06174A for <linux-media@vger.kernel.org>; Fri, 30 Apr 2021 04:26:19 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id f11-20020a17090a638bb02901524d3a3d48so1549508pjj.3 for <linux-media@vger.kernel.org>; Fri, 30 Apr 2021 04:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=EkTyMd3fqCBBv4Wwr4P1rErcM9uEjejcW+0ZhgpoQpw=; b=I05y6Tr8dAPswoxUR+I2YMNcjW/rP+zuRZLWCGeD/YhQI4o78bukVpRzMQziw4TTz7 /zibhpD9CFsZCqBa4GF89+4kGCs9CZBg41N8ITSxHafuQt0mGuaQ2Ob58M+f7GNMopwL NG2fn2gl/cUiOOrJkXoMAM3svhFWqU1BwErZo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=EkTyMd3fqCBBv4Wwr4P1rErcM9uEjejcW+0ZhgpoQpw=; b=l/Wu2vLCHb0DOHdALQWalnaKH5CoLxMPDgGvh4JkGo+AkqsiZ7dNkAgElx7t/gDIJN ylMzEvT43UkIqkldw16nRrnA6B+GcOLD2pijfHa6ogle5BfsyPwm8HuGv8hPtz0KpY4y Qi/oZ6WW2h+5TekojaXFaa2zN4xgSh27NelanA6frGMLIetFDAcPZngitEHkohfP2o7n A+v2YqsBw9IyM45BEiwm8+rrVqZ1xiDvNGAmpGiaJdT0FukmFlfcWLmpRj7dJdwFWXLF 2X0xDUSQryyWpUsVTmXyfyrv/UXrWNS3/P5n2D45KwF/shKjEBuKIIMMwNzKZhUL6qq/ mcPg== X-Gm-Message-State: AOAM530scmYwuiViHDumjEdRoUS4p/kS82pxJEcRnMcY/L3Kpe/l41ov 4NgaHtoCNKmuAG6SlW0+a2SRqA== X-Google-Smtp-Source: ABdhPJyD8fThwL8MTsk/JrHK3LtPnup9yQcEV9jKiM43GUoIvXfnp1O6y2m6AhTQ0c44IOBYjs6Kvg== X-Received: by 2002:a17:90b:f82:: with SMTP id ft2mr14444595pjb.0.1619781978184; Fri, 30 Apr 2021 04:26:18 -0700 (PDT) Received: from senozhatsky.flets-east.jp ([2409:10:2e40:5100:2c33:77c9:7bef:267e]) by smtp.gmail.com with ESMTPSA id l10sm1809457pjy.42.2021.04.30.04.26.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Apr 2021 04:26:17 -0700 (PDT) From: Sergey Senozhatsky <senozhatsky@chromium.org> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Ricardo Ribalda <ribalda@chromium.org> Cc: Tomasz Figa <tfiga@chromium.org>, Mauro Carvalho Chehab <mchehab@kernel.org>, Hans Verkuil <hverkuil-cisco@xs4all.nl>, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky <senozhatsky@chromium.org> Subject: [PATCHv4 0/5] media: uvcvideo: implement UVC 1.5 ROI Date: Fri, 30 Apr 2021 20:26:06 +0900 Message-Id: <20210430112611.475039-1-senozhatsky@chromium.org> X-Mailer: git-send-email 2.31.1.527.g47e6f16901-goog MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-LSpam-Score: -7.5 (-------) X-LSpam-Report: No, score=-7.5 required=5.0 tests=BAYES_00=-1.9,DKIMWL_WL_HIGH=0.001,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1,RCVD_IN_DNSWL_HI=-5 autolearn=ham autolearn_force=no |
Series |
media: uvcvideo: implement UVC 1.5 ROI
|
|
Message
Sergey Senozhatsky
April 30, 2021, 11:26 a.m. UTC
Hello, This patch set implements UVC 1.5 ROI using v4l2_selection API. v4: -- split ROI rect selection API and auto-controls -- handle very large ROI rectangles: limit to frame dimensions Sergey Senozhatsky (5): media: v4l UAPI: add ROI selection targets media: v4l UAPI: document ROI selection targets media: uvcvideo: add ROI auto controls media: v4l UAPI: document ROI auto_controls media: uvcvideo: add UVC 1.5 ROI control .../media/v4l/ext-ctrls-camera.rst | 23 +++ .../media/v4l/selection-api-configuration.rst | 22 +++ .../media/v4l/selection-api-examples.rst | 27 +++ .../media/v4l/v4l2-selection-targets.rst | 24 +++ drivers/media/usb/uvc/uvc_ctrl.c | 19 ++ drivers/media/usb/uvc/uvc_v4l2.c | 185 +++++++++++++++++- include/uapi/linux/usb/video.h | 1 + include/uapi/linux/v4l2-common.h | 8 + include/uapi/linux/v4l2-controls.h | 9 + 9 files changed, 315 insertions(+), 3 deletions(-)
Comments
Hi Sergey, On 30/04/2021 13:26, Sergey Senozhatsky wrote: > Hello, > > This patch set implements UVC 1.5 ROI using v4l2_selection API. Is the selection API the right approach for this? Wouldn't it make sense to use controls instead? That would interface easily with the Request API allowing per-frame changes to the ROI, and with dynamic array controls (1) it allows you to provide multiple ROIs as well. The only missing piece would be MIN/MAX for compound controls, but that can easily be added to the control framework. If this was discussed before, then can you give a me pointer to that discussion? I couldn't find anything for that, but I didn't look very long for it :-) In any case, it doesn't really feel like it is the right API for this job. I really need to review this series when I have a bit more time :-( Regards, Hans (1) https://patchwork.linuxtv.org/project/linux-media/cover/20210428101841.696059-1-hverkuil-cisco@xs4all.nl/ > > v4: > -- split ROI rect selection API and auto-controls > -- handle very large ROI rectangles: limit to frame dimensions > > Sergey Senozhatsky (5): > media: v4l UAPI: add ROI selection targets > media: v4l UAPI: document ROI selection targets > media: uvcvideo: add ROI auto controls > media: v4l UAPI: document ROI auto_controls > media: uvcvideo: add UVC 1.5 ROI control > > .../media/v4l/ext-ctrls-camera.rst | 23 +++ > .../media/v4l/selection-api-configuration.rst | 22 +++ > .../media/v4l/selection-api-examples.rst | 27 +++ > .../media/v4l/v4l2-selection-targets.rst | 24 +++ > drivers/media/usb/uvc/uvc_ctrl.c | 19 ++ > drivers/media/usb/uvc/uvc_v4l2.c | 185 +++++++++++++++++- > include/uapi/linux/usb/video.h | 1 + > include/uapi/linux/v4l2-common.h | 8 + > include/uapi/linux/v4l2-controls.h | 9 + > 9 files changed, 315 insertions(+), 3 deletions(-) >
Hi Hans, On (21/04/30 14:49), Hans Verkuil wrote: > Hi Sergey, > > On 30/04/2021 13:26, Sergey Senozhatsky wrote: > > Hello, > > > > This patch set implements UVC 1.5 ROI using v4l2_selection API. > > Is the selection API the right approach for this? Wouldn't it make > sense to use controls instead? [..] > If this was discussed before, then can you give a me pointer to that discussion? > I couldn't find anything for that, but I didn't look very long for it :-) I believe Tomasz raised this question over IRC back in the days and there was no clear conclusion at the end: selection API vs control - 50/50 split. After internal discussions we decided to go with the selection API. > In any case, it doesn't really feel like it is the right API for this job. Well, we pass a rectangle to the driver. The driver already knows what to do with some of those rectangles, we teach it to handle one more. So we don't introduce anything new, but use the existing API instead.
On (21/04/30 20:26), Sergey Senozhatsky wrote: > v4: > -- split ROI rect selection API and auto-controls > -- handle very large ROI rectangles: limit to frame dimensions Please ignore this series. I just sent out v5 with UAPI fixes.
On 01/05/2021 03:58, Sergey Senozhatsky wrote: > Hi Hans, > > On (21/04/30 14:49), Hans Verkuil wrote: >> Hi Sergey, >> >> On 30/04/2021 13:26, Sergey Senozhatsky wrote: >>> Hello, >>> >>> This patch set implements UVC 1.5 ROI using v4l2_selection API. >> >> Is the selection API the right approach for this? Wouldn't it make >> sense to use controls instead? > > [..] > >> If this was discussed before, then can you give a me pointer to that discussion? >> I couldn't find anything for that, but I didn't look very long for it :-) > > I believe Tomasz raised this question over IRC back in the days and there > was no clear conclusion at the end: selection API vs control - 50/50 split. > After internal discussions we decided to go with the selection API. > >> In any case, it doesn't really feel like it is the right API for this job. > > Well, we pass a rectangle to the driver. The driver already knows what > to do with some of those rectangles, we teach it to handle one more. So > we don't introduce anything new, but use the existing API instead. > Yes, but this works for only one ROI since the Selection API has no provision for rectangle arrays, but with the upcoming dynamic array control support this is trivial for controls. In addition, controls are already integrated in the Request API, so this will automatically work with requests as well. I don't remember being involved in the irc discussion (if I was, I don't remember it), and that discussion definitely did not know about dynamic arrays since that's brand new and not even merged yet and may even precede the Request API depending on how long ago the irc discussion was. I think being able to provide multiple ROI rectangles is an obvious feature in general, even if UVC currently supports only a single rectangle. Ditto for being able to use them in a request. You get both for free when using controls. Before I can accept this series I think I need to have feedback from others why they believe the Selection API is the right API to use. Regards, Hans