public inbox for linux-media@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox