From patchwork Fri Dec 6 16:07:42 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jacopo Mondi X-Patchwork-Id: 22230 Return-Path: X-Original-To: parsemail@patchwork.libcamera.org Delivered-To: parsemail@patchwork.libcamera.org Received: from lancelot.ideasonboard.com (lancelot.ideasonboard.com [92.243.16.209]) by patchwork.libcamera.org (Postfix) with ESMTPS id 4DD8ABE173 for ; Fri, 6 Dec 2024 16:08:07 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id 323BB67E30; Fri, 6 Dec 2024 17:08:01 +0100 (CET) Authentication-Results: lancelot.ideasonboard.com; dkim=pass (1024-bit key; unprotected) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="NnkUB2s0"; dkim-atps=neutral Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 5CF2C67E1C for ; Fri, 6 Dec 2024 17:07:56 +0100 (CET) Received: from ideasonboard.com (93-61-96-190.ip145.fastwebnet.it [93.61.96.190]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id ADC009FC; Fri, 6 Dec 2024 17:07:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1733501246; bh=7Y0HjASJaq70ru03BO0gmDiDRiK9/i3qxwgjLsFrHJk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NnkUB2s0WQ9UyH0XwXbZMRZEbLNAhE4hBIKfOnGT9BiMpTCfr5d4HeSrgtPQChjfX UpLRvn26w9sh+JGuopyDIpoiS6nkUt6r2498BuhAwt3SuHgD/v6G2TkN65zC66euH+ 35VWkKTKcLckYWGTTDNCOvDL73pcN86NGPBH3ozg= From: Jacopo Mondi To: libcamera-devel@lists.libcamera.org Cc: Jacopo Mondi , Harvey Yang , Han-Lin Chen Subject: [PATCH 4/8] guides: pipeline_handler: Document PipelineHandler::metadataAvailable Date: Fri, 6 Dec 2024 17:07:42 +0100 Message-ID: <20241206160747.97176-5-jacopo.mondi@ideasonboard.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241206160747.97176-1-jacopo.mondi@ideasonboard.com> References: <20241206160747.97176-1-jacopo.mondi@ideasonboard.com> MIME-Version: 1.0 X-BeenThere: libcamera-devel@lists.libcamera.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libcamera-devel-bounces@lists.libcamera.org Sender: "libcamera-devel" Document the new available helpers to accumulate metadata results in Request::metadata and notify applications about metadata availability. Signed-off-by: Jacopo Mondi --- Documentation/guides/pipeline-handler.rst | 26 ++++++++++++++++------- 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/Documentation/guides/pipeline-handler.rst b/Documentation/guides/pipeline-handler.rst index 69e832a5587e..5a1b402fcc62 100644 --- a/Documentation/guides/pipeline-handler.rst +++ b/Documentation/guides/pipeline-handler.rst @@ -1431,18 +1431,28 @@ classes documentation. .. _libcamera Signal and Slot: https://libcamera.org/api-html/classlibcamera_1_1Signal.html#details In order to notify applications about the availability of new frames and data, -the ``Camera`` device exposes two ``Signals`` to which applications can connect -to be notified of frame completion events. The ``bufferComplete`` signal serves -to report to applications the completion event of a single ``Stream`` part of a -``Request``, while the ``requestComplete`` signal notifies the completion of all -the ``Streams`` and data submitted as part of a request. This mechanism allows +the ``Camera`` device exposes three ``Signals`` to which applications can +connect to be notified of frame completion and metadata availability events. + +The ``metadataAvailable`` signal serves to notify about the availability of +metadata and accumulates metadata results in the list of metadata associated +with a ``Request``. The ``bufferComplete`` signal serves to report to +applications the completion event of a single ``Stream`` part of a ``Request``, +while the ``requestComplete`` signal notifies the completion of all the +``Streams`` and data submitted as part of a request. This mechanism allows implementation of partial request completion, which allows an application to inspect completed buffers associated with the single streams without waiting for all of them to be ready. -The ``bufferComplete`` and ``requestComplete`` signals are emitted by the -``Camera`` device upon notifications received from the pipeline handler, which -tracks the buffers and request completion status. +The ``metadataAvailable``, ``bufferComplete`` and ``requestComplete`` signals +are emitted by the ``Camera`` device upon notifications received from the +pipeline handler, which tracks the metadata, buffers and request completion +status. + +Metadata availability is signalled by the pipeline handlers by calling the +PipelineHandler base class ``metadataAvailable`` function. This function +notifies applications about metadata availability and accumulates metadata +results in the ``Request::metadata()`` list. The single buffer completion notification is implemented by pipeline handlers by `connecting`_ the ``bufferReady`` signal of the capture devices they have queued