| 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>
|
|
To support polling, we need to be able to signal when data is
available to be read (POLLIN), as well as events (POLLPRI). Add the
necessary calls to eventfd to allow signaling POLLIN. We signal POLLIN
by writing writing to the eventfd, and clear it by reading from the
eventfd, upon VIDIOC_DQBUF.
Note that eventfd does not support signaling POLLPRI, so we don't yet
support V4L2 events.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The V4L2 compatibility layer is licensed under the GPL. It is compiled
as a binary separate from libcamera.so, and is loaded into the address
space of processes through LD_PRELOAD to intercept calls to the C
library.
It is our understanding and intent that the GPL license doesn't
propagate to the binaries whose calls are intercepted, considering those
binaries are not derivative work of the V4L2 compatibility layer and are
not designed to be linked to the V4L2 compatibility layer. There is
however a possibly grey area if binaries are packaged with a shell
script wrapper that loads the V4L2 compatibility layer. This could lead
to license-related issues if such packaging is performed by Linux
distributions or system integrators.
To clarify the intent and lift the doubts, relicense the V4L2
compatibility layer under the LGPL. The V4L2 compatibility layer code
itself still benefits from the license protection, while its usage with
third-party binaries is clearly allowed as intended.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Acked-by: Paul Elder <paul.elder@ideasonboard.com>
Acked-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.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>
|
|
Now that libcamera creates threads internally and doesn't rely on an
application-provided event loop, remove the thread from the V4L2
compatibility layer. The split between the V4L2CameraProxy and
V4L2Camera classes is still kept to separate the V4L2 adaptation from
camera operation. This may be further refactored later.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
In the upcoming FrameBuffer API the memory mapping of buffers will be
left to the user of the FrameBuffer objects. Prepare the V4L2
compatibility layer to this upcoming change to ease conversion to the
new API.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Create a new FileOperations structure to hold all the dynamically-loaded
C library file operations. The file operations are now exposed publicly,
to prepare for usage of mmap in the V4L2CameraProxy.
A new template helper function is added to retrieve a symbol with
dlsym() with proper casting to simplify the V4L2CompatManager
constructor.
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>
|
