[ANN] Media Summit at ELCE Dublin, September 12: Final (?) Agenda V3

[ANN] Media Summit at ELCE Dublin, September 12: Final (?) Agenda V3

[Hans Verkuil]

Hi all,

Here is some more information about the Media Summit:

Date: Monday September 12
Time: 8:45-18:00
Location: Convention Centre Dublin
Room: The Liffey B - Part 1
Sponsored by: Cisco Systems Norway, Collabora and the Kodi Foundation

We will have a projector or display to show presentations, power strips,
a whiteboard and beverages. Lunch is sponsored by the Kodi Foundation.

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>
Hugues FRUCHET <hugues.fruchet@st.com>
Benjamin Gaignard <benjamin.gaignard@collabora.com>
Jacopo Mondi <jacopo@jmondi.org>
Michael Olbrich <m.olbrich@pengutronix.de>
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>
Niklas Söderlund <niklas.soderlund@ragnatech.se> (afternoon only)
Dave Stevenson <dave.stevenson@raspberrypi.com> (from 11 am approx.)
Michael Tretter <m.tretter@pengutronix.de>
Hans Verkuil <hverkuil@xs4all.nl>
Philipp Zabel <p.zabel@pengutronix.de>

Remote attendees:

Mauro Carvalho Chehab <mchehab@kernel.org>
Benjamin MUGNIER <benjamin.mugnier@foss.st.com>

Regarding remote attendance: I will a second laptop with me and a good webcam.
But whether this will work is not at all certain, esp. audio is often very poor. It very
much depends on the room. I mailed Mauro and Benjamin instructions on how to join.
We'll see if it works or not.

We'll be using etherpad to keep notes. I created one here:

https://pad.systemli.org/p/media-summit-2022


The health and safety regulations will be those of the OSSE LF (updated on August 22):

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

As you can read above masks are needed for this event, so make sure you bring them!
You also need to be fully vaccinated (Duh!), or show a negative test. See the details
in the link.

We also 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/


Agenda:

Below is the final (?) version of the agenda. I have tried to keep the sensor-related
topics to after 11:00 since Dave comes in later in the day.

Changes since V2:
- Updated attendees list.
- Dropped my presentation since I'll be presenting the same thing at the ELCE on Friday
  9:50.
- Added keysigning party at the end of the day.
- Added links to slides.

I am also making the (reasonable) assumption that most 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.

I added a guesstimate of the time needed for each topic. Please note that it is
fine if we decide to discuss it further in the following days in a smaller group,
or continue discussions on the mailing list.

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

We have the room from 8:30-18:00, so I moved a few things around since V1, in particular
please come in a bit earlier so you can set everything up (power, internet, etc.) so
we can begin at 9 AM sharp.

Don't expect that the times below are precise (esp. after 11:00): past experience tells
us that it can vary wildly.

Links to slides:

Ricardo: https://drive.google.com/file/d/1Tew21xeKmFlQ7dQxMcIYqybVuQL7La1a/view
Dave: https://drive.google.com/file/d/1vjYJjTNRL1P3j6G4Nx2ZpjFtTBTNdeFG/view?usp=sharing
Jacopo: https://nc.nibble.pw/s/oib8jzNjjtgB9c6

Agenda V3:

 8:40 Getting settled
 9:00 Introduction
 9:10 Nicolas: Stateless encoder progress
 9:45 Ricardo: Introduce ChromeOS camera project: slides posted!

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:50 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:10 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:30 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?

15:00 Break

15: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 ?


16:00 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:30 Laurent: How can we finalize conversion of v4l-utils to meson?

16:45 Key signing party

      See: https://lore.kernel.org/linux-media/YxhplLKtRAQzlSK%2F@pendragon.ideasonboard.com/

      I'm really not sure where the 'party' aspect comes in, since while necessary,
      it is all terribly boring :-)

17:15-18:00 Anything else?

Regards,

	Hans

[ANN] Media Summit: room change!

[Hans Verkuil]

We are now in Liffey Meeting Room 4!

Regards,

	Hans

On 9/8/22 10:58, Hans Verkuil wrote:
> Hi all,
> 
> Here is some more information about the Media Summit:
> 
> Date: Monday September 12
> Time: 8:45-18:00
> Location: Convention Centre Dublin
> Room: The Liffey B - Part 1
> Sponsored by: Cisco Systems Norway, Collabora and the Kodi Foundation
> 
> We will have a projector or display to show presentations, power strips,
> a whiteboard and beverages. Lunch is sponsored by the Kodi Foundation.
> 
> 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>
> Hugues FRUCHET <hugues.fruchet@st.com>
> Benjamin Gaignard <benjamin.gaignard@collabora.com>
> Jacopo Mondi <jacopo@jmondi.org>
> Michael Olbrich <m.olbrich@pengutronix.de>
> 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>
> Niklas Söderlund <niklas.soderlund@ragnatech.se> (afternoon only)
> Dave Stevenson <dave.stevenson@raspberrypi.com> (from 11 am approx.)
> Michael Tretter <m.tretter@pengutronix.de>
> Hans Verkuil <hverkuil@xs4all.nl>
> Philipp Zabel <p.zabel@pengutronix.de>
> 
> Remote attendees:
> 
> Mauro Carvalho Chehab <mchehab@kernel.org>
> Benjamin MUGNIER <benjamin.mugnier@foss.st.com>
> 
> Regarding remote attendance: I will a second laptop with me and a good webcam.
> But whether this will work is not at all certain, esp. audio is often very poor. It very
> much depends on the room. I mailed Mauro and Benjamin instructions on how to join.
> We'll see if it works or not.
> 
> We'll be using etherpad to keep notes. I created one here:
> 
> https://pad.systemli.org/p/media-summit-2022
> 
> 
> The health and safety regulations will be those of the OSSE LF (updated on August 22):
> 
> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/
> 
> As you can read above masks are needed for this event, so make sure you bring them!
> You also need to be fully vaccinated (Duh!), or show a negative test. See the details
> in the link.
> 
> We also 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/
> 
> 
> Agenda:
> 
> Below is the final (?) version of the agenda. I have tried to keep the sensor-related
> topics to after 11:00 since Dave comes in later in the day.
> 
> Changes since V2:
> - Updated attendees list.
> - Dropped my presentation since I'll be presenting the same thing at the ELCE on Friday
>    9:50.
> - Added keysigning party at the end of the day.
> - Added links to slides.
> 
> I am also making the (reasonable) assumption that most 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.
> 
> I added a guesstimate of the time needed for each topic. Please note that it is
> fine if we decide to discuss it further in the following days in a smaller group,
> or continue discussions on the mailing list.
> 
> If you present a topic, then please make a presentation. And if you have material you
> can share beforehand, then that would be great.
> 
> We have the room from 8:30-18:00, so I moved a few things around since V1, in particular
> please come in a bit earlier so you can set everything up (power, internet, etc.) so
> we can begin at 9 AM sharp.
> 
> Don't expect that the times below are precise (esp. after 11:00): past experience tells
> us that it can vary wildly.
> 
> Links to slides:
> 
> Ricardo: https://drive.google.com/file/d/1Tew21xeKmFlQ7dQxMcIYqybVuQL7La1a/view
> Dave: https://drive.google.com/file/d/1vjYJjTNRL1P3j6G4Nx2ZpjFtTBTNdeFG/view?usp=sharing
> Jacopo: https://nc.nibble.pw/s/oib8jzNjjtgB9c6
> 
> Agenda V3:
> 
>   8:40 Getting settled
>   9:00 Introduction
>   9:10 Nicolas: Stateless encoder progress
>   9:45 Ricardo: Introduce ChromeOS camera project: slides posted!
> 
> 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:50 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:10 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:30 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?
> 
> 15:00 Break
> 
> 15: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 ?
> 
> 
> 16:00 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:30 Laurent: How can we finalize conversion of v4l-utils to meson?
> 
> 16:45 Key signing party
> 
>        See: https://lore.kernel.org/linux-media/YxhplLKtRAQzlSK%2F@pendragon.ideasonboard.com/
> 
>        I'm really not sure where the 'party' aspect comes in, since while necessary,
>        it is all terribly boring :-)
> 
> 17:15-18:00 Anything else?
> 
> Regards,
> 
> 	Hans

