[PATCH v2 6/7] Documentation: Expand introductory content on docs.rst
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Mon Aug 19 01:01:22 CEST 2024
Hi Dan,
Thank you for the patch.
On Thu, Aug 15, 2024 at 09:29:43AM +0100, Daniel Scally wrote:
> docs.rst is the landing page for the documentation from the libcamera
> website, but isn't particularly introductory. Move much of the content
> from guides/introduction.rst to docs.rst, which will serve as the new
> introductory page. Remove guides/introduction.rst.
>
> Signed-off-by: Daniel Scally <dan.scally at ideasonboard.com>
> ---
> Changes since v1:
>
> - Removed deleted file from meson's docs_sources array.
>
> Documentation/c55.svg | 175 +++++++++++++++++++++++
> Documentation/docs.rst | 128 ++++++++++++++++-
> Documentation/documentation-contents.rst | 1 -
> Documentation/guides/introduction.rst | 78 ----------
> Documentation/index.rst | 1 -
> Documentation/meson.build | 1 -
> 6 files changed, 296 insertions(+), 88 deletions(-)
> create mode 100644 Documentation/c55.svg
> delete mode 100644 Documentation/guides/introduction.rst
>
> diff --git a/Documentation/c55.svg b/Documentation/c55.svg
> new file mode 100644
> index 00000000..9dbd52bb
> --- /dev/null
> +++ b/Documentation/c55.svg
> @@ -0,0 +1,175 @@
> +<?xml version="1.0" encoding="UTF-8" standalone="no"?>
> +<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
> + "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
> +<!-- Generated by graphviz version 2.43.0 (0)
> + -->
Sphinx has a graphviz extension. I've tested it locally and it works
quite nicely, with the following diff:
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 325f27591cfb..1f087c14e744 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -37,8 +37,11 @@ author = u'Kieran Bingham, Jacopo Mondi, Laurent Pinchart, Niklas Söderlund'
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = [
+ 'sphinx.ext.graphviz',
]
+graphviz_output_format = 'svg'
+
# Add any paths that contain templates here, relative to this directory.
templates_path = []
diff --git a/Documentation/docs.rst b/Documentation/docs.rst
index c495fa61e40e..1cf2f4d6c744 100644
--- a/Documentation/docs.rst
+++ b/Documentation/docs.rst
@@ -58,7 +58,7 @@ desirable results from the camera through the kernel's APIs, reducing those
operations to a simple and consistent method for developers. In short instead of
having to deal with this:
-.. figure:: c55.svg
+.. graphviz:: mali-c55.dot
You can instead simply deal with this::
diff --git a/Documentation/meson.build b/Documentation/meson.build
index 1c982ba6f862..c8433f33c0a4 100644
--- a/Documentation/meson.build
+++ b/Documentation/meson.build
@@ -139,6 +139,7 @@ if sphinx.found()
'guides/tracing.rst',
'index.rst',
'lens_driver_requirements.rst',
+ 'mali-c55.dot',
'python-bindings.rst',
'sensor_driver_requirements.rst',
'software-isp-benchmarking.rst',
(and c55.svg replaced with mali-c55.dot).
Adding the .dot file to the docs_sources isn't a requirement specific to
.dot input files, the .svg should have been added there too.
The sphinx extension is part of the base sphinx package on Debian, so
using it should be fine.
[snip]
> diff --git a/Documentation/docs.rst b/Documentation/docs.rst
> index d65b2b4f..c495fa61 100644
> --- a/Documentation/docs.rst
> +++ b/Documentation/docs.rst
> @@ -14,12 +14,87 @@ Documentation
>
> API <api-html/index>
>
> -API
> -===
> +What is libcamera exactly?
I would drop "exactly".
> +==========================
> +
> +libcamera is an open source complex camera support library for Linux. The
To match the Doxygen documentation, the README.rst file and the website,
you should write "for Linux, Android and ChromeOS".
> +library interfaces with Linux kernel uAPIs implemented by device drivers and
I'd write "with Linux kernel device drivers"
> +provides an intuitive API to developers in order to simplify the complexity
> +involved in capturing images from complex cameras on Linux systems.
> +
> +What's a "complex camera"?
"What is"
> +==========================
> +
> +A modern "camera" tends to infact be several different pieces of hardware which
> +must all be controlled together in order to capture images. For example the
> +pipeline might consist of a camera sensor which actually records the data, a
> +receiver which accepts those data transmitted from the camera sensor and an
> +image signal processor which processes those data into a useful image in an
> +accepted format.
I like the storyline here, but I think I would make this paragraph a bit
clearer:
A modern "camera" tends to infact be several different pieces of hardware which
must all be controlled together in order to produce and capture images of
appropriate quality. A hardware pipeline typically consists of a camera sensor
that captures raw frames and transmits them on a bus, a receiver that decodes
the bus signals, and an image signal processor that processes raw frames to
produce usable images in a standard format.
> The Linux kernel handles these multimedia devices through the
> +'Linux media' subsystem and provides a set of APIs (application programming
s/APIs (/
> +interfaces) known collectively as V4L2 (`Video for Linux 2`_) and the
> +`Media Controller`_ API which provide an interface to interact and control media
s/API/APIs/
(to avoid repeating "API").
> +devices.
> +
> +.. _Video for Linux 2: https://www.linuxtv.org/downloads/v4l-dvb-apis-new/userspace-api/v4l/v4l2.html
> +.. _Media Controller: https://www.linuxtv.org/downloads/v4l-dvb-apis-new/userspace-api/mediactl/media-controller.html
> +
> +Included in this subsystem are drivers for camera sensors, CSI2 (Camera
> +Serial Interface) receivers, and ISPs (Image Signal Processors)
s/$/./
> +
> +The usage of these drivers to provide a functioning camera stack is a
> +responsibility that lies in userspace which is commonly implemented separately
> +by vendors without a common architecture or API for application developers. This
> +adds a lot of complexity to the task, particularly when considering that the
> +differences in hardware pipelines and their representation in the kernel's APIs
> +often necessitates bespoke handling.
s/necessitates/necessitate/ if the subject is differences.
> +
> +What is libcamera for?
> +======================
>
> -The libcamera API is extensively documented using Doxygen. The :ref:`API
> -nightly build <api>` contains the most up-to-date API documentation, built from
> -the latest master branch.
> +libcamera provides a complete camera stack for Linux based systems to abstract
s/Linux based/Linux-based/
> +the configuration of hardware and image control algorithms required to obtain
> +desirable results from the camera through the kernel's APIs, reducing those
> +operations to a simple and consistent method for developers. In short instead of
> +having to deal with this:
> +
> +.. figure:: c55.svg
> +
> +You can instead simply deal with this::
> +
Let's get syntax highlighting:
You can instead simply deal with this:
.. code-block:: python
> + >>> import libcamera as lc
> + >>> camera_manager = lc.CameraManager.singleton()
> + [0:15:59.582029920] [504] INFO Camera camera_manager.cpp:313 libcamera v0.3.0+182-01e57380
> + >>> for camera in camera_manager.cameras:
> + ... print(f' - {camera.id}')
> + ...
> + - mali-c55 tpg
> + - imx415 1-001a
> +
> +And the library handles the rest for you. These documentary pages give more
> +information on the internal workings of libcamera (and the kernel camera stack
> +that lies behind it) as well as guidance on using libcamera in an application or
> +extending the library with support for your hardware (through the pipeline
> +handler and IPA module writer's guides).
> +
> +How should I use it?
> +====================
> +
> +There are a few ways you might want to use libcamera, depending on your
> +application. It's always possible to use the library directly of course, and you
> +can find detailed information on how to do so in the
> +:doc:`application writer's guide <guides/application-developer>`. It may be more
> +appropriate to use one of the frameworks with libcamera support. For example an
> +application powering an embedded media device incorporating capture, encoding
> +and streaming of both video and audio might benefit from using `gstreamer`_ (for
s/gstreamer/GStreamer/
s/ (/, /
> +which libcamera provides a plugin). Similarly an application for user-facing
s/)//
> +devices like a laptop would likely benefit accessing cameras through the XDG
> +camera portal and `pipewire`_, which brings the advantages of resource sharing
> +(multiple applications accessing the stream at the same time) and access
> +control.
Should you mention the Android camera HAL and V4L2 compatibility layer
here ?
> +
> +.. _gstreamer: https://gstreamer.freedesktop.org/
> +.. _pipewire: https://pipewire.org/
So far I think it's a nice introduction, but I believe the rest belongs
to a different page. Actually it depends on what audience we target the
main page for. The two main options I can think of are libcamera users
(I put applications developers and system integrators in this category
for now), and libcamera developers. I'm leaning towards the former, in
which case I think it would make sense to move the contents of the
camera_stack.rst page here, and move the internal architecture to a separate
page.
>
> libcamera Architecture
> ======================
> @@ -177,7 +252,7 @@ Helpers and Support Classes
>
>
> V4L2 Compatibility Layer
> -------------------------
> +========================
>
> V4L2 compatibility is achieved through a shared library that traps all
> accesses to camera devices and routes them to libcamera to emulate high-level
> @@ -190,7 +265,7 @@ designed for video conferencing.
>
>
> Android Camera HAL
> -------------------
> +==================
>
> Camera support for Android is achieved through a generic Android
> camera HAL implementation on top of libcamera. The HAL will implement internally
> @@ -200,3 +275,42 @@ support.
> The Android camera HAL implementation will initially target the
> LIMITED hardware level, with support for the FULL level then being gradually
> implemented.
The description of the compat layers duplicates the text in
camera_stack.rst. Moving the whole stack description here will fix that.
> +
> +Platform Support
> +================
> +
> +The library currently supports the following hardware platforms specifically
> +with dedicated pipeline handlers:
> +
> + - Arm Mali-C55 (mali-c55)
I think you can use a single space after the '-'.
> + - Intel IPU3 (ipu3)
- NXP i.MX8MP (imx8-isi and rkisp1)
> + - Rockchip RK3399 (rkisp1)
> + - RaspberryPi 3 and 4 (rpi/vc4)
- Raspberry Pi 3, 4 and zero (rpi/vc4)
> +
> +Furthermore, generic platform support is provided for the following:
> +
> + - USB video device class cameras (uvcvideo)
> + - iMX7, Allwinner Sun6i (simple)
IPU6 works too. There are also other platforms supported by the simple
pipeline handler.
If we move the architecture to a separate document, there will be no
mention of pipeline handlers here anymore. This text could be reworked
to list platforms from a user point of view, maybe based on the level of
support they have (with ISP, with software ISP, without ISP, ...).
You're mainly moving contents here, so this could be done in a separate
patch.
> + - Virtual media controller driver for test use cases (vimc)
> +
> +Licensing
> +=========
> +
> +The libcamera core, is covered by the `LGPL-2.1-or-later`_ license. Pipeline
> +Handlers are a part of the libcamera code base and need to be contributed
> +upstream by device vendors. IPA modules included in libcamera are covered by a
> +free software license, however third-parties may develop IPA modules outside of
> +libcamera and distribute them under a closed-source license, provided they do
> +not include source code from the libcamera project.
> +
> +The libcamera project itself contains multiple libraries, applications and
> +utilities. Licenses are expressed through SPDX tags in text-based files that
> +support comments, and through the .reuse/dep5 file otherwise. A copy of all
> +licenses are stored in the LICENSES directory, and a full summary of the
> +licensing used throughout the project can be found in the COPYING.rst document.
> +
> +Applications which link dynamically against libcamera and use only the public
> +API are an independent work of the authors and have no license restrictions
> +imposed upon them from libcamera.
> +
> +.. _LGPL-2.1-or-later: https://spdx.org/licenses/LGPL-2.1-or-later.html
This section feels a bit out-of-place, but I don't have a better
suggestion for now.
> diff --git a/Documentation/documentation-contents.rst b/Documentation/documentation-contents.rst
> index 613366d1..d978b704 100644
> --- a/Documentation/documentation-contents.rst
> +++ b/Documentation/documentation-contents.rst
> @@ -10,7 +10,6 @@
> * :doc:`/environment_variables`
> * :doc:`/feature_requirements`
> * :doc:`/guides/application-developer`
> - * :doc:`/guides/introduction`
I would also rename docs.rst to introduction.rst now that it has become
an introduction.
> * :doc:`/guides/ipa`
> * :doc:`/guides/pipeline-handler`
> * :doc:`/guides/tracing`
> diff --git a/Documentation/guides/introduction.rst b/Documentation/guides/introduction.rst
> deleted file mode 100644
> index e419eb9d..00000000
> --- a/Documentation/guides/introduction.rst
> +++ /dev/null
> @@ -1,78 +0,0 @@
> -.. SPDX-License-Identifier: CC-BY-SA-4.0
> -
> -.. include:: ../documentation-contents.rst
> -
> -Developers guide to libcamera
> -=============================
> -
> -The Linux kernel handles multimedia devices through the 'Linux media' subsystem
> -and provides a set of APIs (application programming interfaces) known
> -collectively as V4L2 (`Video for Linux 2`_) and the `Media Controller`_ API
> -which provide an interface to interact and control media devices.
> -
> -Included in this subsystem are drivers for camera sensors, CSI2 (Camera
> -Serial Interface) receivers, and ISPs (Image Signal Processors)
> -
> -The usage of these drivers to provide a functioning camera stack is a
> -responsibility that lies in userspace which is commonly implemented separately
> -by vendors without a common architecture or API for application developers.
> -
> -libcamera provides a complete camera stack for Linux based systems to abstract
> -functionality desired by camera application developers and process the
> -configuration of hardware and image control algorithms required to obtain
> -desirable results from the camera.
> -
> -.. _Video for Linux 2: https://www.linuxtv.org/downloads/v4l-dvb-apis-new/userspace-api/v4l/v4l2.html
> -.. _Media Controller: https://www.linuxtv.org/downloads/v4l-dvb-apis-new/userspace-api/mediactl/media-controller.html
> -
> -
> -In this developers guide the current `Platform Support`_ is detailed, as well as
> -an overview of the `Licensing`_ requirements of the project.
> -
> -This introduction is followed by a walkthrough tutorial to newcomers wishing to
> -support a new platform with the `Pipeline Handler Writers Guide`_ and for those
> -looking to make use of the libcamera native API an `Application Writers Guide`_
> -provides a tutorial of the key APIs exposed by libcamera.
> -
> -.. _Pipeline Handler Writers Guide: pipeline-handler.html
> -.. _Application Writers Guide: application-developer.html
> -
> -.. TODO: Correctly link to the other articles of the guide
> -
> -Platform Support
> -----------------
> -
> -The library currently supports the following hardware platforms specifically
> -with dedicated pipeline handlers:
> -
> - - Intel IPU3 (ipu3)
> - - Rockchip RK3399 (rkisp1)
> - - RaspberryPi 3 and 4 (rpi/vc4)
> -
> -Furthermore, generic platform support is provided for the following:
> -
> - - USB video device class cameras (uvcvideo)
> - - iMX7, Allwinner Sun6i (simple)
> - - Virtual media controller driver for test use cases (vimc)
> -
> -Licensing
> ----------
> -
> -The libcamera core, is covered by the `LGPL-2.1-or-later`_ license. Pipeline
> -Handlers are a part of the libcamera code base and need to be contributed
> -upstream by device vendors. IPA modules included in libcamera are covered by a
> -free software license, however third-parties may develop IPA modules outside of
> -libcamera and distribute them under a closed-source license, provided they do
> -not include source code from the libcamera project.
> -
> -The libcamera project itself contains multiple libraries, applications and
> -utilities. Licenses are expressed through SPDX tags in text-based files that
> -support comments, and through the .reuse/dep5 file otherwise. A copy of all
> -licenses are stored in the LICENSES directory, and a full summary of the
> -licensing used throughout the project can be found in the COPYING.rst document.
> -
> -Applications which link dynamically against libcamera and use only the public
> -API are an independent work of the authors and have no license restrictions
> -imposed upon them from libcamera.
> -
> -.. _LGPL-2.1-or-later: https://spdx.org/licenses/LGPL-2.1-or-later.html
> diff --git a/Documentation/index.rst b/Documentation/index.rst
> index 59416906..6d7d2ca3 100644
> --- a/Documentation/index.rst
> +++ b/Documentation/index.rst
> @@ -17,7 +17,6 @@
> Application Writer's Guide <guides/application-developer>
> Camera Sensor Model <camera-sensor-model>
> Camera Stack <camera_stack>
> - Developer Guide <guides/introduction>
> Environment variables <environment_variables>
> Feature Requirements <feature_requirements>
> IPA Writer's guide <guides/ipa>
> diff --git a/Documentation/meson.build b/Documentation/meson.build
> index 74cffc11..32642f32 100644
> --- a/Documentation/meson.build
> +++ b/Documentation/meson.build
> @@ -134,7 +134,6 @@ if sphinx.found()
> 'environment_variables.rst',
> 'feature_requirements.rst','
> 'guides/application-developer.rst',
> - 'guides/introduction.rst',
> 'guides/ipa.rst',
> 'guides/pipeline-handler.rst',
> 'guides/tracing.rst',
--
Regards,
Laurent Pinchart
More information about the libcamera-devel
mailing list