All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mikhail Rudenko <mike.rudenko@gmail.com>
To: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
	linux-media@vger.kernel.org, hverkuil@xs4all.nl,
	laurent.pinchart@ideasonboard.com,
	Prabhakar <prabhakar.csengg@gmail.com>,
	Kate Hsuan <hpa@redhat.com>,
	Alexander Shiyan <eagle.alexander923@gmail.com>,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	Tommaso Merciai <tomm.merciai@gmail.com>,
	Umang Jain <umang.jain@ideasonboard.com>,
	Benjamin Mugnier <benjamin.mugnier@foss.st.com>,
	Sylvain Petinot <sylvain.petinot@foss.st.com>,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	Julien Massot <julien.massot@collabora.com>,
	Naushir Patuck <naush@raspberrypi.com>
Subject: Re: [RFC 0/4] Sub-device configuration models
Date: Tue, 22 Oct 2024 20:40:46 +0300	[thread overview]
Message-ID: <87seso592k.fsf@gmail.com> (raw)
In-Reply-To: <mye7inyopwlumstqhycuyk2iuldlsp5axlndyjyxy3j4zqonym@rtfz7ap2e66s>


On 2024-10-22 at 18:05 +02, Jacopo Mondi <jacopo.mondi@ideasonboard.com> wrote:

> Hi Mikhail
>
> On Mon, Oct 21, 2024 at 05:29:33PM +0300, Mikhail Rudenko wrote:
>>
>> Hi, Sakari!
>>
>> On 2024-10-11 at 10:55 +03, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
>>
>> > Hello everyone,
>> >
>> > I've been recently working (with others) on sub-device streams support as
>> > well as on internal pads. The two can be used to make sub-device
>> > configuration more versatile.
>> >
>> > At the same time, the added interfaces are much more useful if we require
>> > specific semantics of those interfaces, so that the user space knows
>> > exactly what e.g. a given selection target signifies. However, as the same
>> > selection rectangle could be used for a different purpose on a non-raw
>> > sensor device, we need a way to tell how should the user space determine
>> > how to use a given interface.
>> >
>> > I'm proposing to solve this problem by introducing sub-device
>> > configuration models, and by the common raw sensor model, also present in
>> > this patchset, in particular.
>> >
>> > This has been (and will, for some time, continue to be) the reason why I
>> > have reviewed few sensor driver related patches lately. As we're
>> > introducing a new interface, it's beneficial to be able to use that
>> > interface right from the start, rather than trying to later on offer
>> > compatibility support, which is almost always a fair amount of work with
>> > less than desirable results in the driver.
>> >
>> > With this solved, I believe we can enable the use of the streams UAPI.
>> >
>> > Comments are welcome.
>> >
>> > The compiled documentation can be found in
>> > <URL:https://www.retiisi.eu/~sailus/v4l2/tmp/meta-format/output/userspace-api/media/v4l/dev-subdev.html#sub-device-configuration-models>
>> > and the patches here
>> > <URL:https://git.linuxtv.org/sailus/media_tree.git/log/?h=metadata>, i.e.
>> > they're on top of the metadata set.
>>
>> I've read the updated documentation you shared, and have a question
>> concerning binning configuration. IIUC binning should be configured via
>> set_selection(V4L2_SEL_TGT_COMPOSE). But I also see some existing
>
> set_selection(V4L2_SEL_TGT_COMPOSE) on the internal image pad, stream
> #0
>
>> drivers configure binning via set_fmt() (imx296) or both set_fmt() and
>> set_selection(V4L2_SEL_TGT_COMPOSE) (imx274). What will be the right way
>
> Existing drivers have adopted creative solutions to allow control of
> the binning factor but all of them are somewhat non-compliant with the
> specs (we went in great lenght in looking at these in the media summit
> 2 years ago). We didn't have internal pads at the time.
>
>> to add binning support to a driver I care about (ov4689), which
>> presently does not implement any binning configuration at all?
>
> Now that you can use internal pads, I would follow what is described
> in patch 3/4 of this series.

Will do so, thanks!

> Thanks
>   j
>
>>
>> --
>> Best regards,
>> Mikhail
>>


--
Best regards,
Mikhail

      reply	other threads:[~2024-10-22 17:41 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-11  7:55 [RFC 0/4] Sub-device configuration models Sakari Ailus
2024-10-11  7:55 ` [RFC 1/4] media: Documentation: Rework embedded data documentation Sakari Ailus
2024-10-22 15:08   ` Jacopo Mondi
2024-11-08 12:23     ` Sakari Ailus
2024-10-22 19:27   ` Laurent Pinchart
2024-10-11  7:55 ` [RFC 2/4] media: Documentation: Reword split of sensor driver to two classes Sakari Ailus
2024-10-22 15:12   ` Jacopo Mondi
2024-10-22 19:39     ` Laurent Pinchart
2024-11-08 12:39       ` Sakari Ailus
2024-11-08 12:57         ` Laurent Pinchart
2024-10-11  7:55 ` [RFC 3/4] media: Documentation: Add subdev configuration models, raw sensor model Sakari Ailus
2024-10-22 16:02   ` Jacopo Mondi
2024-10-22 22:10     ` Laurent Pinchart
2024-11-13  7:35       ` Sakari Ailus
2024-11-13  8:20         ` Jacopo Mondi
2024-11-13 10:18           ` Sakari Ailus
2024-10-11  7:55 ` [RFC 4/4] media: v4l: ctrl: Add V4L2_CID_CONFIG_MODEL control Sakari Ailus
2024-10-22 19:42   ` Laurent Pinchart
2024-11-13  7:37     ` Sakari Ailus
2024-11-13  8:03   ` Hans Verkuil
2024-11-13  8:35     ` Sakari Ailus
2024-11-13 12:26       ` Hans Verkuil
2024-11-18  2:40         ` Laurent Pinchart
2025-02-11  8:31           ` Sakari Ailus
2025-02-13 22:47             ` Laurent Pinchart
2024-10-21 14:29 ` [RFC 0/4] Sub-device configuration models Mikhail Rudenko
2024-10-22 16:05   ` Jacopo Mondi
2024-10-22 17:40     ` Mikhail Rudenko [this message]

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=87seso592k.fsf@gmail.com \
    --to=mike.rudenko@gmail.com \
    --cc=benjamin.mugnier@foss.st.com \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=eagle.alexander923@gmail.com \
    --cc=hpa@redhat.com \
    --cc=hverkuil@xs4all.nl \
    --cc=jacopo.mondi@ideasonboard.com \
    --cc=julien.massot@collabora.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=naush@raspberrypi.com \
    --cc=prabhakar.csengg@gmail.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=sylvain.petinot@foss.st.com \
    --cc=tomm.merciai@gmail.com \
    --cc=umang.jain@ideasonboard.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.