[libcamera-devel] [PATCH v2 10/11] Documentation: guides: pipeline-handler: Migrate to Camera::Private
Jacopo Mondi
jacopo at jmondi.org
Tue Aug 10 15:59:31 CEST 2021
Hi Laurent,
On Thu, Aug 05, 2021 at 08:58:47PM +0300, Laurent Pinchart wrote:
> Update the pipeline handler guide following the migration from the
> CameraData class to the Camera::Private class.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Reviewed-by: Niklas Söderlund <niklas.soderlund at ragnatech.se>
> ---
> Documentation/guides/pipeline-handler.rst | 67 ++++++++++++-----------
> 1 file changed, 34 insertions(+), 33 deletions(-)
>
> diff --git a/Documentation/guides/pipeline-handler.rst b/Documentation/guides/pipeline-handler.rst
> index 152776935a33..7e9ff824dd50 100644
> --- a/Documentation/guides/pipeline-handler.rst
> +++ b/Documentation/guides/pipeline-handler.rst
> @@ -106,7 +106,7 @@ functionalities descibed above. Below is a brief overview of each of those:
> Abstracts camera sensor handling by hiding the details of the V4L2 subdevice
> kernel API and caching sensor information.
>
> -- `CameraData <http://libcamera.org/api-html/classlibcamera_1_1CameraData.html>`_:
> +- `Camera::Private <http://libcamera.org/api-html/classlibcamera_1_1Camera_1_1Private.html>`_:
> Represents device-specific data a pipeline handler associates to each Camera
> instance.
>
> @@ -416,26 +416,26 @@ receivers port output.
> The Pipeline Handler is responsible for defining the set of Streams associated
> with the Camera.
>
> -Each Camera has instance-specific data represented using the `CameraData`_
> +Each Camera has instance-specific data represented using the `Camera::Private`_
> class, which can be extended for the specific needs of the pipeline handler.
>
> -.. _CameraData: http://libcamera.org/api-html/classlibcamera_1_1CameraData.html
> +.. _Camera::Private: http://libcamera.org/api-html/classlibcamera_1_1Camera_1_1Private.html
>
>
> -To support the Camera we will later register, we need to create a CameraData
> +To support the Camera we will later register, we need to create a Camera::Private
> class that we can implement for our specific Pipeline Handler.
>
> -Define a new ``VividCameraData()`` class derived from ``CameraData`` by adding
> -the following code before the PipelineHandlerVivid class definition where it
> -will be used:
> +Define a new ``VividCameraPrivate()`` class derived from ``Camera::Private`` by
> +adding the following code before the PipelineHandlerVivid class definition where
> +it will be used:
>
> .. code-block:: cpp
>
> - class VividCameraData : public CameraData
> + class VividCameraData : public Camera::Private
> {
> public:
> VividCameraData(PipelineHandler *pipe, MediaDevice *media)
> - : CameraData(pipe), media_(media), video_(nullptr)
> + : Camera::Private(pipe), media_(media), video_(nullptr)
> {
> }
>
> @@ -457,17 +457,17 @@ single stream, represented by the ``VividCameraData`` class members. More
> complex pipeline handlers might register cameras composed of several video
> devices and sub-devices, or multiple streams per camera that represent the
> several components of the image capture pipeline. You should represent all these
> -components in the ``CameraData`` derived class when developing a custom
> +components in the ``Camera::Private`` derived class when developing a custom
> PipelineHandler.
>
> In our example VividCameraData we implement an ``init()`` function to prepare
> -the object from our PipelineHandler, however the CameraData class does not
> +the object from our PipelineHandler, however the Camera::Private class does not
> specify the interface for initialisation and PipelineHandlers can manage this
> -based on their own needs. Derived CameraData classes are used only by their
> +based on their own needs. Derived Camera::Private classes are used only by their
> respective pipeline handlers.
>
> -The CameraData class stores the context required for each camera instance and
> -is usually responsible for opening all Devices used in the capture pipeline.
> +The Camera::Private class stores the context required for each camera instance
> +and is usually responsible for opening all Devices used in the capture pipeline.
>
> We can now implement the ``init`` method for our example Pipeline Handler to
> create a new V4L2 video device from the media entity, which we can specify using
> @@ -488,11 +488,11 @@ capture device named 'vivid-000-vid-cap' by the device.
> return 0;
> }
>
> -The CameraData should be created and initialised before we move on to register a
> -new Camera device so we need to construct and initialise our
> +The VividCameraData should be created and initialised before we move on to
> +register a new Camera device so we need to construct and initialise our
> VividCameraData after we have identified our device within
> PipelineHandlerVivid::match(). The VividCameraData is wrapped by a
> -std::unique_ptr to help manage the lifetime of our CameraData instance.
> +std::unique_ptr to help manage the lifetime of the instance.
If the ownership is not transfered, this is really an implementation
detail of each pipeline's match() implementation
>
> If the camera data initialization fails, return ``false`` to indicate the
> failure to the ``match()`` method and prevent retrying of the pipeline handler.
> @@ -508,9 +508,9 @@ failure to the ``match()`` method and prevent retrying of the pipeline handler.
> Once the camera data has been initialized, the Camera device instances and the
> associated streams have to be registered. Create a set of streams for the
> camera, which for this device is only one. You create a camera using the static
> -`Camera::create`_ method, passing the pipeline handler, the id of the camera,
> -and the streams available. Then register the camera and its data with the
> -pipeline handler and camera manager using `registerCamera`_.
> +`Camera::create`_ method, passing the Camera::Private instance, the id of the
> +camera, and the streams available. Then register the camera with the pipeline
> +handler and camera manager using `registerCamera`_.
>
> Finally with a successful construction, we return 'true' indicating that the
> PipelineHandler successfully matched and constructed a device.
> @@ -548,23 +548,24 @@ Our match function should now look like the following:
>
> /* Create and register the camera. */
> std::set<Stream *> streams{ &data->stream_ };
> - std::shared_ptr<Camera> camera = Camera::create(this, data->video_->deviceName(), streams);
> - registerCamera(std::move(camera), std::move(data));
> + const std::string &id = data->video_->deviceName();
^ weird spacing
> + std::shared_ptr<Camera> camera = Camera::create(data.release(), id, streams);
> + registerCamera(std::move(camera));
>
> return true;
> }
>
> -We will need to use our custom CameraData class frequently throughout the
> +We will need to use our custom VividCameraData class frequently throughout the
> pipeline handler, so we add a private convenience helper to our Pipeline handler
> -to obtain and cast the custom CameraData instance from a Camera instance.
> +to obtain and cast the custom VividCameraData instance from a Camera::Private
> +instance.
>
> .. code-block:: cpp
>
> private:
> - VividCameraData *cameraData(const Camera *camera)
> + VividCameraData *cameraData(Camera *camera)
> {
> - return static_cast<VividCameraData *>(
> - PipelineHandler::cameraData(camera));
> + return static_cast<VividCameraData *>(camera->_d());
> }
>
> At this point, you need to add the following new includes to provide the Camera
> @@ -594,12 +595,12 @@ are defined by src/libcamera/`properties_ids.yaml`_.
>
> Pipeline handlers can optionally register the list of controls an application
> can set as well as a list of immutable camera properties. Being both
> -Camera-specific values, they are represented in the ``CameraData`` base class,
> -which provides two members for this purpose: the `CameraData::controlInfo_`_ and
> -the `CameraData::properties_`_ fields.
> +Camera-specific values, they are represented in the ``Camera::Private`` base
> +class, which provides two members for this purpose: the
> +`Camera::Private::controlInfo_`_ and the `Camera::Private::properties_`_ fields.
>
> -.. _CameraData::controlInfo_: http://libcamera.org/api-html/classlibcamera_1_1CameraData.html#ab9fecd05c655df6084a2233872144a52
> -.. _CameraData::properties_: http://libcamera.org/api-html/classlibcamera_1_1CameraData.html#a84002c29f45bd35566c172bb65e7ec0b
> +.. _Camera::Private::controlInfo_: http://libcamera.org/api-html/classlibcamera_1_1Camera_1_1Private.html#ab4e183eb4dabe929d1b2bbbb519b969f
> +.. _Camera::Private::properties_: http://libcamera.org/api-html/classlibcamera_1_1Camera_1_1Private.html#ad31f12f5ed9c1fbe25750902f4791064
>
> The ``controlInfo_`` field represents a map of ``ControlId`` instances
> associated with the limits of valid values supported for the control. More
> @@ -617,7 +618,7 @@ Complete the initialization of the ``VividCameraData`` class by adding the
> following code to the ``VividCameraData::init()`` method to initialise the
> controls. For more complex control configurations, this could of course be
> broken out to a separate function, but for now we just initialise the small set
> -inline in our CameraData init:
> +inline in our VividCameraData init:
The rest looks ok
Reviewed-by: Jacopo Mondi <jacopo at jmondi.org>
Thanks
j
>
> .. code-block:: cpp
>
> --
> Regards,
>
> Laurent Pinchart
>
More information about the libcamera-devel
mailing list