[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <nr7wzo7smtq2mbtorhw4slgtvmj6nyk3witjcymwzk7efrftlc@obgey7ky5hpp>
Date: Thu, 31 Oct 2024 10:13:13 +0100
From: Stefan Klug <stefan.klug@...asonboard.com>
To: Umang Jain <umang.jain@...asonboard.com>
Cc: libcamera-devel@...ts.libcamera.org, linux-media@...r.kernel.org,
linux-kernel@...r.kernel.org, Sakari Ailus <sakari.ailus@...ux.intel.com>,
Kieran Bingham <kieran.bingham@...asonboard.com>, Mauro Carvalho Chehab <mchehab@...nel.org>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH] media: imx283: Report correct V4L2_SEL_TGT_CROP
Hi Umang,
On Thu, Oct 31, 2024 at 11:07:00AM +0530, Umang Jain wrote:
> Hi Stefan
>
> On 30/10/24 10:04 pm, Stefan Klug wrote:
> > The target crop rectangle is initialized with the crop of the default
> > sensor mode. This is incorrect when a different sensor mode gets
> > selected. Fix that by updating the crop rectangle when changing the
> > sensor mode.
> >
> > Signed-off-by: Stefan Klug <stefan.klug@...asonboard.com>
> > ---
> > drivers/media/i2c/imx283.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/media/i2c/imx283.c b/drivers/media/i2c/imx283.c
> > index 3174d5ffd2d7..c8863c9e0ccf 100644
> > --- a/drivers/media/i2c/imx283.c
> > +++ b/drivers/media/i2c/imx283.c
> > @@ -1123,6 +1123,7 @@ static int imx283_set_pad_format(struct v4l2_subdev *sd,
> > struct v4l2_subdev_state *sd_state,
> > struct v4l2_subdev_format *fmt)
> > {
> > + struct v4l2_rect *crop;
> > struct v4l2_mbus_framefmt *format;
> > const struct imx283_mode *mode;
> > struct imx283 *imx283 = to_imx283(sd);
> > @@ -1149,6 +1150,9 @@ static int imx283_set_pad_format(struct v4l2_subdev *sd,
> > *format = fmt->format;
> > + crop = v4l2_subdev_state_get_crop(sd_state, IMAGE_PAD);
> > + *crop = mode->crop;
> > +
>
> One thing to note, is the crop for binning modes.
>
> Do you need to report
>
> mode->crop.width / mode->hbin_ratio
> mode->crop.height / mode->vbin_ratio
>
> for those modes?
Good point. I was naively assuming that it has the same semantics as we
use for ScalerCrop in libcamera where it is explicitly stated that the
coordinates are in sensor pixels without binning. That has the added
advantage that we can deduce the binning factor from TGT_CROP and the
actual output size. However I couldn't find a precise specification for
that in the linux docs.
Maybe Sakari or Laurent have a definiteve answer there?
Best regards,
Stefan
>
> > return 0;
> > }
>
Powered by blists - more mailing lists