By default all pipeline handlers are built, regardless on whether these
are needed in the host architecture or not. It makes more sense to build
only the pipeline handlers that will be used for the given architecture.
Let's do that by default now, but still allow to build the other
pipeline handlers if needed, by using the `pipelines` meson option. For
example, on a x86-64 platform:
$ meson build
...
Configuration
Enabled pipelines : ipu3
uvcvideo
Enabled IPA modules : ipu3
...
$ meson build -Dpipelines="ipu3,raspberrypi,rkisp1" -Dtest=true
...
Configuration
Enabled pipelines : ipu3
raspberrypi
rkisp1
vimc
Enabled IPA modules : ipu3
raspberrypi
rkisp1
vimc
...
Suggested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The libcamera Python bindings is still experimental and it relies on some
features in pybind11 that are not yet upstreamed, so a special branch has
to be downloaded as a subproject.
This conflicts with the build process used by most Linux distributions,
since there is expected that all the dependencies will be fulfilled by
-devel packages present in the build root.
To allow libcamera to be built by distros, let's disable the pycamera by
default. This can still be enabled with `meson build -Dpycamera=enabled`.
Suggested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Currently, a subproject is used to fetch gtest dependency unconditionally
for any Linux distribution besides ChromeOS. But it leads to a regression
in distros whose builders are not allowed to download files during build.
This change was introduced by commit 0d50a04cc9 ("lc-compliance: Build
with gtest in subprojects") and the rationale is that some distros, such
as Debian ship libgtest-dev as a static library. And this could be built
with a different toolchain than the one used to build libcamera itself.
But this seems to be a corner case, usually users will either build both
libcamera and all its dependencies using the same toolchain or build it
using both the libgtest library and toolchain as provided by the distro.
If someone doesn't want for meson to pick up the non-compatible static
library provided by the distro, then instead should make sure that their
build root does not have the package providing this installed.
Let's simplify the logic to find the dependency and just use the built-in
support in dependency() function to fallback to a subproject if not found.
This covers to common case of attempting to use the gtest provided by the
system or pulling from source if not found or is not preferred.
To force meson to fallback to the wrap for gtest you can use this command:
meson configure -Dforce_fallback_for=gtest
and to force fallback for all the dependencies, you can use the following:
meson build --wrap-mode=forcefallback
Fixes: commit 0d50a04cc9 ("lc-compliance: Build with gtest in subprojects")
Reported-by: Eric Curtin <ecurtin@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The libcamera Android Camera HAL generates camera configurations for the
StillCapture, Raw and ViewFinder stream roles. But there is only a check
if the configuration generation failed, for the StillCapture stream role.
This could lead to a NULL pointer dereference if a pipeline handler fails
to generate a default configuration for one of the other two stream roles.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Currently, the gst_libcamera_device_new() function assumes that a call to
Camera::generateConfiguration() will always succeed, but that may not be
the case and the return value must to be checked.
Otherwise, this could lead to a NULL pointer dereference if the pipeline
handler fails to generate a config for the VideoRecording stream role.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The libcamera and libcamera-base libraries are currently unversioned, but
donwstream users expect these to have a proper SONAME version in order to
package them.
A stable release has not yet happened because the project is still under
development and the API/ABI might change. But having a versioned SONAME
would allow distributions to package libcamera, without the need to add
any downstream patch to set the version.
Since the "0.0.0" version is already used in different places, let's also
use that as the library version. The meson build system will use the first
part of the version ("0") as the SONAME version, which is aligned with the
convention used by other projects:
$ ls /lib64/libcamera*so* -1
/lib64/libcamera-base.so
/lib64/libcamera-base.so.0
/lib64/libcamera-base.so.0.0.0
/lib64/libcamera.so
/lib64/libcamera.so.0
/lib64/libcamera.so.0.0.0
$ objdump -p /lib64/libcamera.so.0.0.0 | grep SONAME
SONAME libcamera.so.0
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Javier Martinez CanillasandLaurent Pinchart