public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
	Robert Mader <robert.mader@collabora.com>,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	linux-media@vger.kernel.org
Subject: Re: [PATCH 2/3] media: imx258: Register H/V flip controls
Date: Wed, 25 Jan 2023 14:49:09 +0200	[thread overview]
Message-ID: <Y9ElRb1SJXg+liSG@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20230117102839.yg4jl6iuslut62ve@uno.localdomain>

Hello,

On Tue, Jan 17, 2023 at 11:28:39AM +0100, Jacopo Mondi wrote:
> On Tue, Jan 17, 2023 at 10:17:13AM +0000, Sakari Ailus wrote:
> > On Tue, Jan 17, 2023 at 11:06:02AM +0100, Jacopo Mondi wrote:
> > > Register controls for V4L2_CID_HFLIP and V4L2_CID_VFLIP.
> > >
> > > The controls are registered as read-only and enabled by default, as the
> > > driver embeds a 180 degrees rotation in its programming sequences and
> > > only supports that mode of operations.
> > >
> > > Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
> > > ---
> > >  drivers/media/i2c/imx258.c | 14 +++++++++++++-
> > >  1 file changed, 13 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> > > index 3b560865b657..2e0a4ea76589 100644
> > > --- a/drivers/media/i2c/imx258.c
> > > +++ b/drivers/media/i2c/imx258.c
> > > @@ -1151,6 +1151,7 @@ static int imx258_init_controls(struct imx258 *imx258)
> > >  	struct i2c_client *client = v4l2_get_subdevdata(&imx258->sd);
> > >  	struct v4l2_fwnode_device_properties props;
> > >  	struct v4l2_ctrl_handler *ctrl_hdlr;
> > > +	struct v4l2_ctrl *vflip, *hflip;
> > >  	s64 vblank_def;
> > >  	s64 vblank_min;
> > >  	s64 pixel_rate_min;
> > > @@ -1158,7 +1159,7 @@ static int imx258_init_controls(struct imx258 *imx258)
> > >  	int ret;
> > >
> > >  	ctrl_hdlr = &imx258->ctrl_handler;
> > > -	ret = v4l2_ctrl_handler_init(ctrl_hdlr, 11);
> > > +	ret = v4l2_ctrl_handler_init(ctrl_hdlr, 13);
> > >  	if (ret)
> > >  		return ret;
> > >
> > > @@ -1174,6 +1175,17 @@ static int imx258_init_controls(struct imx258 *imx258)
> > >  	if (imx258->link_freq)
> > >  		imx258->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> > >
> > > +	/* The driver only supports one bayer order and flips by default. */
> > > +	hflip = v4l2_ctrl_new_std(ctrl_hdlr, &imx258_ctrl_ops,
> > > +				  V4L2_CID_HFLIP, 1, 1, 1, 1);
> > > +	if (hflip)
> > > +		hflip->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> > > +
> > > +	vflip = v4l2_ctrl_new_std(ctrl_hdlr, &imx258_ctrl_ops,
> > > +				  V4L2_CID_VFLIP, 1, 1, 1, 1);
> >
> > This defaults the controls to 1, which suggests the image is upside down.
> >
> > The rotation property has been used to tell the driver the sensor is upside
> 
> Well the rotation property should tell userspace how the camera is
> mounted, not to the driver how to compensate it ? There are several
> reasons not to automatically compensate in the driver, mostly the fact
> that the desired rotation to have the images in the "right"
> orientation might require a transpose (as in example for 90 degrees or
> 270 degrees mounting rotations) which sensors cannot actually do.
> 
> I would rather inform userspace of the mounting rotation and the
> sensor capabilities and have them decide how to compensate it.
> 
> > down, and this has also had the effect of reversing flip contron values so
> > if they're disabled, the image is upright.
> 
> Ok, but why should the driver only accept a mounting rotation of 180
> degrees ? If your sensor is mounted on a mobile device (as the
> PinephonPro where this sensor is used) the phyisical mounting rotation
> is actually 270 degrees.
> 
> Userspace will see that flips are not writable, the rotation to
> compensate is 270 degrees, and will handle that as it like the most.

This sounds good to me. The alternative would be to avoid exposing the
flip controls to userspace, and add 180 to the rotation reported in DT
before passing it to userspace. I don't think that's the right option,
drivers shouldn't try to hide this.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> > See e.g. the CCS driver.
> >
> > I'd do the same here.
> >
> > > +	if (vflip)
> > > +		vflip->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> > > +
> > >  	pixel_rate_max = link_freq_to_pixel_rate(link_freq_menu_items[0]);
> > >  	pixel_rate_min = link_freq_to_pixel_rate(link_freq_menu_items[1]);
> > >  	/* By default, PIXEL_RATE is read only */

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2023-01-25 12:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-17 10:06 [PATCH 0/3] media: imx258: Remove rotation=<80 requirement Jacopo Mondi
2023-01-17 10:06 ` [PATCH 1/3] media: imx258: Parse and register properties Jacopo Mondi
2023-01-25 12:35   ` Laurent Pinchart
2023-01-17 10:06 ` [PATCH 2/3] media: imx258: Register H/V flip controls Jacopo Mondi
2023-01-17 10:17   ` Sakari Ailus
2023-01-17 10:28     ` Jacopo Mondi
2023-01-25 12:49       ` Laurent Pinchart [this message]
2023-01-17 10:06 ` [PATCH 3/3] media: imx258: Remove mandatory 180 degrees rotation Jacopo Mondi
2023-01-25 12:39   ` Laurent Pinchart
2023-01-26 14:52 ` [PATCH 0/3] media: imx258: Remove rotation=<80 requirement Sakari Ailus
2023-01-26 15:48   ` Dave Stevenson
2023-01-26 16:01     ` Laurent Pinchart
2023-01-26 16:13       ` Dave Stevenson
2023-01-26 16:02     ` Sakari Ailus
2023-01-26 16:44       ` Dave Stevenson
2023-01-26 17:31       ` Jacopo Mondi
2023-01-26 17:58         ` Dave Stevenson
2023-01-26 20:03           ` Jacopo Mondi
2023-01-27 11:08             ` Dave Stevenson
2023-02-27 17:11 ` Jacopo Mondi
2023-02-27 22:09   ` Sakari Ailus
2023-03-17  9:32     ` Robert Mader
2023-03-22 12:27     ` Jacopo Mondi
2023-03-22 12:30       ` Sakari Ailus
2023-03-22 12:32         ` Jacopo Mondi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y9ElRb1SJXg+liSG@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=jacopo.mondi@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=robert.mader@collabora.com \
    --cc=sakari.ailus@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox