From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BC3B5C6FA82 for ; Mon, 12 Sep 2022 18:44:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229833AbiILSow (ORCPT ); Mon, 12 Sep 2022 14:44:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33026 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229536AbiILSov (ORCPT ); Mon, 12 Sep 2022 14:44:51 -0400 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E4D7D13EA5 for ; Mon, 12 Sep 2022 11:44:48 -0700 (PDT) Received: from pendragon.ideasonboard.com (cpc89244-aztw30-2-0-cust3082.18-1.cable.virginm.net [86.31.172.11]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 2F018415; Mon, 12 Sep 2022 20:44:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1663008286; bh=Y5g00Qu/oEY/EEr5sGvpPMZAcxSZlz31eB3foHcVC7I=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=WtnPo9jgEfGp4PpfIS0YOYrrFCDrZWyLNkIx8vlEZZdC33lJrHaKqtAyEOQbZiDOB nElRp91xbRcQ2lNVczah9vzVwwqRaTnazW1i9q6sBptHY8829GR/t2ge3Yvl8kalhy Bf2Ek7olEcdcql/qhlAVwMAiST1ISGUXNq2cmPl0= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <3ff46b2d-eb01-1ce9-8647-19447c82283b@xs4all.nl> References: <3ff46b2d-eb01-1ce9-8647-19447c82283b@xs4all.nl> Subject: Re: [ANN] Media Summit at ELCE Dublin, September 12: Final (?) Agenda V3 From: Kieran Bingham Cc: Sakari Ailus , Nicolas Dufresne , Benjamin Gaignard , Jacopo Mondi , Laurent Pinchart , Ricardo Ribalda , Maxime Ripard , Daniel Scally , Jernej =?utf-8?q?=C5=A0krabec?= , Dave Stevenson , Philipp Zabel , Hugues Fruchet , Michael Olbrich , Niklas =?utf-8?q?S=C3=B6derlund?= , Michael Tretter , Mauro Carvalho Chehab , Benjamin MUGNIER To: Hans Verkuil , linux-media@vger.kernel.org Date: Mon, 12 Sep 2022 19:44:43 +0100 Message-ID: <166300828368.2110681.9419892589409911413@Monstersaurus> User-Agent: alot/0.10 Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Quoting Hans Verkuil (2022-09-08 09:58:21) > Hi all, We've got a table here for dinner tonight.=20 https://maps.app.goo.gl/2jU58EYhHJoZJHVa9 the port house pintxo -- kieran >=20 > Here is some more information about the Media Summit: >=20 > 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 >=20 > We will have a projector or display to show presentations, power strips, > a whiteboard and beverages. Lunch is sponsored by the Kodi Foundation. >=20 > It's co-located with the OSS Europe conference: >=20 > https://events.linuxfoundation.org/open-source-summit-europe/ >=20 > Attendees: >=20 > Sakari Ailus > Kieran Bingham > Nicolas Dufresne > Hugues FRUCHET > Benjamin Gaignard > Jacopo Mondi > Michael Olbrich > Laurent Pinchart > Ricardo Ribalda > Maxime Ripard > Daniel Scally > Jernej =C5=A0krabec > Niklas S=C3=B6derlund (afternoon only) > Dave Stevenson (from 11 am approx.) > Michael Tretter > Hans Verkuil > Philipp Zabel >=20 > Remote attendees: >=20 > Mauro Carvalho Chehab > Benjamin MUGNIER >=20 > Regarding remote attendance: I will a second laptop with me and a good we= bcam. > But whether this will work is not at all certain, esp. audio is often ver= y 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. >=20 > We'll be using etherpad to keep notes. I created one here: >=20 > https://pad.systemli.org/p/media-summit-2022 >=20 >=20 > The health and safety regulations will be those of the OSSE LF (updated o= n August 22): >=20 > https://events.linuxfoundation.org/open-source-summit-europe/attend/healt= h-and-safety/ >=20 > As you can read above masks are needed for this event, so make sure you b= ring them! > You also need to be fully vaccinated (Duh!), or show a negative test. See= the details > in the link. >=20 > We also strongly recommend that you do a self-test before going to the Co= nference Centre > for this meeting. >=20 >=20 > Code of conduct: >=20 > https://events.linuxfoundation.org/open-source-summit-europe/attend/code-= of-conduct/ >=20 >=20 > Agenda: >=20 > Below is the final (?) version of the agenda. I have tried to keep the se= nsor-related > topics to after 11:00 since Dave comes in later in the day. >=20 > 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. >=20 > 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 se= t up > a small group that can discuss it further in the following days. >=20 > 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 smalle= r group, > or continue discussions on the mailing list. >=20 > If you present a topic, then please make a presentation. And if you have = material you > can share beforehand, then that would be great. >=20 > 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, interne= t, etc.) so > we can begin at 9 AM sharp. >=20 > Don't expect that the times below are precise (esp. after 11:00): past ex= perience tells > us that it can vary wildly. >=20 > Links to slides: >=20 > Ricardo: https://drive.google.com/file/d/1Tew21xeKmFlQ7dQxMcIYqybVuQL7La1= a/view > Dave: https://drive.google.com/file/d/1vjYJjTNRL1P3j6G4Nx2ZpjFtTBTNdeFG/v= iew?usp=3Dsharing > Jacopo: https://nc.nibble.pw/s/oib8jzNjjtgB9c6 >=20 > Agenda V3: >=20 > 8:40 Getting settled > 9:00 Introduction > 9:10 Nicolas: Stateless encoder progress > 9:45 Ricardo: Introduce ChromeOS camera project: slides posted! >=20 > 11:00 Break >=20 > 11:15 Kieran: Fault tolerance >=20 > 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). >=20 > Summary of issue: >=20 > - 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 11:45 Jacopo: Representing addition sensor processing stages. >=20 > 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. >=20 > https://lore.kernel.org/linux-media/CAPY8ntA06L1Xsph79sv9t7MiDSNeSO2vAD= evuXZdXQdhWpSmow@mail.gmail.com/ >=20 > Dave made a good introduction of the issue his email which got > largely unanswered. >=20 > 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. >=20 > 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. >=20 > 12:30 Lunch >=20 > 13:30 Dave: On-sensor temperature reporting. >=20 > Thread started by Benjamin at > https://lore.kernel.org/linux-media/20220415111845.27130-3-benjamin.mug= nier@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. >=20 > It's recently been queried for IMX477 with the Pi > (https://github.com/raspberrypi/libcamera/issues/19), but it will > apply to many sensors. >=20 > 13:50 Dave: Synchronising sensors for stereoscopic operation. >=20 > 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 defau= lt > configuration for each sensor from DT/ACPI and then allow userspace to > override should it wish? >=20 > 14:10 Dave: Lens drivers. >=20 > 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? >=20 > 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? >=20 > 14:30 Dave: Controlling sensor GPIO outputs. >=20 > Controlling sensor GPIO outputs for things such as flash triggers, > vsync, frame start/end, exposure start/end, etc. >=20 > 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? >=20 > 15:00 Break >=20 > 15:30 Jacopo: Reconcile handling of regulator, gpios and clock on OF and = ACPI platforms. >=20 > 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: >=20 > https://lore.kernel.org/linux-media/20220425061022.1569480-1-paul.elder= @ideasonboard.com/ > https://lore.kernel.org/linux-media/20220329090133.338073-1-jacopo@jmon= di.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/comm= it/?id=3D0c2c7a1e0d69221b9d489bfd8cf53262d6f82446 >=20 > 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 ? >=20 >=20 > 16:00 Laurent: V4L2 streams series. >=20 > 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. >=20 > 16:30 Laurent: How can we finalize conversion of v4l-utils to meson? >=20 > 16:45 Key signing party >=20 > See: https://lore.kernel.org/linux-media/YxhplLKtRAQzlSK%2F@pendrag= on.ideasonboard.com/ >=20 > I'm really not sure where the 'party' aspect comes in, since while = necessary, > it is all terribly boring :-) >=20 > 17:15-18:00 Anything else? >=20 > Regards, >=20 > Hans