-
Notifications
You must be signed in to change notification settings - Fork 0
Packaging and Distribution of libcamera
This page is some unofficial notes from Kieran to support Distributions and packaging teams. Consider this a draft which can be updated until it could be added to the libcamera documentation.
libcamera is in active development, including investigations into what a 'good' API is for the implementation. We can't guarantee we have all features implemented, or designed correctly yet, and we have plans to make considerable changes to the API and ABI in our roadmap.
Even so, we have been asked to provide 'releases' to support distributions and packaging teams. To support this we are currently making releases of the 0.y.z version scheme, loosely following semver.
In the foreseeable future, the following applies:
- 0.0.z : Each release bumps the soname. API/ABI may be consistent but not necessarily stable between (0.0 is now discontinued)
- 0.y.z : Active development, but with ABI breakage detection. The 0.y version will bump on an ABI/API breakage. Ongoing development will increment the .z version component.
- 1.y.z : Stable API and ABI guarantees on the Major version number. Following semantic versioning as documented at https://semver.org/
'Image Processing Algorithms' are contained within 'IPA modules' and they are loaded dynamically with dlopen at initialisation time of the libcamera library.
libcamera allows camera vendors to supply IPA modules with closed source proprietary implementations. This is seen as a compromise between the open source community and camera vendors who see the image processing algorithms as their 'secret sauce', and the value-add that ensures people buy their products. Without this compromise - Linux distributions and users would likely be left 'unsupported'. For distributions that will not supply binary implementations, the libcamera project aims to develop open-source algorithms. These may not offer all the image processing features as can be supplied by the camera vendors, but should provide a usable and acceptable image, and allows ongoing community development, including support for devices after they stop receiving updates from vendors.
To facilitate closed source components in an open source project, we use module signing. Modules that are open source and compiled at the same time as the build of libcamera are signed with a public/private key pair. This key is verified when loaded. If the signature is valid, then the module can be loaded in the same process space as libcamera and calls are made directly into the trusted IPA.
If the IPA module signature is invalid, then the module is considered proprietary and untrusted. As no public review of the code can be made, it can not be considered safe to run in the same process space as libcamera. Distributions may choose to fully isolate this code in a sandbox, which will restrict access to the system or hardware to provide safety and security guarantees to their users. The module will operate through an IPC mechanism, which can be distribution or platform specific.
libcamera will aim to install components into a libexec directory which are not expected to be multiarch compatible, or required for cross compilation. They are machine specific and are used for that machine to run libcamera functionality.
The v4l2-compat.so is an LD_PRELOAD object that can be loaded before an application to catch calls to the V4L2 interfaces and indirectly wrap these calls to use the libcamera system.
This allows applications which do not know about libcamera to operate on platforms with complex camera devices.
The IPA proxy system is an implementation to run the IPA modules in separated process space. These binaries are executed by libcamera and used to connect IPC links between the IPA modules and the libcamera pipeline handlers.
IPA modules are signed with a public/private key pair. This means that each build will generate a unique keypair and the public key is embedded into the libcamera library. Modules signed with the private key can be validated by the public key. The private key is discarded after the build process, and not installed to the target, which ensures that only IPA modules signed at the time of building libcamera can be identified as 'trusted'.
Distributions which desire a 'reproducible' build may either need to investigate providing a pre-generated keypair to the build system, or otherwise investigate and develop new methods of validating which IPA modules can be trusted to load.
Debian ensure that the IPA modules are resigned after stripping with the following commit:
- https://salsa.debian.org/multimedia-team/libcamera/-/commit/7871e6737d82e76942aaa3b6f56a2f03f28b1d91
Resigning issue solved in one specific project (not Conan itself) with the following commit:
- https://gitlab.com/aivero/open-source/conan-config/-/commit/77043e1e900b32146607730515f74bdcec8a7209
To use libcamera in your image, add "IMAGE_INSTALL += libcamera" to your recipes.
Components are broken into separate packages so for instance to support the gstreamer module, also add "IMAGE_INSTALL += libcamera-gst"