[ANN] Media Summit at ELCE Dublin, September 12: Draft Agenda V1

[ANN] Media Summit at ELCE Dublin, September 12: Draft Agenda V1

[Hans Verkuil]

Hi all,

Here is some more information about the Media Summit:

Date: Monday September 12
Time: 9:00-17:00
Location: Convention Centre Dublin
Room: The Liffey B - Part 1 (subject to change)
Sponsored by: Cisco Systems Norway and Collabora

We will have a projector or display to show presentations, power strips,
a whiteboard and beverages. For lunch we are on our own.

It's co-located with the OSS Europe conference:

https://events.linuxfoundation.org/open-source-summit-europe/

Attendees:

Sakari Ailus <sakari.ailus@linux.intel.com>
Kieran Bingham <kieran.bingham@ideasonboard.com>
Nicolas Dufresne <nicolas@ndufresne.ca>
Benjamin Gaignard <benjamin.gaignard@collabora.com>
Hidenori Kobayashi <hidenorik@chromium.org>
Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Jacopo Mondi <jacopo@jmondi.org>
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Ricardo Ribalda <ribalda@chromium.org>
Maxime Ripard <maxime@cerno.tech>
Daniel Scally <djrscally@gmail.com>
Jernej Škrabec <jernej.skrabec@gmail.com>
Dave Stevenson <dave.stevenson@raspberrypi.com> (from 11 am onwards)
Hans Verkuil <hverkuil@xs4all.nl>
Philipp Zabel <p.zabel@pengutronix.de>

Note: there are 5 seats left, so if you are interested in this, mail me.

The health and safety regulations will be those of the OSSE LF:

https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/

We strongly recommend that you do a self-test before going to the Conference Centre
for this meeting.

Code of conduct:

https://events.linuxfoundation.org/open-source-summit-europe/attend/code-of-conduct/


Based on the submitted topics I have made a first draft of the agenda. I have tried
to keep the sensor-related topics to after 11:00 since Dave comes in later in the day.

I am also making the (reasonable) assumption that most (if not all) attendees will be
attending the ELCE/OSSE conference Tue-Fri as well. While it is nice if we can come
to a conclusion in the time allotted for each topic, it's also OK if we can set up
a small group that can discuss it further in the following days.

If you raised a discussion topic, but will be in Dublin for only the Monday, then
let me know.

I added a guesstimate of the time needed for each topic. If you think that guesstimate
is wildly off, then let me know. But remember: it's fine if we decide to discuss it
further in the following days in a smaller group.

If you present a topic, then please make a presentation. And if you have material you
can share beforehand, then that would be great.

Draft Agenda V1:

 9:00 Getting settled
 9:20 Introduction
 9:30 Hans: Presentation on CTA-861 & edid-decode
 9:45 Nicolas: Stateless encoder progress
10:15 Ricardo: Introduce ChromeOS camera project

11:00 Break

11:15 Kieran: Fault tolerance

  I raised this in the past when we first started hitting the issue on
  Renesas platforms with multiple cameras in a single media graph, but now
  I think it's become more critical with desktop / laptop devices that are
  hitting the issue (i.e. the IPU3).

  Summary of issue:

  - Multiple cameras that can function independently successfully, are
    prevented from functioning or fully probing by V4L2 if one component
    of another camera fails to load or probe.

    If Camera A has a VCM, and Camera B does not, Camera B will not be
    available at all if Camera A's VCM is not fully probed, even though
    Camera B can be fully functional and complete.

    Even if Camera A does not have the VCM probed, it may still function
    successfully (with a fixed focal position) - but our current
    implementation will mean that it will not even be available to
    capture images.

  We talked about this quite a long time ago, and I believe the general
  consensus was that we can have events on the media graph. But
  unfortunately at the time, there was no development scheduled on that,
  and it wasn't something I was able to continue at the time.

  I'd like to bring it up to refresh the topic, and see if we can make
  some progress as it's now affecting more general devices.

11:45 Jacopo: Representing addition sensor processing stages.

  How to represent additional processing stages that happens
  on the sensor side, mostly additional subsampling/cropping that happen
  between the analogue cropping on the full pixel array and the final
  image sent on the wire.

  https://lore.kernel.org/linux-media/CAPY8ntA06L1Xsph79sv9t7MiDSNeSO2vADevuXZdXQdhWpSmow@mail.gmail.com/

  Dave made a good introduction of the issue his email which got
  largely unanswered.

  The issue is particularly relevant for RAW sensors, where applying
  subsampling has an impact on the sensor's sensitivity and requires
  to adjust the gains and exposure accordingly.

  The V4L2 selection API falls short on this and the only other
  solution I am aware of is registering additional subdevices as the
  CCS driver does.

12:30 Lunch