Re: [ANN] Media Summit at ELCE Dublin, September 12: Final (?) Agenda V3

[Kieran Bingham]

Quoting Hans Verkuil (2022-09-08 09:58:21)
> Hi all,

We've got a table here for dinner tonight. 

https://maps.app.goo.gl/2jU58EYhHJoZJHVa9

the port house pintxo

--

kieran


> 
> Here is some more information about the Media Summit:
> 
> Date: Monday September 12
> Time: 8:45-18:00
> Location: Convention Centre Dublin
> Room: The Liffey B - Part 1
> Sponsored by: Cisco Systems Norway, Collabora and the Kodi Foundation
> 
> We will have a projector or display to show presentations, power strips,
> a whiteboard and beverages. Lunch is sponsored by the Kodi Foundation.
> 
> 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>
> Hugues FRUCHET <hugues.fruchet@st.com>
> Benjamin Gaignard <benjamin.gaignard@collabora.com>
> Jacopo Mondi <jacopo@jmondi.org>
> Michael Olbrich <m.olbrich@pengutronix.de>
> 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>
> Niklas Söderlund <niklas.soderlund@ragnatech.se> (afternoon only)
> Dave Stevenson <dave.stevenson@raspberrypi.com> (from 11 am approx.)
> Michael Tretter <m.tretter@pengutronix.de>
> Hans Verkuil <hverkuil@xs4all.nl>
> Philipp Zabel <p.zabel@pengutronix.de>
> 
> Remote attendees:
> 
> Mauro Carvalho Chehab <mchehab@kernel.org>
> Benjamin MUGNIER <benjamin.mugnier@foss.st.com>
> 
> Regarding remote attendance: I will a second laptop with me and a good webcam.
> But whether this will work is not at all certain, esp. audio is often very poor. It very
> much depends on the room. I mailed Mauro and Benjamin instructions on how to join.
> We'll see if it works or not.
> 
> We'll be using etherpad to keep notes. I created one here:
> 
> https://pad.systemli.org/p/media-summit-2022
> 
> 
> The health and safety regulations will be those of the OSSE LF (updated on August 22):
> 
> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/
> 
> As you can read above masks are needed for this event, so make sure you bring them!
> You also need to be fully vaccinated (Duh!), or show a negative test. See the details
> in the link.
> 
> We also 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/
> 
> 
> Agenda:
> 
> Below is the final (?) version of the agenda. I have tried to keep the sensor-related
> topics to after 11:00 since Dave comes in later in the day.
> 
> Changes since V2:
> - Updated attendees list.
> - Dropped my presentation since I'll be presenting the same thing at the ELCE on Friday
>   9:50.
> - Added keysigning party at the end of the day.
> - Added links to slides.
> 
> I am also making the (reasonable) assumption that most 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.
> 
> I added a guesstimate of the time needed for each topic. Please note that it is
> fine if we decide to discuss it further in the following days in a smaller group,
> or continue discussions on the mailing list.
> 
> If you present a topic, then please make a presentation. And if you have material you
> can share beforehand, then that would be great.
> 
> We have the room from 8:30-18:00, so I moved a few things around since V1, in particular
> please come in a bit earlier so you can set everything up (power, internet, etc.) so
> we can begin at 9 AM sharp.
> 
> Don't expect that the times below are precise (esp. after 11:00): past experience tells
> us that it can vary wildly.
> 
> Links to slides:
> 
> Ricardo: https://drive.google.com/file/d/1Tew21xeKmFlQ7dQxMcIYqybVuQL7La1a/view
> Dave: https://drive.google.com/file/d/1vjYJjTNRL1P3j6G4Nx2ZpjFtTBTNdeFG/view?usp=sharing
> Jacopo: https://nc.nibble.pw/s/oib8jzNjjtgB9c6
> 
> Agenda V3:
> 
>  8:40 Getting settled
>  9:00 Introduction
>  9:10 Nicolas: Stateless encoder progress
>  9:45 Ricardo: Introduce ChromeOS camera project: slides posted!
> 
> 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:50 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:10 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:30 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?
> 
> 15:00 Break
> 
> 15: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 ?
> 
> 
> 16:00 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:30 Laurent: How can we finalize conversion of v4l-utils to meson?
> 
> 16:45 Key signing party
> 
>       See: https://lore.kernel.org/linux-media/YxhplLKtRAQzlSK%2F@pendragon.ideasonboard.com/
> 
>       I'm really not sure where the 'party' aspect comes in, since while necessary,
>       it is all terribly boring :-)
> 
> 17:15-18:00 Anything else?
> 
> Regards,
> 
>         Hans

