| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
With the upcoming FrameBuffer API a new library wide FrameMetadata
object will be added which will replace the specific implementation in
the V4L2 compatibility layer.
Avoid name collisions while the new FrameBuffer API is added by renaming
the V4L2 compatibility layer specific implementation until it can be
replaced with the library wide implementation.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Now that Object::invokeMethod() supports returning a value, use it and
drop the return value method argument.
Signed-off-by: Laurent Pinchart <laurent.pinchart@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>
|