13:30 Dave: On-sensor temperature reporting.

  Thread started by Benjamin at
  https://lore.kernel.org/linux-media/20220415111845.27130-3-benjamin.mugnier@foss.st.com/
  but no resolution over using hwmon API or V4L2 control. If hwmon
  then we need Media Controller framework to tie the sensor and thermal
  device together.

  It's recently been queried for IMX477 with the Pi
  (https://github.com/raspberrypi/libcamera/issues/19), but it will
  apply to many sensors.

13:45 Dave: Synchronising sensors for stereoscopic operation.

  How should that be configured? Allowing configuration from userspace
  would allow sensors to be operated independently which can be useful for
  test purposes, or should it be enforced from DT/ACPI? Do we set a default
  configuration for each sensor from DT/ACPI and then allow userspace to
  override should it wish?

14:00 Dave: Lens drivers.

  Each driver will have a "useful" range which is effectively dictated by
  the overall module. Should that be defined via DT as it is a feature of
  the platform, or leave the driver totally generic and expect userspace
  to do something sensible?

  In the case of simple systems without libcamera, do we set default for
  V4L2_CID_FOCUS_ABSOLUTE to a sensible hyperfocal distance, and can
  that again be defined in DT as it is defining the hardware?

14:15 Dave: Controlling sensor GPIO outputs.

  Controlling sensor GPIO outputs for things such as flash triggers,
  vsync, frame start/end, exposure start/end, etc.

  There is a huge range of features available so do we have any hope of
  standardising some of it, or do we end up hiding these away in the
  drivers with custom DT bindings to configure them? If we accept that
  there will be variation, can we vaguely standardise what those
  bindings look like? Or should these be V4L2 controls as things like
  pulse widths may want to be adjusted by userspace?

14:30 Jacopo: Reconcile handling of regulator, gpios and clock on OF and ACPI platforms.

  We recently got a few series trying to reconcile handling of regulators,
  gpios and clocks on OF and ACPI platforms all of them doing the usual
  "similar but slightly different" thing:

  https://lore.kernel.org/linux-media/20220425061022.1569480-1-paul.elder@ideasonboard.com/
  https://lore.kernel.org/linux-media/20220329090133.338073-1-jacopo@jmondi.org/
  https://lore.kernel.org/linux-media/20220509143226.531117-1-foss+kernel@0leil.net/
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c2c7a1e0d69221b9d489bfd8cf53262d6f82446

  ACPI and OF handles clocks slightly differently, and it is not clear
  to me if ACPI based platform need explicit handling of
  clocks/regulator or ACPI does "the right thing" by itself (I'm
  afraid the answer is actually "it depends"). I'm ACPI illiterate
  so I cannot propose anything meaningful but if anyone is interested
  in discussing this further this might be a good time to do so ?

15:00 Break

15:30 Laurent: V4L2 streams series.

  I'd like to discuss the V4L2 streams series, in particular how to
  upstream the parts that won't be upstream yet by mid-September.
  Discussing the next steps would also be useful, as there's lots we could
  build on top.

16:00 Laurent: How can we finalize conversion of v4l-utils to meson?

16:15-17:00 Anything else?

Regards,

	Hans

Re: [ANN] Media Summit at ELCE Dublin, September 12: Draft Agenda V1

[Laurent Pinchart]

Hi Hans,

On Fri, Aug 05, 2022 at 01:35:48PM +0200, Hans Verkuil wrote:
> Hi all,
> 
> Here is some more information about the Media Summit:
> 
> Date: Monday September 12
> Time: 9:00-17:00
> Location: Convention Centre Dublin
> Room: The Liffey B - Part 1 (subject to change)
> Sponsored by: Cisco Systems Norway and Collabora
> 
> We will have a projector or display to show presentations, power strips,
> a whiteboard and beverages. For lunch we are on our own.

Thank you for arranging all this, and thank you to Cisco and Collabora
for the sponsorship.

> It's co-located with the OSS Europe conference:
> 
> https://events.linuxfoundation.org/open-source-summit-europe/
> 
> Attendees:
> 
> Sakari Ailus <sakari.ailus@linux.intel.com>
> Kieran Bingham <kieran.bingham@ideasonboard.com>
> Nicolas Dufresne <nicolas@ndufresne.ca>
> Benjamin Gaignard <benjamin.gaignard@collabora.com>
> Hidenori Kobayashi <hidenorik@chromium.org>
> Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> Jacopo Mondi <jacopo@jmondi.org>
> Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Ricardo Ribalda <ribalda@chromium.org>
> Maxime Ripard <maxime@cerno.tech>
> Daniel Scally <djrscally@gmail.com>
> Jernej Škrabec <jernej.skrabec@gmail.com>
> Dave Stevenson <dave.stevenson@raspberrypi.com> (from 11 am onwards)
> Hans Verkuil <hverkuil@xs4all.nl>
> Philipp Zabel <p.zabel@pengutronix.de>
> 
> Note: there are 5 seats left, so if you are interested in this, mail me.
> 
> The health and safety regulations will be those of the OSSE LF:
> 
> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/
> 
> We strongly recommend that you do a self-test before going to the Conference Centre
> for this meeting.
> 
> Code of conduct:
> 
> https://events.linuxfoundation.org/open-source-summit-europe/attend/code-of-conduct/
> 
> 
> Based on the submitted topics I have made a first draft of the agenda. I have tried
> to keep the sensor-related topics to after 11:00 since Dave comes in later in the day.
> 
> I am also making the (reasonable) assumption that most (if not all) attendees will be
> attending the ELCE/OSSE conference Tue-Fri as well. While it is nice if we can come
> to a conclusion in the time allotted for each topic, it's also OK if we can set up
> a small group that can discuss it further in the following days.
> 
> If you raised a discussion topic, but will be in Dublin for only the Monday, then
> let me know.

I will be at Plumbers and Kernel Summit from Tuesday to Thursday, but
may be able to escape on Tuesday to join specific discussions if needed.
I should also be available on Friday, if anyone manages not to catch
covid at the ELCE/OSSE party on Tuesday evening :-)

It will be a busy week.

> I added a guesstimate of the time needed for each topic. If you think that guesstimate
> is wildly off, then let me know. But remember: it's fine if we decide to discuss it
> further in the following days in a smaller group.

Most topics could probably use four times as much as what has been
allocated. That's due to no fault in the agenda, it's just the way
things are.

> If you present a topic, then please make a presentation. And if you have material you
> can share beforehand, then that would be great.

Yes, please. Given the very tight schedule, there will be close to no
time to make presentations. We need to focus on discussions, with
everybody reading the presentation material beforehand. This means
sending presentations ideally at least a week before the workshop. As
far as I'm concerned, an e-mail is good enough, there's no need for
slides unless the topic at hand would really benefit from more graphical
support material.

For anyone opting to present the topic by e-mail, you can reply to this
mail thread, but please change the subject line, for instance to

Subject: [Workshop 2022] V4L2 streams series

> Draft Agenda V1:
> 
>  9:00 Getting settled
>  9:20 Introduction

Is there a way we can open the room 15 minutes earlier for everybody to
get settled, and start the introduction at 9:00 sharp ?

>  9:30 Hans: Presentation on CTA-861 & edid-decode
>  9:45 Nicolas: Stateless encoder progress
> 10:15 Ricardo: Introduce ChromeOS camera project

I expect this topic alone could take the whole day. Ricardo made a
presentation at Kernel Recipes a few months ago, that's good
introductory material (the video has bad quality audio though).
Ricardo, instead of repeating the same presentation, could you focus on
the issues we need to solve to move forward, perhaps with a proposed
plan ?

> 11:00 Break
> 
> 11:15 Kieran: Fault tolerance
> 
>   I raised this in the past when we first started hitting the issue on
>   Renesas platforms with multiple cameras in a single media graph, but now
>   I think it's become more critical with desktop / laptop devices that are
>   hitting the issue (i.e. the IPU3).
> 
>   Summary of issue:
> 
>   - Multiple cameras that can function independently successfully, are
>     prevented from functioning or fully probing by V4L2 if one component
>     of another camera fails to load or probe.
> 
>     If Camera A has a VCM, and Camera B does not, Camera B will not be
>     available at all if Camera A's VCM is not fully probed, even though
>     Camera B can be fully functional and complete.
> 
>     Even if Camera A does not have the VCM probed, it may still function
>     successfully (with a fixed focal position) - but our current
>     implementation will mean that it will not even be available to
>     capture images.
> 
>   We talked about this quite a long time ago, and I believe the general
>   consensus was that we can have events on the media graph. But
>   unfortunately at the time, there was no development scheduled on that,
>   and it wasn't something I was able to continue at the time.
> 
>   I'd like to bring it up to refresh the topic, and see if we can make
>   some progress as it's now affecting more general devices.
> 
> 11:45 Jacopo: Representing addition sensor processing stages.
> 
>   How to represent additional processing stages that happens
>   on the sensor side, mostly additional subsampling/cropping that happen
>   between the analogue cropping on the full pixel array and the final
>   image sent on the wire.
> 
>   https://lore.kernel.org/linux-media/CAPY8ntA06L1Xsph79sv9t7MiDSNeSO2vADevuXZdXQdhWpSmow@mail.gmail.com/
> 
>   Dave made a good introduction of the issue his email which got
>   largely unanswered.
> 
>   The issue is particularly relevant for RAW sensors, where applying
>   subsampling has an impact on the sensor's sensitivity and requires
>   to adjust the gains and exposure accordingly.
> 
>   The V4L2 selection API falls short on this and the only other
>   solution I am aware of is registering additional subdevices as the
>   CCS driver does.
> 
> 12:30 Lunch

I would have proposed having lunch in the room to avoid losing one hour,
but that won't be compatible with the conference's mask mandate. I
suppose an hour of brain rest would be welcome anyway :-)