Re: [ANN] Media Summit at ELCE Dublin, September 12: Final (?) Agenda V3

[Jacopo Mondi]

Hello and thanks everyone for attending the media summit. The meeting
and the discussion were good, let's now try to move forward on the many
points that has been discussed.

Can I ask participants to go over the etherpad notes to check if
there's anything to change or add there, and once done have the notes
circulate on the list (or be stored on linuxtv.org where the notes
from previous meetings are ?)

Thanks
   j

On Thu, Sep 08, 2022 at 10:58:21AM +0200, Hans Verkuil wrote:
> Hi all,
>
> Here is some more information about the Media Summit:
>
> Date: Monday September 12
> Time: 8:45-18:00
> Location: Convention Centre Dublin
> Room: The Liffey B - Part 1
> Sponsored by: Cisco Systems Norway, Collabora and the Kodi Foundation
>
> We will have a projector or display to show presentations, power strips,
> a whiteboard and beverages. Lunch is sponsored by the Kodi Foundation.
>
> 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>
> Hugues FRUCHET <hugues.fruchet@st.com>
> Benjamin Gaignard <benjamin.gaignard@collabora.com>
> Jacopo Mondi <jacopo@jmondi.org>
> Michael Olbrich <m.olbrich@pengutronix.de>
> 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>
> Niklas Söderlund <niklas.soderlund@ragnatech.se> (afternoon only)
> Dave Stevenson <dave.stevenson@raspberrypi.com> (from 11 am approx.)
> Michael Tretter <m.tretter@pengutronix.de>
> Hans Verkuil <hverkuil@xs4all.nl>
> Philipp Zabel <p.zabel@pengutronix.de>
>
> Remote attendees:
>
> Mauro Carvalho Chehab <mchehab@kernel.org>
> Benjamin MUGNIER <benjamin.mugnier@foss.st.com>
>
> Regarding remote attendance: I will a second laptop with me and a good webcam.
> But whether this will work is not at all certain, esp. audio is often very poor. It very
> much depends on the room. I mailed Mauro and Benjamin instructions on how to join.
> We'll see if it works or not.
>
> We'll be using etherpad to keep notes. I created one here:
>
> https://pad.systemli.org/p/media-summit-2022
>
>
> The health and safety regulations will be those of the OSSE LF (updated on August 22):
>
> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/
>
> As you can read above masks are needed for this event, so make sure you bring them!
> You also need to be fully vaccinated (Duh!), or show a negative test. See the details
> in the link.
>
> We also 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/
>
>
> Agenda:
>
> Below is the final (?) version of the agenda. I have tried to keep the sensor-related
> topics to after 11:00 since Dave comes in later in the day.
>
> Changes since V2:
> - Updated attendees list.
> - Dropped my presentation since I'll be presenting the same thing at the ELCE on Friday
>   9:50.
> - Added keysigning party at the end of the day.
> - Added links to slides.
>
> I am also making the (reasonable) assumption that most 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.
>
> I added a guesstimate of the time needed for each topic. Please note that it is
> fine if we decide to discuss it further in the following days in a smaller group,
> or continue discussions on the mailing list.
>
> If you present a topic, then please make a presentation. And if you have material you
> can share beforehand, then that would be great.
>
> We have the room from 8:30-18:00, so I moved a few things around since V1, in particular
> please come in a bit earlier so you can set everything up (power, internet, etc.) so
> we can begin at 9 AM sharp.
>
> Don't expect that the times below are precise (esp. after 11:00): past experience tells
> us that it can vary wildly.
>
> Links to slides:
>
> Ricardo: https://drive.google.com/file/d/1Tew21xeKmFlQ7dQxMcIYqybVuQL7La1a/view
> Dave: https://drive.google.com/file/d/1vjYJjTNRL1P3j6G4Nx2ZpjFtTBTNdeFG/view?usp=sharing
> Jacopo: https://nc.nibble.pw/s/oib8jzNjjtgB9c6
>
> Agenda V3:
>
>  8:40 Getting settled
>  9:00 Introduction
>  9:10 Nicolas: Stateless encoder progress
>  9:45 Ricardo: Introduce ChromeOS camera project: slides posted!
>
> 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:50 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:10 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:30 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?
>
> 15:00 Break
>
> 15: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 ?
>
>
> 16:00 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:30 Laurent: How can we finalize conversion of v4l-utils to meson?
>
> 16:45 Key signing party
>
>       See: https://lore.kernel.org/linux-media/YxhplLKtRAQzlSK%2F@pendragon.ideasonboard.com/
>
>       I'm really not sure where the 'party' aspect comes in, since while necessary,
>       it is all terribly boring :-)
>
> 17:15-18:00 Anything else?
>
> Regards,
>
> 	Hans

