[{"id":30876,"web_url":"https://patchwork.libcamera.org/comment/30876/","msgid":"<20240820163742.GD7478@pendragon.ideasonboard.com>","date":"2024-08-20T16:37:42","subject":"Re: [PATCH v4 5/9] Documentation: Remove libcamera architecture from\n\tintroduction.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 Tue, Aug 20, 2024 at 02:07:36PM +0100, Daniel Scally wrote:\n> The libcamera Architecture section of the introduction is largely a\n> duplicate of the section broken out from docs.rst. Remove it from the\n> introduction.rst file and consolidate anything that wasn't duplicated\n> into libcamera_architecture.rst and feature_requirements.rst. Take the\n> opportunity to also expand the list of Platform Support which is now a\n> bit out of date.\n> \n> Signed-off-by: Daniel Scally \n\nReviewed-by: Laurent Pinchart \n\n> ---\n> Changes since v3:\n> \n> \t- Merged the contents rather than replaced one with the other, following\n> \t Laurent's suggestion. Also merged one section into the page detailing\n> \t feature requirements\n> \n> Changes since v2:\n> \n> \t- Reworked to change libcamera architecture section instead of camera\n> \t stack. DDropped R-b\n> \t- Updated the list of supported platforms on the new libcamera\n> \t architecture page\n> \n> Changes since v1:\n> \n> \t- None\n> \n> Documentation/feature_requirements.rst | 13 +-\n> Documentation/guides/introduction.rst | 156 +--------------\n> Documentation/libcamera_architecture.rst | 244 +++++++++++++----------\n> 3 files changed, 148 insertions(+), 265 deletions(-)\n> \n> diff --git a/Documentation/feature_requirements.rst b/Documentation/feature_requirements.rst\n> index cae7e9ab..e6b74a62 100644\n> --- a/Documentation/feature_requirements.rst\n> +++ b/Documentation/feature_requirements.rst\n> @@ -90,10 +90,15 @@ on top of the minimum required set for the profile they expose.\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> +The library shall provide a basic implementation of Image Processing Algorithms\n> +to serve as a reference for the internal API. This shall including auto exposure\n> +and gain and auto white balance. Camera devices that include a focus lens shall\n> +implement auto focus. Additional image enhancement algorithms, such as noise\n> +reduction or video stabilization, may be implemented. Device vendors are\n> +expected to provide a fully-fledged implementation compatible with their\n> +Pipeline Handler. One goal of the libcamera project is to create an environment\n> +in which the community will be able to compete with the closed-source vendor\n> +biaries and develop a high quality open source implementation.\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> diff --git a/Documentation/guides/introduction.rst b/Documentation/guides/introduction.rst\n> index d1e67654..12d1b7d4 100644\n> --- a/Documentation/guides/introduction.rst\n> +++ b/Documentation/guides/introduction.rst\n> @@ -26,10 +26,8 @@ desirable results from the camera.\n> .. _Media Controller: https://www.linuxtv.org/downloads/v4l-dvb-apis-new/userspace-api/mediactl/media-controller.html\n> \n> \n> -In this developers guide, we will explore the internal `Architecture`_ of\n> -the libcamera library with its components. The current `Platform Support`_ is\n> -detailed, as well as an overview of the `Licensing`_ requirements of the\n> -project.\n> +In this developers guide the `Licensing`_ requirements of the project are\n> +detailed.\n> \n> This introduction is followed by a walkthrough tutorial to newcomers wishing to\n> support a new platform with the `Pipeline Handler Writers Guide`_ and for those\n> @@ -41,156 +39,6 @@ provides a tutorial of the key APIs exposed by libcamera.\n> \n> .. TODO: Correctly link to the other articles of the guide\n> \n> -Architecture\n> -------------\n> -\n> -While offering a unified API towards upper layers, and presenting itself as a\n> -single library, libcamera isn't monolithic. It exposes multiple components\n> -through its public API and is built around a set of separate helpers internally.\n> -Hardware abstractions are handled through the use of device-specific components\n> -where required and dynamically loadable plugins are used to separate image\n> -processing algorithms from the core libcamera codebase.\n> -\n> -::\n> -\n> - --------------------------< libcamera Public API >---------------------------\n> - ^ ^\n> - | |\n> - v v\n> - +-------------+ +---------------------------------------------------+\n> - | Camera | | Camera Device |\n> - | Manager | | +-----------------------------------------------+ |\n> - +-------------+ | | Device-Agnostic | |\n> - ^ | | | |\n> - | | | +--------------------------+ |\n> - | | | | ~~~~~~~~~~~~~~~~~~~~~~~ |\n> - | | | | { +-----------------+ } |\n> - | | | | } | //// Image //// | { |\n> - | | | | <-> | / Processing // | } |\n> - | | | | } | / Algorithms // | { |\n> - | | | | { +-----------------+ } |\n> - | | | | ~~~~~~~~~~~~~~~~~~~~~~~ |\n> - | | | | ========================== |\n> - | | | | +-----------------+ |\n> - | | | | | // Pipeline /// | |\n> - | | | | <-> | /// Handler /// | |\n> - | | | | | /////////////// | |\n> - | | +--------------------+ +-----------------+ |\n> - | | Device-Specific |\n> - | +---------------------------------------------------+\n> - | ^ ^\n> - | | |\n> - v v v\n> - +--------------------------------------------------------------------+\n> - | Helpers and Support Classes |\n> - | +-------------+ +-------------+ +-------------+ +-------------+ |\n> - | | MC & V4L2 | | Buffers | | Sandboxing | | Plugins | |\n> - | | Support | | Allocator | | IPC | | Manager | |\n> - | +-------------+ +-------------+ +-------------+ +-------------+ |\n> - | +-------------+ +-------------+ |\n> - | | Pipeline | | ... | |\n> - | | Runner | | | |\n> - | +-------------+ +-------------+ |\n> - +--------------------------------------------------------------------+\n> -\n> - /// Device-Specific Components\n> - ~~~ Sandboxing\n> -\n> -\n> -Camera Manager\n> - The Camera Manager enumerates cameras and instantiates Pipeline Handlers to\n> - manage each Camera that libcamera supports. The Camera Manager supports\n> - hotplug detection and notification events when supported by the underlying\n> - kernel devices.\n> -\n> - There is only ever one instance of the Camera Manager running per application.\n> - Each application's instance of the Camera Manager ensures that only a single\n> - application can take control of a camera device at once.\n> -\n> - Read the `Camera Manager API`_ documentation for more details.\n> -\n> -.. _Camera Manager API: https://libcamera.org/api-html/classlibcamera_1_1CameraManager.html\n> -\n> -Camera Device\n> - The Camera class represents a single item of camera hardware that is capable\n> - of producing one or more image streams, and provides the API to interact with\n> - the underlying device.\n> -\n> - If a system has multiple instances of the same hardware attached, each has its\n> - own instance of the camera class.\n> -\n> - The API exposes full control of the device to upper layers of libcamera through\n> - the public API, making it the highest level object libcamera exposes, and the\n> - object that all other API operations interact with from configuration to\n> - capture.\n> -\n> - Read the `Camera API`_ documentation for more details.\n> -\n> -.. _Camera API: https://libcamera.org/api-html/classlibcamera_1_1Camera.html\n> -\n> -Pipeline Handler\n> - The Pipeline Handler manages the complex pipelines exposed by the kernel\n> - drivers through the Media Controller and V4L2 APIs. It abstracts pipeline\n> - handling to hide device-specific details from the rest of the library, and\n> - implements both pipeline configuration based on stream configuration, and\n> - pipeline runtime execution and scheduling when needed by the device.\n> -\n> - The Pipeline Handler lives in the same process as the rest of the library, and\n> - has access to all helpers and kernel camera-related devices.\n> -\n> - Hardware abstraction is handled by device specific Pipeline Handlers which are\n> - derived from the Pipeline Handler base class allowing commonality to be shared\n> - among the implementations.\n> -\n> - Derived pipeline handlers create Camera device instances based on the devices\n> - they detect and support on the running system, and are responsible for\n> - managing the interactions with a camera device.\n> -\n> - More details can be found in the `PipelineHandler API`_ documentation, and the\n> - `Pipeline Handler Writers Guide`_.\n> -\n> -.. _PipelineHandler API: https://libcamera.org/api-html/classlibcamera_1_1PipelineHandler.html\n> -\n> -Image Processing Algorithms\n> - An image processing algorithm (IPA) component is a loadable plugin that\n> - implements 3A (Auto-Exposure, Auto-White Balance, and Auto-Focus) and other\n> - algorithms.\n> -\n> - The algorithms run on the CPU and interact with the camera devices through the\n> - Pipeline Handler to control hardware image processing based on the parameters\n> - supplied by upper layers, maintaining state and closing the control loop\n> - of the ISP.\n> -\n> - The component is sandboxed and can only interact with libcamera through the\n> - API provided by the Pipeline Handler and an IPA has no direct access to kernel\n> - camera devices.\n> -\n> - Open source IPA modules built with libcamera can be run in the same process\n> - space as libcamera, however external IPA modules are run in a separate process\n> - from the main libcamera process. IPA modules have a restricted view of the\n> - system, including no access to networking APIs and limited access to file\n> - systems.\n> -\n> - IPA modules are only required for platforms and devices with an ISP controlled\n> - by the host CPU. Camera sensors which have an integrated ISP are not\n> - controlled through the IPA module.\n> -\n> -Platform Support\n> -----------------\n> -\n> -The library currently supports the following hardware platforms specifically\n> -with dedicated pipeline handlers:\n> -\n> - - Intel IPU3 (ipu3)\n> - - Rockchip RK3399 (rkisp1)\n> - - RaspberryPi 3 and 4 (rpi/vc4)\n> -\n> -Furthermore, generic platform support is provided for the following:\n> -\n> - - USB video device class cameras (uvcvideo)\n> - - iMX7, Allwinner Sun6i (simple)\n> - - Virtual media controller driver for test use cases (vimc)\n> -\n> Licensing\n> ---------\n> \n> diff --git a/Documentation/libcamera_architecture.rst b/Documentation/libcamera_architecture.rst\n> index 1258db23..abbb0d17 100644\n> --- a/Documentation/libcamera_architecture.rst\n> +++ b/Documentation/libcamera_architecture.rst\n> @@ -5,124 +5,136 @@\n> libcamera Architecture\n> ======================\n> \n> +While offering a unified API towards upper layers, and presenting itself as a\n> +single library, libcamera isn't monolithic. It exposes multiple components\n> +through its public API and is built around a set of separate helpers internally.\n> +Hardware abstractions are handled through the use of device-specific components\n> +where required and dynamically loadable plugins are used to separate image\n> +processing algorithms from the core libcamera codebase.\n> +\n> ::\n> \n> - ---------------------------< libcamera Public API >---------------------------\n> - ^ ^\n> - | |\n> - v v\n> - +-------------+ +-------------------------------------------------+\n> - | Camera | | Camera Device |\n> - | Devices | | +---------------------------------------------+ |\n> - | Manager | | | Device-Agnostic | |\n> - +-------------+ | | | |\n> - ^ | | +------------------------+ |\n> - | | | | ~~~~~~~~~~~~~~~~~~~~~ |\n> - | | | | { +---------------+ } |\n> - | | | | } | ////Image//// | { |\n> - | | | | <-> | /Processing// | } |\n> - | | | | } | /Algorithms// | { |\n> - | | | | { +---------------+ } |\n> - | | | | ~~~~~~~~~~~~~~~~~~~~~ |\n> - | | | | ======================== |\n> - | | | | +---------------+ |\n> - | | | | | //Pipeline/// | |\n> - | | | | <-> | ///Handler/// | |\n> - | | | | | ///////////// | |\n> - | | +--------------------+ +---------------+ |\n> - | | Device-Specific |\n> - | +-------------------------------------------------+\n> - | ^ ^\n> - | | |\n> - v v v\n> - +--------------------------------------------------------------------+\n> - | Helpers and Support Classes |\n> - | +-------------+ +-------------+ +-------------+ +-------------+ |\n> - | | MC & V4L2 | | Buffers | | Sandboxing | | Plugins | |\n> - | | Support | | Allocator | | IPC | | Manager | |\n> - | +-------------+ +-------------+ +-------------+ +-------------+ |\n> - | +-------------+ +-------------+ |\n> - | | Pipeline | | ... | |\n> - | | Runner | | | |\n> - | +-------------+ +-------------+ |\n> - +--------------------------------------------------------------------+\n> -\n> - /// Device-Specific Components\n> - ~~~ Sandboxing\n> -\n> -While offering a unified API towards upper layers, and presenting\n> -itself as a single library, libcamera isn't monolithic. It exposes\n> -multiple components through its public API, is built around a set of\n> -separate helpers internally, uses device-specific components and can\n> -load dynamic plugins.\n> -\n> -Camera Devices Manager\n> - The Camera Devices Manager provides a view of available cameras\n> - in the system. It performs cold enumeration and runtime camera\n> - management, and supports a hotplug notification mechanism in its\n> - public API.\n> -\n> - To avoid the cost associated with cold enumeration of all devices\n> - at application start, and to arbitrate concurrent access to camera\n> - devices, the Camera Devices Manager could later be split to a\n> - separate service, possibly with integration in platform-specific\n> - device management.\n> + --------------------------< libcamera Public API >---------------------------\n> + ^ ^\n> + | |\n> + v v\n> + +-------------+ +---------------------------------------------------+\n> + | Camera | | Camera Device |\n> + | Manager | | +-----------------------------------------------+ |\n> + +-------------+ | | Device-Agnostic | |\n> + ^ | | | |\n> + | | | +--------------------------+ |\n> + | | | | ~~~~~~~~~~~~~~~~~~~~~~~ |\n> + | | | | { +-----------------+ } |\n> + | | | | } | //// Image //// | { |\n> + | | | | <-> | / Processing // | } |\n> + | | | | } | / Algorithms // | { |\n> + | | | | { +-----------------+ } |\n> + | | | | ~~~~~~~~~~~~~~~~~~~~~~~ |\n> + | | | | ========================== |\n> + | | | | +-----------------+ |\n> + | | | | | // Pipeline /// | |\n> + | | | | <-> | /// Handler /// | |\n> + | | | | | /////////////// | |\n> + | | +--------------------+ +-----------------+ |\n> + | | Device-Specific |\n> + | +---------------------------------------------------+\n> + | ^ ^\n> + | | |\n> + v v v\n> + +--------------------------------------------------------------------+\n> + | Helpers and Support Classes |\n> + | +-------------+ +-------------+ +-------------+ +-------------+ |\n> + | | MC & V4L2 | | Buffers | | Sandboxing | | Plugins | |\n> + | | Support | | Allocator | | IPC | | Manager | |\n> + | +-------------+ +-------------+ +-------------+ +-------------+ |\n> + | +-------------+ +-------------+ |\n> + | | Pipeline | | ... | |\n> + | | Runner | | | |\n> + | +-------------+ +-------------+ |\n> + +--------------------------------------------------------------------+\n> +\n> + /// Device-Specific Components\n> + ~~~ Sandboxing\n> +\n> +\n> +Camera Manager\n> + The Camera Manager enumerates cameras and instantiates Pipeline Handlers to\n> + manage each Camera that libcamera supports. The Camera Manager supports\n> + hotplug detection and notification events when supported by the underlying\n> + kernel devices.\n> +\n> + There is only ever one instance of the Camera Manager running per application.\n> + Each application's instance of the Camera Manager ensures that only a single\n> + application can take control of a camera device at once.\n> +\n> + Read the `Camera Manager API`_ documentation for more details.\n> +\n> +.. _Camera Manager API: https://libcamera.org/api-html/classlibcamera_1_1CameraManager.html\n> \n> Camera Device\n> - The Camera Device represents a camera device to upper layers. It\n> - exposes full control of the device through the public API, and is\n> - thus the highest level object exposed by libcamera.\n> + The Camera class represents a single item of camera hardware that is capable\n> + of producing one or more image streams, and provides the API to interact with\n> + the underlying device.\n> +\n> + If a system has multiple instances of the same hardware attached, each has its\n> + own instance of the camera class.\n> +\n> + The API exposes full control of the device to upper layers of libcamera through\n> + the public API, making it the highest level object libcamera exposes, and the\n> + object that all other API operations interact with from configuration to\n> + capture.\n> +\n> + Read the `Camera API`_ documentation for more details.\n> \n> - Camera Device instances are created by the Camera Devices\n> - Manager. An optional function to create new instances could be exposed\n> - through the public API to speed up initialization when the upper\n> - layer knows how to directly address camera devices present in the\n> - system.\n> +.. _Camera API: https://libcamera.org/api-html/classlibcamera_1_1Camera.html\n> \n> Pipeline Handler\n> - The Pipeline Handler manages complex pipelines exposed by the kernel drivers\n> - through the Media Controller and V4L2 APIs. It abstracts pipeline handling to\n> - hide device-specific details to the rest of the library, and implements both\n> - pipeline configuration based on stream configuration, and pipeline runtime\n> - execution and scheduling when needed by the device.\n> -\n> - This component is device-specific and is part of the libcamera code base. As\n> - such it is covered by the same free software license as the rest of libcamera\n> - and needs to be contributed upstream by device vendors. The Pipeline Handler\n> - lives in the same process as the rest of the library, and has access to all\n> - helpers and kernel camera-related devices.\n> + The Pipeline Handler manages the complex pipelines exposed by the kernel\n> + drivers through the Media Controller and V4L2 APIs. It abstracts pipeline\n> + handling to hide device-specific details from the rest of the library, and\n> + implements both pipeline configuration based on stream configuration, and\n> + pipeline runtime execution and scheduling when needed by the device.\n> +\n> + The Pipeline Handler lives in the same process as the rest of the library, and\n> + has access to all helpers and kernel camera-related devices.\n> +\n> + Hardware abstraction is handled by device specific Pipeline Handlers which are\n> + derived from the Pipeline Handler base class allowing commonality to be shared\n> + among the implementations.\n> +\n> + Derived pipeline handlers create Camera device instances based on the devices\n> + they detect and support on the running system, and are responsible for\n> + managing the interactions with a camera device.\n> +\n> + More details can be found in the `PipelineHandler API`_ documentation, and the\n> + :doc:`Pipeline Handler Writers Guide `.\n> +\n> +.. _PipelineHandler API: https://libcamera.org/api-html/classlibcamera_1_1PipelineHandler.html\n> \n> Image Processing Algorithms\n> Together with the hardware image processing and hardware statistics\n> - collection, the Image Processing Algorithms implement 3A (Auto-Exposure,\n> + collection, the Image Processing Algorithms (IPA) implement 3A (Auto-Exposure,\n> Auto-White Balance and Auto-Focus) and other algorithms. They run on the CPU\n> - and interact with the kernel camera devices to control hardware image\n> - processing based on the parameters supplied by upper layers, closing the\n> - control loop of the ISP.\n> -\n> - This component is device-specific and is loaded as an external plugin. It can\n> - be part of the libcamera code base, in which case it is covered by the same\n> - license, or provided externally as an open-source or closed-source component.\n> -\n> - The component is sandboxed and can only interact with libcamera through\n> - internal APIs specifically marked as such. In particular it will have no\n> - direct access to kernel camera devices, and all its accesses to image and\n> - metadata will be mediated by dmabuf instances explicitly passed to the\n> - component. The component must be prepared to run in a process separate from\n> - the main libcamera process, and to have a very restricted view of the system,\n> - including no access to networking APIs and limited access to file systems.\n> -\n> - The sandboxing mechanism isn't defined by libcamera. One example\n> - implementation will be provided as part of the project, and platforms vendors\n> - will be able to provide their own sandboxing mechanism as a plugin.\n> -\n> - libcamera should provide a basic implementation of Image Processing\n> - Algorithms, to serve as a reference for the internal API. Device vendors are\n> - expected to provide a full-fledged implementation compatible with their\n> - Pipeline Handler. One goal of the libcamera project is to create an\n> - environment in which the community will be able to compete with the\n> - closed-source vendor binaries and develop a high quality open source\n> - implementation.\n> + and control hardware image processing based on the parameters supplied by\n> + upper layers, closing the control loop of the ISP.\n> +\n> + IPAs are loaded as external plugins named IPA Modules. IPA Modules can be part\n> + of the libcamera code base or provided externally by camera vendors as\n> + open-source or closed-source components.\n> +\n> + Open source IPA Modules built with libcamera are run in the same process space\n> + as libcamera. External IPA Modules are run in a separate sandboxed process. In\n> + either case, they can only interact with libcamera through the API provided by\n> + the Pipeline Handler. They have a restricted view of the system, with no direct\n> + access to kernel camera devices, no access to networking APIs, and limited\n> + access to file systems. All their accesses to image and metadata are mediated\n> + by dmabuf instances explicitly passed by the Pipeline Handler to the IPA\n> + Module.\n> +\n> + IPA Modules are only required for platforms and devices with an ISP controlled\n> + by the host CPU. Camera sensors which have an integrated ISP are not\n> + controlled through the IPA Module.\n> \n> Helpers and Support Classes\n> While Pipeline Handlers are device-specific, implementations are expected to\n> @@ -136,3 +148,21 @@ Helpers and Support Classes\n> self-contained support classes, even if such code is present only once in the\n> code base, in order to keep the source code clean and easy to read. This\n> should be the case for instance for plugin management.\n> +\n> +Platform Support\n> +----------------\n> +\n> +The library currently supports the following hardware platforms specifically\n> +with dedicated pipeline handlers:\n> +\n> + - Arm Mali-C55\n> + - Intel IPU3 (ipu3)\n> + - NXP i.MX8MP (imx8-isi and rkisp1)\n> + - RaspberryPi 3, 4 and zero (rpi/vc4)\n> + - Rockchip RK3399 (rkisp1)\n> +\n> +Furthermore, generic platform support is provided for the following:\n> +\n> + - USB video device class cameras (uvcvideo)\n> + - iMX7, IPU6, Allwinner Sun6i (simple)\n> + - Virtual media controller driver for test use cases (vimc)","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 EBA12BDB13\n\tfor ;\n\tTue, 20 Aug 2024 16:37:47 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id CBD45633CE;\n\tTue, 20 Aug 2024 18:37:46 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 23129633B2\n\tfor ;\n\tTue, 20 Aug 2024 18:37:45 +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 8A6D8541;\n\tTue, 20 Aug 2024 18:36:42 +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=\"iiSZF5uj\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1724171803;\n\tbh=ULxyETzfkz7ZrmCFsyGC8M6yqpCB02vrdLX68qmSDig=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=iiSZF5ujdGfOz322kTrhL4UsgoRXX3ghZiCmzcggdLgB+8S4mRVHD4dmsR9IvGdkj\n\ttqmxbWJjPigZ6ByIQLb9X468Lblcu3h9UzlMKTIPAx4jf0H8FmvzXgYb9JhhH9Irr0\n\ttY3opoTS60N/mkaCW/VegHaxPzN/IxXsX+TQQdw4=","Date":"Tue, 20 Aug 2024 19:37:42 +0300","From":"Laurent Pinchart ","To":"Daniel Scally ","Cc":"libcamera-devel@lists.libcamera.org","Subject":"Re: [PATCH v4 5/9] Documentation: Remove libcamera architecture from\n\tintroduction.rst","Message-ID":"<20240820163742.GD7478@pendragon.ideasonboard.com>","References":"<20240820130740.568243-1-dan.scally@ideasonboard.com>\n\t<20240820130740.568243-6-dan.scally@ideasonboard.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20240820130740.568243-6-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\" "}}]