> 13:30 Dave: On-sensor temperature reporting.
> 
>   Thread started by Benjamin at
>   https://lore.kernel.org/linux-media/20220415111845.27130-3-benjamin.mugnier@foss.st.com/
>   but no resolution over using hwmon API or V4L2 control. If hwmon
>   then we need Media Controller framework to tie the sensor and thermal
>   device together.
> 
>   It's recently been queried for IMX477 with the Pi
>   (https://github.com/raspberrypi/libcamera/issues/19), but it will
>   apply to many sensors.

Dave, it would be very useful if you could summarize, based on your
experience, how that information is reported by sensors (I2C reads,
embedded data, ..., but also single value, multiple values, ...) and
what use cases are expected to consume it.

> 13:45 Dave: Synchronising sensors for stereoscopic operation.
> 
>   How should that be configured? Allowing configuration from userspace
>   would allow sensors to be operated independently which can be useful for
>   test purposes, or should it be enforced from DT/ACPI? Do we set a default
>   configuration for each sensor from DT/ACPI and then allow userspace to
>   override should it wish?
> 
> 14:00 Dave: Lens drivers.
> 
>   Each driver will have a "useful" range which is effectively dictated by
>   the overall module. Should that be defined via DT as it is a feature of
>   the platform, or leave the driver totally generic and expect userspace
>   to do something sensible?
> 
>   In the case of simple systems without libcamera, do we set default for
>   V4L2_CID_FOCUS_ABSOLUTE to a sensible hyperfocal distance, and can
>   that again be defined in DT as it is defining the hardware?
> 
> 14:15 Dave: Controlling sensor GPIO outputs.
> 
>   Controlling sensor GPIO outputs for things such as flash triggers,
>   vsync, frame start/end, exposure start/end, etc.
> 
>   There is a huge range of features available so do we have any hope of
>   standardising some of it, or do we end up hiding these away in the
>   drivers with custom DT bindings to configure them? If we accept that
>   there will be variation, can we vaguely standardise what those
>   bindings look like? Or should these be V4L2 controls as things like
>   pulse widths may want to be adjusted by userspace?
> 
> 14:30 Jacopo: Reconcile handling of regulator, gpios and clock on OF and ACPI platforms.
> 
>   We recently got a few series trying to reconcile handling of regulators,
>   gpios and clocks on OF and ACPI platforms all of them doing the usual
>   "similar but slightly different" thing:
> 
>   https://lore.kernel.org/linux-media/20220425061022.1569480-1-paul.elder@ideasonboard.com/
>   https://lore.kernel.org/linux-media/20220329090133.338073-1-jacopo@jmondi.org/
>   https://lore.kernel.org/linux-media/20220509143226.531117-1-foss+kernel@0leil.net/
>   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c2c7a1e0d69221b9d489bfd8cf53262d6f82446
> 
>   ACPI and OF handles clocks slightly differently, and it is not clear
>   to me if ACPI based platform need explicit handling of
>   clocks/regulator or ACPI does "the right thing" by itself (I'm
>   afraid the answer is actually "it depends"). I'm ACPI illiterate
>   so I cannot propose anything meaningful but if anyone is interested
>   in discussing this further this might be a good time to do so ?
> 
> 15:00 Break
> 
> 15:30 Laurent: V4L2 streams series.
> 
>   I'd like to discuss the V4L2 streams series, in particular how to
>   upstream the parts that won't be upstream yet by mid-September.
>   Discussing the next steps would also be useful, as there's lots we could
>   build on top.
> 
> 16:00 Laurent: How can we finalize conversion of v4l-utils to meson?

If everybody answers "yes" to this question in reply to this e-mail,
I'll send patches and we can free 15 minutes of discussion time :-)

> 16:15-17:00 Anything else?

Do we have t leave the room at 17:00 or would it still be available
should anyone want to continue discussions ?

-- 
Regards,

Laurent Pinchart

Re: [ANN] Media Summit at ELCE Dublin, September 12: Draft Agenda V1

[Hans Verkuil]

A quick clarification:

On 05/08/2022 13:35, Hans Verkuil wrote:
> If you present a topic, then please make a presentation. And if you have material you
> can share beforehand, then that would be great.

The idea is that you introduce the problem you want to discuss in your timeslot
with a few slides. Keep it as short as possible, and if it can be shared in the week
before, then that would be very helpful. 

Regards,

	Hans

Re: [ANN] Media Summit at ELCE Dublin, September 12: Draft Agenda V1

[Michael Tretter]

On Fri, 05 Aug 2022 13:35:48 +0200, Hans Verkuil wrote:
> Here is some more information about the Media Summit:
> 
> Date: Monday September 12
> Time: 9:00-17:00
> Location: Convention Centre Dublin
> Room: The Liffey B - Part 1 (subject to change)
> Sponsored by: Cisco Systems Norway and Collabora
> 
> We will have a projector or display to show presentations, power strips,
> a whiteboard and beverages. For lunch we are on our own.
> 
> It's co-located with the OSS Europe conference:
> 
> https://events.linuxfoundation.org/open-source-summit-europe/
> 
> Attendees:
> 
> Sakari Ailus <sakari.ailus@linux.intel.com>
> Kieran Bingham <kieran.bingham@ideasonboard.com>
> Nicolas Dufresne <nicolas@ndufresne.ca>
> Benjamin Gaignard <benjamin.gaignard@collabora.com>
> Hidenori Kobayashi <hidenorik@chromium.org>
> Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> Jacopo Mondi <jacopo@jmondi.org>
> Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Ricardo Ribalda <ribalda@chromium.org>
> Maxime Ripard <maxime@cerno.tech>
> Daniel Scally <djrscally@gmail.com>
> Jernej Škrabec <jernej.skrabec@gmail.com>
> Dave Stevenson <dave.stevenson@raspberrypi.com> (from 11 am onwards)
> Hans Verkuil <hverkuil@xs4all.nl>
> Philipp Zabel <p.zabel@pengutronix.de>
> 
> Note: there are 5 seats left, so if you are interested in this, mail me.

I would like to join as well: Michael Tretter <m.tretter@pengutronix.de>

Michael

Re: [ANN] Media Summit at ELCE Dublin, September 12: Draft Agenda V1

[Michael Olbrich]

Hi,

On Fri, Aug 05, 2022 at 01:35:48PM +0200, Hans Verkuil wrote:
> Here is some more information about the Media Summit:
> 
> Date: Monday September 12
> Time: 9:00-17:00
> Location: Convention Centre Dublin
> Room: The Liffey B - Part 1 (subject to change)
> Sponsored by: Cisco Systems Norway and Collabora
> 
> We will have a projector or display to show presentations, power strips,
> a whiteboard and beverages. For lunch we are on our own.
> 
> It's co-located with the OSS Europe conference:
> 
> https://events.linuxfoundation.org/open-source-summit-europe/
> 
> Attendees:
> 
> Sakari Ailus <sakari.ailus@linux.intel.com>
> Kieran Bingham <kieran.bingham@ideasonboard.com>
> Nicolas Dufresne <nicolas@ndufresne.ca>
> Benjamin Gaignard <benjamin.gaignard@collabora.com>
> Hidenori Kobayashi <hidenorik@chromium.org>
> Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> Jacopo Mondi <jacopo@jmondi.org>
> Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Ricardo Ribalda <ribalda@chromium.org>
> Maxime Ripard <maxime@cerno.tech>
> Daniel Scally <djrscally@gmail.com>
> Jernej Škrabec <jernej.skrabec@gmail.com>
> Dave Stevenson <dave.stevenson@raspberrypi.com> (from 11 am onwards)
> Hans Verkuil <hverkuil@xs4all.nl>
> Philipp Zabel <p.zabel@pengutronix.de>
> 
> Note: there are 5 seats left, so if you are interested in this, mail me.

I would like to come as well: Michael Olbrich <m.olbrich@pengutronix.de>

Regards,
Michael


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [ANN] Media Summit at ELCE Dublin, September 12: Draft Agenda V1

[Hans Verkuil]

On 8/9/22 11:38, Michael Tretter wrote:
> On Fri, 05 Aug 2022 13:35:48 +0200, Hans Verkuil wrote:
>> Here is some more information about the Media Summit:
>>
>> Date: Monday September 12
>> Time: 9:00-17:00
>> Location: Convention Centre Dublin
>> Room: The Liffey B - Part 1 (subject to change)
>> Sponsored by: Cisco Systems Norway and Collabora
>>
>> We will have a projector or display to show presentations, power strips,
>> a whiteboard and beverages. For lunch we are on our own.
>>
>> It's co-located with the OSS Europe conference:
>>
>> https://events.linuxfoundation.org/open-source-summit-europe/
>>
>> Attendees:
>>
>> Sakari Ailus <sakari.ailus@linux.intel.com>
>> Kieran Bingham <kieran.bingham@ideasonboard.com>
>> Nicolas Dufresne <nicolas@ndufresne.ca>
>> Benjamin Gaignard <benjamin.gaignard@collabora.com>
>> Hidenori Kobayashi <hidenorik@chromium.org>
>> Paul Kocialkowski <paul.kocialkowski@bootlin.com>
>> Jacopo Mondi <jacopo@jmondi.org>
>> Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> Ricardo Ribalda <ribalda@chromium.org>
>> Maxime Ripard <maxime@cerno.tech>
>> Daniel Scally <djrscally@gmail.com>
>> Jernej Škrabec <jernej.skrabec@gmail.com>
>> Dave Stevenson <dave.stevenson@raspberrypi.com> (from 11 am onwards)
>> Hans Verkuil <hverkuil@xs4all.nl>
>> Philipp Zabel <p.zabel@pengutronix.de>
>>
>> Note: there are 5 seats left, so if you are interested in this, mail me.
> 
> I would like to join as well: Michael Tretter <m.tretter@pengutronix.de>

You're in.

See you next month!

	Hans

> 
> Michael

Re: [ANN] Media Summit at ELCE Dublin, September 12: Draft Agenda V1

[Hans Verkuil]

On 8/9/22 12:18, Michael Olbrich wrote:
> Hi,
> 
> On Fri, Aug 05, 2022 at 01:35:48PM +0200, Hans Verkuil wrote:
>> Here is some more information about the Media Summit:
>>
>> Date: Monday September 12
>> Time: 9:00-17:00
>> Location: Convention Centre Dublin
>> Room: The Liffey B - Part 1 (subject to change)
>> Sponsored by: Cisco Systems Norway and Collabora
>>
>> We will have a projector or display to show presentations, power strips,
>> a whiteboard and beverages. For lunch we are on our own.
>>
>> It's co-located with the OSS Europe conference:
>>
>> https://events.linuxfoundation.org/open-source-summit-europe/
>>
>> Attendees:
>>
>> Sakari Ailus <sakari.ailus@linux.intel.com>
>> Kieran Bingham <kieran.bingham@ideasonboard.com>
>> Nicolas Dufresne <nicolas@ndufresne.ca>
>> Benjamin Gaignard <benjamin.gaignard@collabora.com>
>> Hidenori Kobayashi <hidenorik@chromium.org>
>> Paul Kocialkowski <paul.kocialkowski@bootlin.com>
>> Jacopo Mondi <jacopo@jmondi.org>
>> Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> Ricardo Ribalda <ribalda@chromium.org>
>> Maxime Ripard <maxime@cerno.tech>
>> Daniel Scally <djrscally@gmail.com>
>> Jernej Škrabec <jernej.skrabec@gmail.com>
>> Dave Stevenson <dave.stevenson@raspberrypi.com> (from 11 am onwards)
>> Hans Verkuil <hverkuil@xs4all.nl>
>> Philipp Zabel <p.zabel@pengutronix.de>
>>
>> Note: there are 5 seats left, so if you are interested in this, mail me.
> 
> I would like to come as well: Michael Olbrich <m.olbrich@pengutronix.de>

You're in.

See you next month!

	Hans

> 
> Regards,
> Michael
> 
> 

Re: [ANN] Media Summit at ELCE Dublin, September 12: Draft Agenda V1

[Hans Verkuil]

On 8/5/22 13:35, Hans Verkuil wrote:
> Hi all,
> 
> Here is some more information about the Media Summit:
> 
> Date: Monday September 12
> Time: 9:00-17:00
> Location: Convention Centre Dublin
> Room: The Liffey B - Part 1 (subject to change)
> Sponsored by: Cisco Systems Norway and Collabora
> 
> We will have a projector or display to show presentations, power strips,
> a whiteboard and beverages. For lunch we are on our own.
> 
> It's co-located with the OSS Europe conference:
> 
> https://events.linuxfoundation.org/open-source-summit-europe/
> 
> Attendees:
> 
> Sakari Ailus <sakari.ailus@linux.intel.com>
> Kieran Bingham <kieran.bingham@ideasonboard.com>
> Nicolas Dufresne <nicolas@ndufresne.ca>
> Benjamin Gaignard <benjamin.gaignard@collabora.com>
> Hidenori Kobayashi <hidenorik@chromium.org>
> Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> Jacopo Mondi <jacopo@jmondi.org>
> Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Ricardo Ribalda <ribalda@chromium.org>
> Maxime Ripard <maxime@cerno.tech>
> Daniel Scally <djrscally@gmail.com>
> Jernej Škrabec <jernej.skrabec@gmail.com>
> Dave Stevenson <dave.stevenson@raspberrypi.com> (from 11 am onwards)
> Hans Verkuil <hverkuil@xs4all.nl>
> Philipp Zabel <p.zabel@pengutronix.de>
> 
> Note: there are 5 seats left, so if you are interested in this, mail me.
> 
> The health and safety regulations will be those of the OSSE LF:
> 
> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/
> 
> We strongly recommend that you do a self-test before going to the Conference Centre
> for this meeting.
> 
> Code of conduct:
> 
> https://events.linuxfoundation.org/open-source-summit-europe/attend/code-of-conduct/
> 
> 
> Based on the submitted topics I have made a first draft of the agenda. I have tried
> to keep the sensor-related topics to after 11:00 since Dave comes in later in the day.
> 
> I am also making the (reasonable) assumption that most (if not all) attendees will be
> attending the ELCE/OSSE conference Tue-Fri as well. While it is nice if we can come
> to a conclusion in the time allotted for each topic, it's also OK if we can set up
> a small group that can discuss it further in the following days.
> 
> If you raised a discussion topic, but will be in Dublin for only the Monday, then
> let me know.
> 
> I added a guesstimate of the time needed for each topic. If you think that guesstimate
> is wildly off, then let me know. But remember: it's fine if we decide to discuss it
> further in the following days in a smaller group.
> 
> If you present a topic, then please make a presentation. And if you have material you
> can share beforehand, then that would be great.
> 
> Draft Agenda V1:
> 
>  9:00 Getting settled
>  9:20 Introduction
>  9:30 Hans: Presentation on CTA-861 & edid-decode
>  9:45 Nicolas: Stateless encoder progress
> 10:15 Ricardo: Introduce ChromeOS camera project
> 
> 11:00 Break
> 
> 11:15 Kieran: Fault tolerance
> 
>   I raised this in the past when we first started hitting the issue on
>   Renesas platforms with multiple cameras in a single media graph, but now
>   I think it's become more critical with desktop / laptop devices that are
>   hitting the issue (i.e. the IPU3).
> 
>   Summary of issue:
> 
>   - Multiple cameras that can function independently successfully, are
>     prevented from functioning or fully probing by V4L2 if one component
>     of another camera fails to load or probe.
> 
>     If Camera A has a VCM, and Camera B does not, Camera B will not be
>     available at all if Camera A's VCM is not fully probed, even though
>     Camera B can be fully functional and complete.
> 
>     Even if Camera A does not have the VCM probed, it may still function
>     successfully (with a fixed focal position) - but our current
>     implementation will mean that it will not even be available to
>     capture images.
> 
>   We talked about this quite a long time ago, and I believe the general
>   consensus was that we can have events on the media graph. But
>   unfortunately at the time, there was no development scheduled on that,
>   and it wasn't something I was able to continue at the time.
> 
>   I'd like to bring it up to refresh the topic, and see if we can make
>   some progress as it's now affecting more general devices.
> 
> 11:45 Jacopo: Representing addition sensor processing stages.
> 
>   How to represent additional processing stages that happens
>   on the sensor side, mostly additional subsampling/cropping that happen
>   between the analogue cropping on the full pixel array and the final
>   image sent on the wire.
> 
>   https://lore.kernel.org/linux-media/CAPY8ntA06L1Xsph79sv9t7MiDSNeSO2vADevuXZdXQdhWpSmow@mail.gmail.com/
> 
>   Dave made a good introduction of the issue his email which got
>   largely unanswered.
> 
>   The issue is particularly relevant for RAW sensors, where applying
>   subsampling has an impact on the sensor's sensitivity and requires
>   to adjust the gains and exposure accordingly.
> 
>   The V4L2 selection API falls short on this and the only other
>   solution I am aware of is registering additional subdevices as the
>   CCS driver does.
> 
> 12:30 Lunch
> 
> 13:30 Dave: On-sensor temperature reporting.
> 
>   Thread started by Benjamin at
>   https://lore.kernel.org/linux-media/20220415111845.27130-3-benjamin.mugnier@foss.st.com/
>   but no resolution over using hwmon API or V4L2 control. If hwmon
>   then we need Media Controller framework to tie the sensor and thermal
>   device together.
> 
>   It's recently been queried for IMX477 with the Pi
>   (https://github.com/raspberrypi/libcamera/issues/19), but it will
>   apply to many sensors.
> 
> 13:45 Dave: Synchronising sensors for stereoscopic operation.
> 
>   How should that be configured? Allowing configuration from userspace
>   would allow sensors to be operated independently which can be useful for
>   test purposes, or should it be enforced from DT/ACPI? Do we set a default
>   configuration for each sensor from DT/ACPI and then allow userspace to
>   override should it wish?
> 
> 14:00 Dave: Lens drivers.
> 
>   Each driver will have a "useful" range which is effectively dictated by
>   the overall module. Should that be defined via DT as it is a feature of
>   the platform, or leave the driver totally generic and expect userspace
>   to do something sensible?
> 
>   In the case of simple systems without libcamera, do we set default for
>   V4L2_CID_FOCUS_ABSOLUTE to a sensible hyperfocal distance, and can
>   that again be defined in DT as it is defining the hardware?
> 
> 14:15 Dave: Controlling sensor GPIO outputs.
> 
>   Controlling sensor GPIO outputs for things such as flash triggers,
>   vsync, frame start/end, exposure start/end, etc.
> 
>   There is a huge range of features available so do we have any hope of
>   standardising some of it, or do we end up hiding these away in the
>   drivers with custom DT bindings to configure them? If we accept that
>   there will be variation, can we vaguely standardise what those
>   bindings look like? Or should these be V4L2 controls as things like
>   pulse widths may want to be adjusted by userspace?
> 
> 14:30 Jacopo: Reconcile handling of regulator, gpios and clock on OF and ACPI platforms.
> 
>   We recently got a few series trying to reconcile handling of regulators,
>   gpios and clocks on OF and ACPI platforms all of them doing the usual
>   "similar but slightly different" thing:
> 
>   https://lore.kernel.org/linux-media/20220425061022.1569480-1-paul.elder@ideasonboard.com/
>   https://lore.kernel.org/linux-media/20220329090133.338073-1-jacopo@jmondi.org/
>   https://lore.kernel.org/linux-media/20220509143226.531117-1-foss+kernel@0leil.net/
>   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c2c7a1e0d69221b9d489bfd8cf53262d6f82446
> 
>   ACPI and OF handles clocks slightly differently, and it is not clear
>   to me if ACPI based platform need explicit handling of
>   clocks/regulator or ACPI does "the right thing" by itself (I'm
>   afraid the answer is actually "it depends"). I'm ACPI illiterate
>   so I cannot propose anything meaningful but if anyone is interested
>   in discussing this further this might be a good time to do so ?
> 
> 15:00 Break
> 
> 15:30 Laurent: V4L2 streams series.
> 
>   I'd like to discuss the V4L2 streams series, in particular how to
>   upstream the parts that won't be upstream yet by mid-September.
>   Discussing the next steps would also be useful, as there's lots we could
>   build on top.
> 
> 16:00 Laurent: How can we finalize conversion of v4l-utils to meson?
> 
> 16:15-17:00 Anything else?

One more topic: "Deprecate (and later remove) the last few videobuf version 1 drivers"

Possibly also include drivers that do not use neither videobuf nor vb2, I'll have
to check how many of those we have.

Regards,

	Hans

> 
> Regards,
> 
> 	Hans

Re: [ANN] Media Summit at ELCE Dublin, September 12: Draft Agenda V1

[Laurent Pinchart]

Hi Hans,

On Tue, Aug 09, 2022 at 03:01:01PM +0200, Hans Verkuil wrote:
> On 8/5/22 13:35, Hans Verkuil wrote:
> > Hi all,
> > 
> > Here is some more information about the Media Summit:
> > 
> > Date: Monday September 12
> > Time: 9:00-17:00
> > Location: Convention Centre Dublin
> > Room: The Liffey B - Part 1 (subject to change)
> > Sponsored by: Cisco Systems Norway and Collabora
> > 
> > We will have a projector or display to show presentations, power strips,
> > a whiteboard and beverages. For lunch we are on our own.
> > 
> > It's co-located with the OSS Europe conference:
> > 
> > https://events.linuxfoundation.org/open-source-summit-europe/
> > 
> > Attendees:
> > 
> > Sakari Ailus <sakari.ailus@linux.intel.com>
> > Kieran Bingham <kieran.bingham@ideasonboard.com>
> > Nicolas Dufresne <nicolas@ndufresne.ca>
> > Benjamin Gaignard <benjamin.gaignard@collabora.com>
> > Hidenori Kobayashi <hidenorik@chromium.org>
> > Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > Jacopo Mondi <jacopo@jmondi.org>
> > Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Ricardo Ribalda <ribalda@chromium.org>
> > Maxime Ripard <maxime@cerno.tech>
> > Daniel Scally <djrscally@gmail.com>
> > Jernej Škrabec <jernej.skrabec@gmail.com>
> > Dave Stevenson <dave.stevenson@raspberrypi.com> (from 11 am onwards)
> > Hans Verkuil <hverkuil@xs4all.nl>
> > Philipp Zabel <p.zabel@pengutronix.de>
> > 
> > Note: there are 5 seats left, so if you are interested in this, mail me.
> > 
> > The health and safety regulations will be those of the OSSE LF:
> > 
> > https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/
> > 
> > We strongly recommend that you do a self-test before going to the Conference Centre
> > for this meeting.
> > 
> > Code of conduct:
> > 
> > https://events.linuxfoundation.org/open-source-summit-europe/attend/code-of-conduct/
> > 
> > 
> > Based on the submitted topics I have made a first draft of the agenda. I have tried
> > to keep the sensor-related topics to after 11:00 since Dave comes in later in the day.
> > 
> > I am also making the (reasonable) assumption that most (if not all) attendees will be
> > attending the ELCE/OSSE conference Tue-Fri as well. While it is nice if we can come
> > to a conclusion in the time allotted for each topic, it's also OK if we can set up
> > a small group that can discuss it further in the following days.
> > 
> > If you raised a discussion topic, but will be in Dublin for only the Monday, then
> > let me know.
> > 
> > I added a guesstimate of the time needed for each topic. If you think that guesstimate
> > is wildly off, then let me know. But remember: it's fine if we decide to discuss it
> > further in the following days in a smaller group.
> > 
> > If you present a topic, then please make a presentation. And if you have material you
> > can share beforehand, then that would be great.
> > 
> > Draft Agenda V1:
> > 
> >  9:00 Getting settled
> >  9:20 Introduction
> >  9:30 Hans: Presentation on CTA-861 & edid-decode
> >  9:45 Nicolas: Stateless encoder progress
> > 10:15 Ricardo: Introduce ChromeOS camera project
> > 
> > 11:00 Break
> > 
> > 11:15 Kieran: Fault tolerance
> > 
> >   I raised this in the past when we first started hitting the issue on
> >   Renesas platforms with multiple cameras in a single media graph, but now
> >   I think it's become more critical with desktop / laptop devices that are
> >   hitting the issue (i.e. the IPU3).
> > 
> >   Summary of issue:
> > 
> >   - Multiple cameras that can function independently successfully, are
> >     prevented from functioning or fully probing by V4L2 if one component
> >     of another camera fails to load or probe.
> > 
> >     If Camera A has a VCM, and Camera B does not, Camera B will not be
> >     available at all if Camera A's VCM is not fully probed, even though
> >     Camera B can be fully functional and complete.
> > 
> >     Even if Camera A does not have the VCM probed, it may still function
> >     successfully (with a fixed focal position) - but our current
> >     implementation will mean that it will not even be available to
> >     capture images.
> > 
> >   We talked about this quite a long time ago, and I believe the general
> >   consensus was that we can have events on the media graph. But
> >   unfortunately at the time, there was no development scheduled on that,
> >   and it wasn't something I was able to continue at the time.
> > 
> >   I'd like to bring it up to refresh the topic, and see if we can make
> >   some progress as it's now affecting more general devices.
> > 
> > 11:45 Jacopo: Representing addition sensor processing stages.
> > 
> >   How to represent additional processing stages that happens
> >   on the sensor side, mostly additional subsampling/cropping that happen
> >   between the analogue cropping on the full pixel array and the final
> >   image sent on the wire.
> > 
> >   https://lore.kernel.org/linux-media/CAPY8ntA06L1Xsph79sv9t7MiDSNeSO2vADevuXZdXQdhWpSmow@mail.gmail.com/
> > 
> >   Dave made a good introduction of the issue his email which got
> >   largely unanswered.
> > 
> >   The issue is particularly relevant for RAW sensors, where applying
> >   subsampling has an impact on the sensor's sensitivity and requires
> >   to adjust the gains and exposure accordingly.
> > 
> >   The V4L2 selection API falls short on this and the only other
> >   solution I am aware of is registering additional subdevices as the
> >   CCS driver does.
> > 
> > 12:30 Lunch
> > 
> > 13:30 Dave: On-sensor temperature reporting.
> > 
> >   Thread started by Benjamin at
> >   https://lore.kernel.org/linux-media/20220415111845.27130-3-benjamin.mugnier@foss.st.com/
> >   but no resolution over using hwmon API or V4L2 control. If hwmon
> >   then we need Media Controller framework to tie the sensor and thermal
> >   device together.
> > 
> >   It's recently been queried for IMX477 with the Pi
> >   (https://github.com/raspberrypi/libcamera/issues/19), but it will
> >   apply to many sensors.
> > 
> > 13:45 Dave: Synchronising sensors for stereoscopic operation.
> > 
> >   How should that be configured? Allowing configuration from userspace
> >   would allow sensors to be operated independently which can be useful for
> >   test purposes, or should it be enforced from DT/ACPI? Do we set a default
> >   configuration for each sensor from DT/ACPI and then allow userspace to
> >   override should it wish?
> > 
> > 14:00 Dave: Lens drivers.
> > 
> >   Each driver will have a "useful" range which is effectively dictated by
> >   the overall module. Should that be defined via DT as it is a feature of
> >   the platform, or leave the driver totally generic and expect userspace
> >   to do something sensible?
> > 
> >   In the case of simple systems without libcamera, do we set default for
> >   V4L2_CID_FOCUS_ABSOLUTE to a sensible hyperfocal distance, and can
> >   that again be defined in DT as it is defining the hardware?
> > 
> > 14:15 Dave: Controlling sensor GPIO outputs.
> > 
> >   Controlling sensor GPIO outputs for things such as flash triggers,
> >   vsync, frame start/end, exposure start/end, etc.
> > 
> >   There is a huge range of features available so do we have any hope of
> >   standardising some of it, or do we end up hiding these away in the
> >   drivers with custom DT bindings to configure them? If we accept that
> >   there will be variation, can we vaguely standardise what those
> >   bindings look like? Or should these be V4L2 controls as things like
> >   pulse widths may want to be adjusted by userspace?
> > 
> > 14:30 Jacopo: Reconcile handling of regulator, gpios and clock on OF and ACPI platforms.
> > 
> >   We recently got a few series trying to reconcile handling of regulators,
> >   gpios and clocks on OF and ACPI platforms all of them doing the usual
> >   "similar but slightly different" thing:
> > 
> >   https://lore.kernel.org/linux-media/20220425061022.1569480-1-paul.elder@ideasonboard.com/
> >   https://lore.kernel.org/linux-media/20220329090133.338073-1-jacopo@jmondi.org/
> >   https://lore.kernel.org/linux-media/20220509143226.531117-1-foss+kernel@0leil.net/
> >   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c2c7a1e0d69221b9d489bfd8cf53262d6f82446
> > 
> >   ACPI and OF handles clocks slightly differently, and it is not clear
> >   to me if ACPI based platform need explicit handling of
> >   clocks/regulator or ACPI does "the right thing" by itself (I'm
> >   afraid the answer is actually "it depends"). I'm ACPI illiterate
> >   so I cannot propose anything meaningful but if anyone is interested
> >   in discussing this further this might be a good time to do so ?
> > 
> > 15:00 Break
> > 
> > 15:30 Laurent: V4L2 streams series.
> > 
> >   I'd like to discuss the V4L2 streams series, in particular how to
> >   upstream the parts that won't be upstream yet by mid-September.
> >   Discussing the next steps would also be useful, as there's lots we could
> >   build on top.
> > 
> > 16:00 Laurent: How can we finalize conversion of v4l-utils to meson?
> > 
> > 16:15-17:00 Anything else?
> 
> One more topic: "Deprecate (and later remove) the last few videobuf version 1 drivers"
> 
> Possibly also include drivers that do not use neither videobuf nor vb2, I'll have
> to check how many of those we have.

Maybe we can reach an agreement through e-mail discussions on this one ?
Let's at least try.

Do you have a list of the vb1 drivers ?

-- 
Regards,

Laurent Pinchart

Proposal: removal of old vb1 or custom streaming I/O drivers

[Hans Verkuil]

We have the following drivers still using vb1:

PCI: saa7146, bt8xx, cx18
USB: zr364xx, tm6000
platform: ti/davinci/vpfe_capture, nxp/fsl-viu
staging: atomisp

And these drivers rolls their own streaming I/O implementation:

pci: meye
usb: cpia2
staging: stkwebcam (deprecated, to be removed by the end of the year)

I think we should bite the bullet and move all of these drivers to staging,
mark them deprecated and delete them some time next year if nobody will
convert them to vb2.

That includes atomisp: is that going anywhere? Unless someone does the
hard work of converting it to vb2 I think it should be removed as well.

The two drivers most likely to still be in use somewhere are bt8xx and
cx18. If it turns out that we can't remove them (yet), then I can probably
justify the time to convert cx18 to vb2 myself.

And for bt8xx I would probably be willing to convert it to vb2 as well,
provided we can strip the overlay support from the driver (since, if memory
serves, vb2 doesn't support that) and convert it to vb2. It's a big job, though.

One other thing we can do is to deprecate/remove video capture overlay support
(in the sense of video capture hardware writing directly to a framebuffer).

It's supported by saa7146, bttv, saa7134 and fsl-viu. If we remove vb1
drivers, then that would leave only saa7134 that still supports it.

Removing the API will simplify things.

Regards,

	Hans

Re: Proposal: removal of old vb1 or custom streaming I/O drivers

[Mauro Carvalho Chehab]

Em Wed, 10 Aug 2022 10:18:56 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> We have the following drivers still using vb1:
> 
> PCI: saa7146, bt8xx, cx18
> USB: zr364xx, tm6000
> platform: ti/davinci/vpfe_capture, nxp/fsl-viu
> staging: atomisp
> 
> And these drivers rolls their own streaming I/O implementation:
> 
> pci: meye
> usb: cpia2
> staging: stkwebcam (deprecated, to be removed by the end of the year)
> 
> I think we should bite the bullet and move all of these drivers to staging,
> mark them deprecated and delete them some time next year if nobody will
> convert them to vb2.
> 
> That includes atomisp: is that going anywhere? Unless someone does the
> hard work of converting it to vb2 I think it should be removed as well.

There have been improvements at atomisp driver. Hans de Goede has been
doing some work. As far as I understand, he's planning to get VB2 and
libcamera support for it. I'm also working on it when I have some spare
time available.

> The two drivers most likely to still be in use somewhere are bt8xx and
> cx18. If it turns out that we can't remove them (yet), then I can probably
> justify the time to convert cx18 to vb2 myself.

Yeah, bt8xx is probably still widely used, specially on analog camera
multi-port capture scenarios. Not sure about cx18 usage those days.

IMO, once we get bt8xx, atomisp (and maybe cx18) converted to VB2, it
should be OK to remove the other drivers. 

For now, we can move them to staging, adding a TODO explaining that they
should be ported to VB2 or they'll be removed.

Scheduling removal to the end of the year is probably not doable, as
the patch moving them to staging would be merged only around Oct.
We should grant at least two Kernel cycles for people to convert the
drivers - assuming that someone would do that for some driver(s).

> And for bt8xx I would probably be willing to convert it to vb2 as well,
> provided we can strip the overlay support from the driver (since, if memory
> serves, vb2 doesn't support that) and convert it to vb2. It's a big job, though.

It sounds OK on my eyes to remove overlay support from bt8xx during VB2
conversion. We should probably add a warning about such removal before
that (see below).

> One other thing we can do is to deprecate/remove video capture overlay support
> (in the sense of video capture hardware writing directly to a framebuffer).
> 
> It's supported by saa7146, bttv, saa7134 and fsl-viu. If we remove vb1
> drivers, then that would leave only saa7134 that still supports it.
> 
> Removing the API will simplify things.

It probably makes sense to add an error-level printks, printed only once,
when someone uses VIDIOC_OVERLAY ioctl, warning that this is a deprecated
feature that will be removed soon, for the drivers that still supports it.

For sure once we get rid of the VB1 drivers that use overlay, it makes
sense to also remove its support for saa7134. Maybe even before ;-)

Thanks,
Mauro

Re: Proposal: removal of old vb1 or custom streaming I/O drivers

[Laurent Pinchart]

Hello,

On Wed, Aug 10, 2022 at 12:24:16PM +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 10 Aug 2022 10:18:56 +0200 Hans Verkuil escreveu:
> 
> > We have the following drivers still using vb1:
> > 
> > PCI: saa7146, bt8xx, cx18
> > USB: zr364xx, tm6000
> > platform: ti/davinci/vpfe_capture, nxp/fsl-viu
> > staging: atomisp
> > 
> > And these drivers rolls their own streaming I/O implementation:
> > 
> > pci: meye
> > usb: cpia2
> > staging: stkwebcam (deprecated, to be removed by the end of the year)
> > 
> > I think we should bite the bullet and move all of these drivers to staging,
> > mark them deprecated and delete them some time next year if nobody will
> > convert them to vb2.
> > 
> > That includes atomisp: is that going anywhere? Unless someone does the
> > hard work of converting it to vb2 I think it should be removed as well.
> 
> There have been improvements at atomisp driver. Hans de Goede has been
> doing some work. As far as I understand, he's planning to get VB2 and
> libcamera support for it. I'm also working on it when I have some spare
> time available.

That looks like a project that will take a few lifetimes, but as long as
I don't have to work on it myself, that's fine with me :-)

I don't think it's a blocker anyway, if we move vb1 drivers to staging,
and hopefully the vb1 core too, then atomisp2 will just be with all its
vb1 cousins.

> > The two drivers most likely to still be in use somewhere are bt8xx and
> > cx18. If it turns out that we can't remove them (yet), then I can probably
> > justify the time to convert cx18 to vb2 myself.
> 
> Yeah, bt8xx is probably still widely used, specially on analog camera
> multi-port capture scenarios. Not sure about cx18 usage those days.
> 
> IMO, once we get bt8xx, atomisp (and maybe cx18) converted to VB2, it
> should be OK to remove the other drivers. 
> 
> For now, we can move them to staging, adding a TODO explaining that they
> should be ported to VB2 or they'll be removed.

Sounds good to me, staging is the right way out.

> Scheduling removal to the end of the year is probably not doable, as
> the patch moving them to staging would be merged only around Oct.
> We should grant at least two Kernel cycles for people to convert the
> drivers - assuming that someone would do that for some driver(s).
> 
> > And for bt8xx I would probably be willing to convert it to vb2 as well,
> > provided we can strip the overlay support from the driver (since, if memory
> > serves, vb2 doesn't support that) and convert it to vb2. It's a big job, though.
> 
> It sounds OK on my eyes to remove overlay support from bt8xx during VB2
> conversion. We should probably add a warning about such removal before
> that (see below).
> 
> > One other thing we can do is to deprecate/remove video capture overlay support
> > (in the sense of video capture hardware writing directly to a framebuffer).
> > 
> > It's supported by saa7146, bttv, saa7134 and fsl-viu. If we remove vb1
> > drivers, then that would leave only saa7134 that still supports it.
> > 
> > Removing the API will simplify things.
> 
> It probably makes sense to add an error-level printks, printed only once,
> when someone uses VIDIOC_OVERLAY ioctl, warning that this is a deprecated
> feature that will be removed soon, for the drivers that still supports it.
> 
> For sure once we get rid of the VB1 drivers that use overlay, it makes
> sense to also remove its support for saa7134. Maybe even before ;-)

\o/ I'd be happy to see the V4L2 code base shrink for once.

-- 
Regards,

Laurent Pinchart

Re: Proposal: removal of old vb1 or custom streaming I/O drivers

[Hans de Goede]

Hi,

On 8/10/22 12:24, Mauro Carvalho Chehab wrote:
> Em Wed, 10 Aug 2022 10:18:56 +0200
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> 
>> We have the following drivers still using vb1:
>>
>> PCI: saa7146, bt8xx, cx18
>> USB: zr364xx, tm6000
>> platform: ti/davinci/vpfe_capture, nxp/fsl-viu
>> staging: atomisp
>>
>> And these drivers rolls their own streaming I/O implementation:
>>
>> pci: meye
>> usb: cpia2
>> staging: stkwebcam (deprecated, to be removed by the end of the year)
>>
>> I think we should bite the bullet and move all of these drivers to staging,
>> mark them deprecated and delete them some time next year if nobody will
>> convert them to vb2.
>>
>> That includes atomisp: is that going anywhere? Unless someone does the
>> hard work of converting it to vb2 I think it should be removed as well.
> 
> There have been improvements at atomisp driver. Hans de Goede has been
> doing some work. As far as I understand, he's planning to get VB2 and
> libcamera support for it. I'm also working on it when I have some spare
> time available.

Correct I'm planning to convert the atomisp code to vb2. I hope to resume
work on this again soon-ish.

>> The two drivers most likely to still be in use somewhere are bt8xx and
>> cx18. If it turns out that we can't remove them (yet), then I can probably
>> justify the time to convert cx18 to vb2 myself.
> 
> Yeah, bt8xx is probably still widely used, specially on analog camera
> multi-port capture scenarios. Not sure about cx18 usage those days.
> 
> IMO, once we get bt8xx, atomisp (and maybe cx18) converted to VB2, it
> should be OK to remove the other drivers. 
> 
> For now, we can move them to staging, adding a TODO explaining that they
> should be ported to VB2 or they'll be removed.
> 
> Scheduling removal to the end of the year is probably not doable, as
> the patch moving them to staging would be merged only around Oct.
> We should grant at least two Kernel cycles for people to convert the
> drivers - assuming that someone would do that for some driver(s).
> 
>> And for bt8xx I would probably be willing to convert it to vb2 as well,
>> provided we can strip the overlay support from the driver (since, if memory
>> serves, vb2 doesn't support that) and convert it to vb2. It's a big job, though.
> 
> It sounds OK on my eyes to remove overlay support from bt8xx during VB2
> conversion. We should probably add a warning about such removal before
> that (see below).

About bt8xx support. At least in the Netherlands the cable companies have
stopped sending analog TV over the cable (only DVB now) so I've remove
my bt8xx tv-card from my machine after many years of using it.

I believe something similar is happening in most of the rest of Europe
at least.

Regards,

Hans

Re: Proposal: removal of old vb1 or custom streaming I/O drivers

[Mauro Carvalho Chehab]

Em Wed, 10 Aug 2022 16:27:03 +0200
Hans de Goede <hdegoede@redhat.com> escreveu:

> >> And for bt8xx I would probably be willing to convert it to vb2 as well,
> >> provided we can strip the overlay support from the driver (since, if memory
> >> serves, vb2 doesn't support that) and convert it to vb2. It's a big job, though.  
> > 
> > It sounds OK on my eyes to remove overlay support from bt8xx during VB2
> > conversion. We should probably add a warning about such removal before
> > that (see below).  
> 
> About bt8xx support. At least in the Netherlands the cable companies have
> stopped sending analog TV over the cable (only DVB now) so I've remove
> my bt8xx tv-card from my machine after many years of using it.
> 
> I believe something similar is happening in most of the rest of Europe
> at least.

This has nothing to do with analog TV. There are several bt8xx, saa713x
and cx18 products focused on video surveillance systems. Basically,
analog cameras connected to the capture boards using coaxial cables,
like those:

	https://www.camsecure.co.uk/Camsecure_video_capture_cards.html

Yeah, those are also being deprecated with time with IP-based cameras,
but still there are a lot of such products using analog ones out there.

Funny enough, even analog TV seems to still be used on some places. We
recently merged some patches addressing some issues with PAL/N' on
some drivers.

Thanks,
Mauro

Re: [ANN] Media Summit at ELCE Dublin, September 12: Draft Agenda V1

[Niklas Söderlund]

Hi Hans, all,

On 2022-08-05 13:35:48 +0200, Hans Verkuil wrote:
> 15:30 Laurent: V4L2 streams series.
> 
>   I'd like to discuss the V4L2 streams series, in particular how to
>   upstream the parts that won't be upstream yet by mid-September.
>   Discussing the next steps would also be useful, as there's lots we could
>   build on top.

I have no ticket for OSS Europe but will be in town for LPC and I would 
like to attend the media summit afternoon seasons, this one in 
particular. Would that be possible?

-- 
Kind Regards,
Niklas Söderlund

Re: [ANN] Media Summit at ELCE Dublin, September 12: Draft Agenda V1

[Hans Verkuil]

On 18/08/2022 03:33, Niklas Söderlund wrote:
> Hi Hans, all,
> 
> On 2022-08-05 13:35:48 +0200, Hans Verkuil wrote:
>> 15:30 Laurent: V4L2 streams series.
>>
>>   I'd like to discuss the V4L2 streams series, in particular how to
>>   upstream the parts that won't be upstream yet by mid-September.
>>   Discussing the next steps would also be useful, as there's lots we could
>>   build on top.
> 
> I have no ticket for OSS Europe but will be in town for LPC and I would 
> like to attend the media summit afternoon seasons, this one in 
> particular. Would that be possible?
> 

Yes, that's possible. No registration is required for this, I just need to
know who'll be there.

I've added you to the attendees list.

Regards,

	Hans

Re: [ANN] Media Summit at ELCE Dublin, September 12: Draft Agenda V1

[Benjamin MUGNIER]

>> 13:30 Dave: On-sensor temperature reporting.
>>
>>    Thread started by Benjamin at
>>    https://lore.kernel.org/linux-media/20220415111845.27130-3-benjamin.mugnier@foss.st.com/
>>    but no resolution over using hwmon API or V4L2 control. If hwmon
>>    then we need Media Controller framework to tie the sensor and thermal
>>    device together.
>>
>>    It's recently been queried for IMX477 with the Pi
>>    (https://github.com/raspberrypi/libcamera/issues/19), but it will
>>    apply to many sensors.
> 
> Dave, it would be very useful if you could summarize, based on your
> experience, how that information is reported by sensors (I2C reads,
> embedded data, ..., but also single value, multiple values, ...) and
> what use cases are expected to consume it.

I will only attend in remote so I won't be able to talk with you about 
this topic.

But indeed I'm really interested in the outcome.