Re: [ANN] Media Summit at ELCE Dublin, September 12: Final (?) Agenda V3

[Hans Verkuil]

Hi all,

On 21/09/2022 10:43, Jacopo Mondi wrote:
> Hello and thanks everyone for attending the media summit. The meeting
> and the discussion were good, let's now try to move forward on the many
> points that has been discussed.
> 
> Can I ask participants to go over the etherpad notes to check if
> there's anything to change or add there, and once done have the notes
> circulate on the list (or be stored on linuxtv.org where the notes
> from previous meetings are ?)

Indeed, please check the notes!

I tentatively plan to make a summit report by the end of next week or the
week after, so it's good to have the notes verified beforehand.

They are here: https://pad.systemli.org/p/media-summit-2022

Laurent, I think it is a good idea to split off the Kernel CAM discussion
from the summit report and instead combine it with the discussions on
Tuesday morning and put it in a separate report. If you agree, could you
perhaps create such a report?

Regards,

	Hans

> 
> Thanks
>    j
> 
> On Thu, Sep 08, 2022 at 10:58:21AM +0200, Hans Verkuil wrote:
>> Hi all,
>>
>> Here is some more information about the Media Summit:
>>
>> Date: Monday September 12
>> Time: 8:45-18:00
>> Location: Convention Centre Dublin
>> Room: The Liffey B - Part 1
>> Sponsored by: Cisco Systems Norway, Collabora and the Kodi Foundation
>>
>> We will have a projector or display to show presentations, power strips,
>> a whiteboard and beverages. Lunch is sponsored by the Kodi Foundation.
>>
>> 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>
>> Hugues FRUCHET <hugues.fruchet@st.com>
>> Benjamin Gaignard <benjamin.gaignard@collabora.com>
>> Jacopo Mondi <jacopo@jmondi.org>
>> Michael Olbrich <m.olbrich@pengutronix.de>
>> 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>
>> Niklas Söderlund <niklas.soderlund@ragnatech.se> (afternoon only)
>> Dave Stevenson <dave.stevenson@raspberrypi.com> (from 11 am approx.)
>> Michael Tretter <m.tretter@pengutronix.de>
>> Hans Verkuil <hverkuil@xs4all.nl>
>> Philipp Zabel <p.zabel@pengutronix.de>
>>
>> Remote attendees:
>>
>> Mauro Carvalho Chehab <mchehab@kernel.org>
>> Benjamin MUGNIER <benjamin.mugnier@foss.st.com>
>>
>> Regarding remote attendance: I will a second laptop with me and a good webcam.
>> But whether this will work is not at all certain, esp. audio is often very poor. It very
>> much depends on the room. I mailed Mauro and Benjamin instructions on how to join.
>> We'll see if it works or not.
>>
>> We'll be using etherpad to keep notes. I created one here:
>>
>> https://pad.systemli.org/p/media-summit-2022
>>
>>
>> The health and safety regulations will be those of the OSSE LF (updated on August 22):
>>
>> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/
>>
>> As you can read above masks are needed for this event, so make sure you bring them!
>> You also need to be fully vaccinated (Duh!), or show a negative test. See the details
>> in the link.
>>
>> We also 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/
>>
>>
>> Agenda:
>>
>> Below is the final (?) version of the agenda. I have tried to keep the sensor-related
>> topics to after 11:00 since Dave comes in later in the day.
>>
>> Changes since V2:
>> - Updated attendees list.
>> - Dropped my presentation since I'll be presenting the same thing at the ELCE on Friday
>>   9:50.
>> - Added keysigning party at the end of the day.
>> - Added links to slides.
>>
>> I am also making the (reasonable) assumption that most 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.
>>
>> I added a guesstimate of the time needed for each topic. Please note that it is
>> fine if we decide to discuss it further in the following days in a smaller group,
>> or continue discussions on the mailing list.
>>
>> If you present a topic, then please make a presentation. And if you have material you
>> can share beforehand, then that would be great.
>>
>> We have the room from 8:30-18:00, so I moved a few things around since V1, in particular
>> please come in a bit earlier so you can set everything up (power, internet, etc.) so
>> we can begin at 9 AM sharp.
>>
>> Don't expect that the times below are precise (esp. after 11:00): past experience tells
>> us that it can vary wildly.
>>
>> Links to slides:
>>
>> Ricardo: https://drive.google.com/file/d/1Tew21xeKmFlQ7dQxMcIYqybVuQL7La1a/view
>> Dave: https://drive.google.com/file/d/1vjYJjTNRL1P3j6G4Nx2ZpjFtTBTNdeFG/view?usp=sharing
>> Jacopo: https://nc.nibble.pw/s/oib8jzNjjtgB9c6
>>
>> Agenda V3:
>>
>>  8:40 Getting settled
>>  9:00 Introduction
>>  9:10 Nicolas: Stateless encoder progress
>>  9:45 Ricardo: Introduce ChromeOS camera project: slides posted!
>>
>> 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:50 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:10 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:30 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?
>>
>> 15:00 Break
>>
>> 15: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 ?
>>
>>
>> 16:00 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:30 Laurent: How can we finalize conversion of v4l-utils to meson?
>>
>> 16:45 Key signing party
>>
>>       See: https://lore.kernel.org/linux-media/YxhplLKtRAQzlSK%2F@pendragon.ideasonboard.com/
>>
>>       I'm really not sure where the 'party' aspect comes in, since while necessary,
>>       it is all terribly boring :-)
>>
>> 17:15-18:00 Anything else?
>>
>> Regards,
>>
>> 	Hans