[{"id":30851,"web_url":"https://patchwork.libcamera.org/comment/30851/","msgid":"<20240816010112.GB15356@pendragon.ideasonboard.com>","date":"2024-08-16T01:01:12","subject":"Re: [PATCH v2.1 4/7] Documentation: Breakout docs.rst","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Dan,\n\nThank you for the patch.\n\nOn Thu, Aug 15, 2024 at 10:59:31AM +0100, Daniel Scally wrote:\n> In preparation for including more of the Documentation for libcamera\n> on the website, break out the Camera Stack and Feature Requirements\n> sections of docs.rst file into separate files for each section. Add\n> all of the new files to documentation-contents.rst so they're\n> included on the website too.\n> \n> Signed-off-by: Daniel Scally \n> ---\n> Changes since v2:\n> \n> \t- Fixed the docs_sources array\n> \n> Changes since v1:\n> \n> \t- Included the new files in meson's docs_sources array\n> \n> Documentation/camera_stack.rst | 78 ++++++++\n> Documentation/docs.rst | 219 -----------------------\n> Documentation/documentation-contents.rst | 2 +\n> Documentation/feature_requirements.rst | 145 +++++++++++++++\n> Documentation/index.rst | 2 +\n> Documentation/meson.build | 2 +\n> 6 files changed, 229 insertions(+), 219 deletions(-)\n> create mode 100644 Documentation/camera_stack.rst\n> create mode 100644 Documentation/feature_requirements.rst\n> \n> diff --git a/Documentation/camera_stack.rst b/Documentation/camera_stack.rst\n> new file mode 100644\n> index 00000000..381385cb\n> --- /dev/null\n> +++ b/Documentation/camera_stack.rst\n> @@ -0,0 +1,78 @@\n> +.. SPDX-License-Identifier: CC-BY-SA-4.0\n> +\n> +.. include:: documentation-contents.rst\n> +\n> +Camera Stack\n> +============\n> +\n> +::\n> +\n> + a c / +-------------+ +-------------+ +-------------+ +-------------+\n> + p a | | Native | | Framework | | Native | | Android |\n> + p t | | V4L2 | | Application | | libcamera | | Camera |\n> + l i | | Application | | (gstreamer) | | Application | | Framework |\n> + i o \\ +-------------+ +-------------+ +-------------+ +-------------+\n> + n ^ ^ ^ ^\n> + | | | |\n> + l a | | | |\n> + i d v v | v\n> + b a / +-------------+ +-------------+ | +-------------+\n> + c p | | V4L2 | | Camera | | | Android |\n> + a t | | Compat. | | Framework | | | Camera |\n> + m a | | | | (gstreamer) | | | HAL |\n> + e t \\ +-------------+ +-------------+ | +-------------+\n> + r i ^ ^ | ^\n> + a o | | | |\n> + n | | | |\n> + / | ,................................................\n> + | | ! : Language : !\n> + l f | | ! : Bindings : !\n> + i r | | ! : (optional) : !\n> + b a | | \\...............................................'\n> + c m | | | | |\n> + a e | | | | |\n> + m w | v v v v\n> + e o | +----------------------------------------------------------------+\n> + r r | | |\n> + a k | | libcamera |\n> + | | |\n> + \\ +----------------------------------------------------------------+\n> + ^ ^ ^\n> + Userspace | | |\n> + ------------------------ | ---------------- | ---------------- | ---------------\n> + Kernel | | |\n> + v v v\n> + +-----------+ +-----------+ +-----------+\n> + | Media | <--> | Video | <--> | V4L2 |\n> + | Device | | Device | | Subdev |\n> + +-----------+ +-----------+ +-----------+\n> +\n> +The camera stack comprises four software layers. From bottom to top:\n> +\n> +* The kernel drivers control the camera hardware and expose a\n> + low-level interface to userspace through the Linux kernel V4L2\n> + family of APIs (Media Controller API, V4L2 Video Device API and\n> + V4L2 Subdev API).\n> +\n> +* The libcamera framework is the core part of the stack. It\n> + handles all control of the camera devices in its core component,\n> + libcamera, and exposes a native C++ API to upper layers. Optional\n> + language bindings allow interfacing to libcamera from other\n> + programming languages.\n> +\n> + Those components live in the same source code repository and\n> + all together constitute the libcamera framework.\n> +\n> +* The libcamera adaptation is an umbrella term designating the\n> + components that interface to libcamera in other frameworks.\n> + Notable examples are a V4L2 compatibility layer, a gstreamer\n> + libcamera element, and an Android camera HAL implementation based\n> + on libcamera.\n> +\n> + Those components can live in the libcamera project source code\n> + in separate repositories, or move to their respective project's\n> + repository (for instance the gstreamer libcamera element).\n> +\n> +* The applications and upper level frameworks are based on the\n> + libcamera framework or libcamera adaptation, and are outside of\n> + the scope of the libcamera project.\n> diff --git a/Documentation/docs.rst b/Documentation/docs.rst\n> index 10f07a9e..d65b2b4f 100644\n> --- a/Documentation/docs.rst\n> +++ b/Documentation/docs.rst\n> @@ -21,225 +21,6 @@ The libcamera API is extensively documented using Doxygen. The :ref:`API\n> nightly build ` contains the most up-to-date API documentation, built from\n> the latest master branch.\n> \n> -Feature Requirements\n> -====================\n> -\n> -Device enumeration\n> -------------------\n> -\n> -The library shall support enumerating all camera devices available in the\n> -system, including both fixed cameras and hotpluggable cameras. It shall\n> -support cameras plugged and unplugged after the initialization of the\n> -library, and shall offer a mechanism to notify applications of camera plug\n> -and unplug.\n> -\n> -The following types of cameras shall be supported:\n> -\n> -* Internal cameras designed for point-and-shoot still image and video\n> - capture usage, either controlled directly by the CPU, or exposed through\n> - an internal USB bus as a UVC device.\n> -\n> -* External UVC cameras designed for video conferencing usage.\n> -\n> -Other types of camera, including analog cameras, depth cameras, thermal\n> -cameras, external digital picture or movie cameras, are out of scope for\n> -this project.\n> -\n> -A hardware device that includes independent camera sensors, such as front\n> -and back sensors in a phone, shall be considered as multiple camera devices\n> -for the purpose of this library.\n> -\n> -Independent Camera Devices\n> ---------------------------\n> -\n> -When multiple cameras are present in the system and are able to operate\n> -independently from each other, the library shall expose them as multiple\n> -camera devices and support parallel operation without any additional usage\n> -restriction apart from the limitations inherent to the hardware (such as\n> -memory bandwidth, CPU usage or number of CSI-2 receivers for instance).\n> -\n> -Independent processes shall be able to use independent cameras devices\n> -without interfering with each other. A single camera device shall be\n> -usable by a single process at a time.\n> -\n> -Multiple streams support\n> -------------------------\n> -\n> -The library shall support multiple video streams running in parallel\n> -for each camera device, within the limits imposed by the system.\n> -\n> -Per frame controls\n> -------------------\n> -\n> -The library shall support controlling capture parameters for each stream\n> -on a per-frame basis, on a best effort basis based on the capabilities of the\n> -hardware and underlying software stack (including kernel drivers and\n> -firmware). It shall apply capture parameters to the frame they target, and\n> -report the value of the parameters that have effectively been used for each\n> -captured frame.\n> -\n> -When a camera device supports multiple streams, the library shall allow both\n> -control of each stream independently, and control of multiple streams\n> -together. Streams that are controlled together shall be synchronized. No\n> -synchronization is required for streams controlled independently.\n> -\n> -Capability Enumeration\n> -----------------------\n> -\n> -The library shall expose capabilities of each camera device in a way that\n> -allows applications to discover those capabilities dynamically. Applications\n> -shall be allowed to cache capabilities for as long as they are using the\n> -library. If capabilities can change at runtime, the library shall offer a\n> -mechanism to notify applications of such changes. Applications shall not\n> -cache capabilities in long term storage between runs.\n> -\n> -Capabilities shall be discovered dynamically at runtime from the device when\n> -possible, and may come, in part or in full, from platform configuration\n> -data.\n> -\n> -Device Profiles\n> ----------------\n> -\n> -The library may define different camera device profiles, each with a minimum\n> -set of required capabilities. Applications may use those profiles to quickly\n> -determine the level of features exposed by a device without parsing the full\n> -list of capabilities. Camera devices may implement additional capabilities\n> -on top of the minimum required set for the profile they expose.\n> -\n> -3A and Image Enhancement Algorithms\n> ------------------------------------\n> -\n> -The camera devices shall implement auto exposure, auto gain and auto white\n> -balance. Camera devices that include a focus lens shall implement auto\n> -focus. Additional image enhancement algorithms, such as noise reduction or\n> -video stabilization, may be implemented.\n> -\n> -All algorithms may be implemented in hardware or firmware outside of the\n> -library, or in software in the library. They shall all be controllable by\n> -applications.\n> -\n> -The library shall be architectured to isolate the 3A and image enhancement\n> -algorithms in a component with a documented API, respectively called the 3A\n> -component and the 3A API. The 3A API shall be stable, and shall allow both\n> -open-source and closed-source implementations of the 3A component.\n> -\n> -The library may include statically-linked open-source 3A components, and\n> -shall support dynamically-linked open-source and closed-source 3A\n> -components.\n> -\n> -Closed-source 3A Component Sandboxing\n> --------------------------------------\n> -\n> -For security purposes, it may be desired to run closed-source 3A components\n> -in a separate process. The 3A API would in such a case be transported over\n> -IPC. The 3A API shall make it possible to use any IPC mechanism that\n> -supports passing file descriptors.\n> -\n> -The library may implement an IPC mechanism, and shall support third-party\n> -platform-specific IPC mechanisms through the implementation of a\n> -platform-specific 3A API wrapper. No modification to the library shall be\n> -needed to use such third-party IPC mechanisms.\n> -\n> -The 3A component shall not directly access any device node on the system.\n> -Such accesses shall instead be performed through the 3A API. The library\n> -shall validate all accesses and restrict them to what is absolutely required\n> -by 3A components.\n> -\n> -V4L2 Compatibility Layer\n> -------------------------\n> -\n> -The project shall support traditional V4L2 application through an additional\n> -libcamera wrapper library. The wrapper library shall trap all accesses to\n> -camera devices through `LD_PRELOAD`, and route them through libcamera to\n> -emulate a high-level V4L2 camera device. It shall expose camera device\n> -features on a best-effort basis, and aim for the level of features\n> -traditionally available from a UVC camera designed for video conferencing.\n> -\n> -Android Camera HAL v3 Compatibility\n> ------------------------------------\n> -\n> -The library API shall expose all the features required to implement an\n> -Android Camera HAL v3 on top of libcamera. Some features of the HAL may be\n> -omitted as long as they can be implemented separately in the HAL, such as\n> -JPEG encoding, or YUV reprocessing.\n> -\n> -\n> -Camera Stack\n> -============\n> -\n> -::\n> -\n> - a c / +-------------+ +-------------+ +-------------+ +-------------+\n> - p a | | Native | | Framework | | Native | | Android |\n> - p t | | V4L2 | | Application | | libcamera | | Camera |\n> - l i | | Application | | (gstreamer) | | Application | | Framework |\n> - i o \\ +-------------+ +-------------+ +-------------+ +-------------+\n> - n ^ ^ ^ ^\n> - | | | |\n> - l a | | | |\n> - i d v v | v\n> - b a / +-------------+ +-------------+ | +-------------+\n> - c p | | V4L2 | | Camera | | | Android |\n> - a t | | Compat. | | Framework | | | Camera |\n> - m a | | | | (gstreamer) | | | HAL |\n> - e t \\ +-------------+ +-------------+ | +-------------+\n> - r i ^ ^ | ^\n> - a o | | | |\n> - n | | | |\n> - / | ,................................................\n> - | | ! : Language : !\n> - l f | | ! : Bindings : !\n> - i r | | ! : (optional) : !\n> - b a | | \\...............................................'\n> - c m | | | | |\n> - a e | | | | |\n> - m w | v v v v\n> - e o | +----------------------------------------------------------------+\n> - r r | | |\n> - a k | | libcamera |\n> - | | |\n> - \\ +----------------------------------------------------------------+\n> - ^ ^ ^\n> - Userspace | | |\n> - ------------------------ | ---------------- | ---------------- | ---------------\n> - Kernel | | |\n> - v v v\n> - +-----------+ +-----------+ +-----------+\n> - | Media | <--> | Video | <--> | V4L2 |\n> - | Device | | Device | | Subdev |\n> - +-----------+ +-----------+ +-----------+\n> -\n> -The camera stack comprises four software layers. From bottom to top:\n> -\n> -* The kernel drivers control the camera hardware and expose a\n> - low-level interface to userspace through the Linux kernel V4L2\n> - family of APIs (Media Controller API, V4L2 Video Device API and\n> - V4L2 Subdev API).\n> -\n> -* The libcamera framework is the core part of the stack. It\n> - handles all control of the camera devices in its core component,\n> - libcamera, and exposes a native C++ API to upper layers. Optional\n> - language bindings allow interfacing to libcamera from other\n> - programming languages.\n> -\n> - Those components live in the same source code repository and\n> - all together constitute the libcamera framework.\n> -\n> -* The libcamera adaptation is an umbrella term designating the\n> - components that interface to libcamera in other frameworks.\n> - Notable examples are a V4L2 compatibility layer, a gstreamer\n> - libcamera element, and an Android camera HAL implementation based\n> - on libcamera.\n> -\n> - Those components can live in the libcamera project source code\n> - in separate repositories, or move to their respective project's\n> - repository (for instance the gstreamer libcamera element).\n> -\n> -* The applications and upper level frameworks are based on the\n> - libcamera framework or libcamera adaptation, and are outside of\n> - the scope of the libcamera project.\n> -\n> -\n> libcamera Architecture\n> ======================\n> \n> diff --git a/Documentation/documentation-contents.rst b/Documentation/documentation-contents.rst\n> index a6915e05..613366d1 100644\n> --- a/Documentation/documentation-contents.rst\n> +++ b/Documentation/documentation-contents.rst\n> @@ -4,9 +4,11 @@\n> \n> * :doc:`/api-html/index`\n> * :doc:`/camera-sensor-model`\n> + * :doc:`/camera_stack`\n> * :doc:`/code-of-conduct`\n> * :doc:`/coding-style`\n> * :doc:`/environment_variables`\n> + * :doc:`/feature_requirements`\n> * :doc:`/guides/application-developer`\n> * :doc:`/guides/introduction`\n> * :doc:`/guides/ipa`\n> diff --git a/Documentation/feature_requirements.rst b/Documentation/feature_requirements.rst\n> new file mode 100644\n> index 00000000..cae7e9ab\n> --- /dev/null\n> +++ b/Documentation/feature_requirements.rst\n> @@ -0,0 +1,145 @@\n> +.. SPDX-License-Identifier: CC-BY-SA-4.0\n> +\n> +.. include:: documentation-contents.rst\n> +\n> +Feature Requirements\n> +====================\n\nWe should revisit all this at some point, but that's out of scope for\nthis series.\n\n> +\n> +Device enumeration\n> +------------------\n> +\n> +The library shall support enumerating all camera devices available in the\n> +system, including both fixed cameras and hotpluggable cameras. It shall\n> +support cameras plugged and unplugged after the initialization of the\n> +library, and shall offer a mechanism to notify applications of camera plug\n> +and unplug.\n> +\n> +The following types of cameras shall be supported:\n> +\n> +* Internal cameras designed for point-and-shoot still image and video\n> + capture usage, either controlled directly by the CPU, or exposed through\n> + an internal USB bus as a UVC device.\n> +\n> +* External UVC cameras designed for video conferencing usage.\n> +\n> +Other types of camera, including analog cameras, depth cameras, thermal\n> +cameras, external digital picture or movie cameras, are out of scope for\n> +this project.\n> +\n> +A hardware device that includes independent camera sensors, such as front\n> +and back sensors in a phone, shall be considered as multiple camera devices\n> +for the purpose of this library.\n> +\n> +Independent Camera Devices\n> +--------------------------\n> +\n> +When multiple cameras are present in the system and are able to operate\n> +independently from each other, the library shall expose them as multiple\n> +camera devices and support parallel operation without any additional usage\n> +restriction apart from the limitations inherent to the hardware (such as\n> +memory bandwidth, CPU usage or number of CSI-2 receivers for instance).\n> +\n> +Independent processes shall be able to use independent cameras devices\n> +without interfering with each other. A single camera device shall be\n> +usable by a single process at a time.\n> +\n> +Multiple streams support\n> +------------------------\n> +\n> +The library shall support multiple video streams running in parallel\n> +for each camera device, within the limits imposed by the system.\n> +\n> +Per frame controls\n> +------------------\n> +\n> +The library shall support controlling capture parameters for each stream\n> +on a per-frame basis, on a best effort basis based on the capabilities of the\n> +hardware and underlying software stack (including kernel drivers and\n> +firmware). It shall apply capture parameters to the frame they target, and\n> +report the value of the parameters that have effectively been used for each\n> +captured frame.\n> +\n> +When a camera device supports multiple streams, the library shall allow both\n> +control of each stream independently, and control of multiple streams\n> +together. Streams that are controlled together shall be synchronized. No\n> +synchronization is required for streams controlled independently.\n> +\n> +Capability Enumeration\n> +----------------------\n> +\n> +The library shall expose capabilities of each camera device in a way that\n> +allows applications to discover those capabilities dynamically. Applications\n> +shall be allowed to cache capabilities for as long as they are using the\n> +library. If capabilities can change at runtime, the library shall offer a\n> +mechanism to notify applications of such changes. Applications shall not\n> +cache capabilities in long term storage between runs.\n> +\n> +Capabilities shall be discovered dynamically at runtime from the device when\n> +possible, and may come, in part or in full, from platform configuration\n> +data.\n> +\n> +Device Profiles\n> +---------------\n> +\n> +The library may define different camera device profiles, each with a minimum\n> +set of required capabilities. Applications may use those profiles to quickly\n> +determine the level of features exposed by a device without parsing the full\n> +list of capabilities. Camera devices may implement additional capabilities\n> +on top of the minimum required set for the profile they expose.\n> +\n> +3A and Image Enhancement Algorithms\n> +-----------------------------------\n> +\n> +The camera devices shall implement auto exposure, auto gain and auto white\n> +balance. Camera devices that include a focus lens shall implement auto\n> +focus. Additional image enhancement algorithms, such as noise reduction or\n> +video stabilization, may be implemented.\n> +\n> +All algorithms may be implemented in hardware or firmware outside of the\n> +library, or in software in the library. They shall all be controllable by\n> +applications.\n> +\n> +The library shall be architectured to isolate the 3A and image enhancement\n> +algorithms in a component with a documented API, respectively called the 3A\n> +component and the 3A API. The 3A API shall be stable, and shall allow both\n> +open-source and closed-source implementations of the 3A component.\n> +\n> +The library may include statically-linked open-source 3A components, and\n> +shall support dynamically-linked open-source and closed-source 3A\n> +components.\n> +\n> +Closed-source 3A Component Sandboxing\n> +-------------------------------------\n> +\n> +For security purposes, it may be desired to run closed-source 3A components\n> +in a separate process. The 3A API would in such a case be transported over\n> +IPC. The 3A API shall make it possible to use any IPC mechanism that\n> +supports passing file descriptors.\n> +\n> +The library may implement an IPC mechanism, and shall support third-party\n> +platform-specific IPC mechanisms through the implementation of a\n> +platform-specific 3A API wrapper. No modification to the library shall be\n> +needed to use such third-party IPC mechanisms.\n> +\n> +The 3A component shall not directly access any device node on the system.\n> +Such accesses shall instead be performed through the 3A API. The library\n> +shall validate all accesses and restrict them to what is absolutely required\n> +by 3A components.\n> +\n> +V4L2 Compatibility Layer\n> +------------------------\n> +\n> +The project shall support traditional V4L2 application through an additional\n> +libcamera wrapper library. The wrapper library shall trap all accesses to\n> +camera devices through `LD_PRELOAD`, and route them through libcamera to\n> +emulate a high-level V4L2 camera device. It shall expose camera device\n> +features on a best-effort basis, and aim for the level of features\n> +traditionally available from a UVC camera designed for video conferencing.\n> +\n> +Android Camera HAL v3 Compatibility\n> +-----------------------------------\n> +\n> +The library API shall expose all the features required to implement an\n> +Android Camera HAL v3 on top of libcamera. Some features of the HAL may be\n> +omitted as long as they can be implemented separately in the HAL, such as\n> +JPEG encoding, or YUV reprocessing.\n> diff --git a/Documentation/index.rst b/Documentation/index.rst\n> index 52ddc494..59416906 100644\n> --- a/Documentation/index.rst\n> +++ b/Documentation/index.rst\n> @@ -16,8 +16,10 @@\n> \n> Application Writer's Guide \n> Camera Sensor Model \n> + Camera Stack \n> Developer Guide \n> Environment variables \n> + Feature Requirements \n> IPA Writer's guide \n> Lens driver requirements \n> Pipeline Handler Writer's Guide \n> diff --git a/Documentation/meson.build b/Documentation/meson.build\n> index c5736991..bf5a80bd 100644\n> --- a/Documentation/meson.build\n> +++ b/Documentation/meson.build\n> @@ -124,6 +124,7 @@ endif\n> if sphinx.found()\n> docs_sources = [\n> 'camera-sensor-model.rst',\n> +\t'camera_stack.rst',\n\ncheckstyle.py should have warned you. Same below. Apart from that,\n\nReviewed-by: Laurent Pinchart \n\n> 'code-of-conduct.rst',\n> 'coding-style.rst',\n> 'conf.py',\n> @@ -131,6 +132,7 @@ if sphinx.found()\n> 'docs.rst',\n> \t'documentation-contents.rst',\n> 'environment_variables.rst',\n> +\t'feature_requirements.rst',\n> 'guides/application-developer.rst',\n> 'guides/introduction.rst',\n> 'guides/ipa.rst',","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 6AB1BC323E\n\tfor ;\n\tFri, 16 Aug 2024 01:01:42 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 3DF60633B3;\n\tFri, 16 Aug 2024 03:01:41 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id BD65B63369\n\tfor ;\n\tFri, 16 Aug 2024 03:01:39 +0200 (CEST)","from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi\n\t[81.175.209.231])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 487BA593;\n\tFri, 16 Aug 2024 03:00:40 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"SnOSZk67\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1723770040;\n\tbh=v1TxhFXktHgK0y2DTuXsWj6yDo9RmEjUlfKHfd9YyBU=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=SnOSZk67Z977kUJUXBDAOtZ8MwzkZRtWNgJPUKWqFdC3FYLkWmGxWUQaYjzCn07l5\n\tFgNLjl8eufdVhbqwiuvTTUhogB8bQpmW9bqnkHr/oShjKQGCzyp1XD8MwDpsUAizPU\n\tdc4PUViRGNBJkPYJ3I/AJhCKRQKiJjAt3mpqtvCo=","Date":"Fri, 16 Aug 2024 04:01:12 +0300","From":"Laurent Pinchart ","To":"Daniel Scally ","Cc":"libcamera-devel@lists.libcamera.org","Subject":"Re: [PATCH v2.1 4/7] Documentation: Breakout docs.rst","Message-ID":"<20240816010112.GB15356@pendragon.ideasonboard.com>","References":"<20240815082944.170109-5-dan.scally@ideasonboard.com>\n\t<20240815095931.187826-1-dan.scally@ideasonboard.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20240815095931.187826-1-dan.scally@ideasonboard.com>","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]