On (21/03/17 09:04), Ricardo Ribalda Delgado wrote: > On Wed, Mar 17, 2021 at 2:31 AM Sergey Senozhatsky > <sergey.senozhatsky.work@xxxxxxxxx> wrote: > > > > On (21/03/16 19:19), Ricardo Ribalda Delgado wrote: > > > > +Configuration of Region of Interest (ROI) > > > > +========================================= > > > > + > > > > +The range of coordinates of the top left corner, width and height of > > > > +areas that can be ROI is given by the ``V4L2_SEL_TGT_ROI_BOUNDS`` target. > > > > +It is recommended for the driver developers to put the top/left corner > > > > +at position ``(0,0)``. The rectangle's coordinates are in global sensor > > > > +coordinates. The units are in pixels and independent of the field of view. > > > > +They are not impacted by any cropping or scaling that is currently being > > > > +used. > > > > > > Can we also mention binning here? > > > > What's binning? Is it in the UVC spec? > > Binning is when you reduce an image by adding up surrounding pixels. > > So you have a 100x100 image that you convert to a 50x50 but showing > the same area of interest. I see. Hmm, not sure if I can comment on this. It's not in the spec, so it might be up to the firmware, maybe. What do you think? > > > > diff --git a/include/uapi/linux/v4l2-common.h b/include/uapi/linux/v4l2-common.h > > > > index 7d21c1634b4d..d0c108fba638 100644 > > > > --- a/include/uapi/linux/v4l2-common.h > > > > +++ b/include/uapi/linux/v4l2-common.h > > > > @@ -78,6 +78,14 @@ > > > > #define V4L2_SEL_TGT_COMPOSE_BOUNDS 0x0102 > > > > /* Current composing area plus all padding pixels */ > > > > #define V4L2_SEL_TGT_COMPOSE_PADDED 0x0103 > > > > +/* Current Region of Interest area */ > > > > +#define V4L2_SEL_TGT_ROI_CURRENT 0x0200 > > > > +/* Default Region of Interest area */ > > > > +#define V4L2_SEL_TGT_ROI_DEFAULT 0x0201 > > > > +/* Region of Interest bounds */ > > > > +#define V4L2_SEL_TGT_ROI_BOUNDS 0x0202 > > > > +/* Set Region of Interest area */ > > > > +#define V4L2_SEL_TGT_ROI 0x0203 > > > > > > Nit: Maybe it could be a good idea to split doc and code. This way the > > > backports/fixes are easier. > > > > I'm quite sure this is the first time I'm being asked to split code > > and documentation :) I'm usually asked to do the opposite - merge code > > and documentation. > > I got answered in both directions. I prefer to split it because the > doc can go to different audience than the code, and then it makes my > life easier when backporting. > > But if you or Laurent prefer otherwise I am of course happy with any option ;) Either way works for me. Laurent, any preferences? -ss
