| Age | Commit message (Collapse) | Author |
|---|
|
Some applications (eg. Firefox, Google Chrome, Skype) use open64,
openat64, and mmap64 instead of their non-64 versions that we currently
intercept. Intercept these calls as well. _LARGEFILE64_SOURCE needs to
be set so that the 64-bit symbols are available and not synonymous to
the non-64-bit versions on 64-bit systems.
Also, since we set _FILE_OFFSET_BITS to 32 to force the various open and
mmap symbols that we export to not be the 64-bit versions, our dlsym to
get the original open and mmap calls will not automatically be converted
to their 64-bit versions. Since we intercept both 32-bit and 64-bit
versions of open and mmap, we should be using the 64-bit version to
service both. Fetch the 64-bit versions of openat and mmap directly.
musl defines the 64-bit symbols as macros that are equivalent to the
non-64-bit symbols, so we put compile guards that check if the 64-bit
symbols are defined.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> # Compile with musl
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The libcamera internal headers are located in src/libcamera/include/.
The directory is added to the compiler headers search path with a meson
include_directories() directive, and internal headers are included with
(e.g. for the internal semaphore.h header)
#include "semaphore.h"
All was well, until libcxx decided to implement the C++20
synchronization library. The __threading_support header gained a
#include <semaphore.h>
to include the pthread's semaphore support. As include_directories()
adds src/libcamera/include/ to the compiler search path with -I, the
internal semaphore.h is included instead of the pthread version.
Needless to say, the compiler isn't happy.
Three options have been considered to fix this issue:
- Use -iquote instead of -I. The -iquote option instructs gcc to only
consider the header search path for headers included with the ""
version. Meson unfortunately doesn't support this option.
- Rename the internal semaphore.h header. This was deemed to be the
beginning of a long whack-a-mole game, where namespace clashes with
system libraries would appear over time (possibly dependent on
particular system configurations) and would need to be constantly
fixed.
- Move the internal headers to another directory to create a unique
namespace through path components. This causes lots of churn in all
the existing source files through the all project.
The first option would be best, but isn't available to us due to missing
support in meson. Even if -iquote support was added, we would need to
fix the problem before a new version of meson containing the required
support would be released.
The third option is thus the only practical solution available. Bite the
bullet, and do it, moving headers to include/libcamera/internal/.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
In an attempt to clarify the license terms of all files in the libcamera
project, the build system files deserve particular attention. While they
describe how the binaries are created, they are not themselves
transformed into any part of binary distributions of the software, and
thus don't influence the copyright on the binary packages. They are
however subject to copyright, and thus influence the distribution terms
of the source packages.
Most of the meson.build files would not meet the threshold of
originality criteria required for copyright protection. Some of the more
complex meson.build files may be eligible for copyright protection. To
avoid any ambiguity and uncertainty, state our intent to not assert
copyrights on the build system files by putting them in the public
domain with the CC0-1.0 license.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Acked-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Acked-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Acked-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Acked-by: Paul Elder <paul.elder@ideasonboard.com>
Acked-by: Show Liu <show.liu@linaro.org>
|
|
The v4l2-compat shared library is declared as depending on
libcamera_deps. This is not correct, as libcamera_deps contains the
dependencies of libcamera itself. The correct dependency for users of
libcamera is libcamera_dep.
Fixing this allows dropping libcamera_includes from the list of includes
required by v4l2-compat, and libcamera from the link_with list, as they
are already contained in libcamera_dep. We however need to add an
explicit dependency on libdl which was previously provided by
libcamera_deps.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Add libcamera V4L2 compatibility layer.
This initial implementation supports the minimal set of V4L2 operations,
which allows getting, setting, and enumerating formats, and streaming
frames from a video device. Some data about the wrapped V4L2 video
device are hardcoded.
Add a build option named 'v4l2' and adjust the build system to
selectively compile the V4L2 compatibility layer.
For now we match the V4L2 device node to a libcamera camera based on a
devnum that a pipeline handler may optionally map to a libcamera
camera.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
