| Age | Commit message (Collapse) | Author |
|---|
|
To achieve the goal of preventing unwanted conversion between a DRM and
a V4L2 FourCC, make the PixelFormat constructor that takes an integer
value explicit. All users of pixel formats flagged by the compiler
are fixed.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Create a class to represent a pixel format. This is done to add support
for modifiers for the formats. So far no modifiers are added by any
pipeline handler, all plumbing to deal with them is however in place.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Instead of having to include linux/drm_fourcc.h everywhere a DRM FourCC
is used in conjunction with PixelFormat include the header directly in
pixelformats.h.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
gcc 8.3.0 for ARM complains about strict aliasing violations:
../../src/libcamera/controls.cpp: In member function ‘void libcamera::ControlValue::release()’:
../../src/libcamera/controls.cpp:111:13: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
delete[] *reinterpret_cast<char **>(&storage_);
Fix it and simplify the code at the same time.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The libcamera_api array is meant to contain all the headers from the
libcamera public API, for the purpose of generating documentation and
creating the libcamera_dep dependency. libcamera.h is part of the
libcamera public API, add it to the array.
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>
|
|
The libcamera_api array is meant to contain all the headers from the
libcamera public API, for the purpose of generating documentation and
creating the libcamera_dep dependency. The generated control headers are
part of the libcamera public API, and used to be included in the
libcamera_api array until commit f870591a9bf5 ("libcamera: properties:
Add location property") inadvertently removed them. Add them back.
Fixes: f870591a9bf5 ("libcamera: properties: Add location property")
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
[Split the change out and reworded the commit message]
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The gen-header.sh script that generates libcamera.h takes all .h files
in the include/libcamera/ directory, and manually adds the generated
control_ids.h and version.h. This is fragile, as shown by the failure to
add property_ids.h to the list in commit f870591a9bf5 ("libcamera:
properties: Add location property").
To avoid future omissions, take all the .h.in files into account to
generate libcamera.h. This also fixes the missing property_ids.h.
Fixes: f870591a9bf5 ("libcamera: properties: Add location property")
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>
|
|
Report in a new field of the ipa_control_value_entry structure if the
value contains an array. Reorganize the other fields of the structure to
avoid increasing its size.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add support for byte values to the control framework and to the control
serializer.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add support for float values in Control<> and ControlValue classes.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
For array controls, the ControlList::set() function takes a value as a
type convertible to Span<T>. This allows passing an std::array or an
std::vector in addition to an explicit Span, but doesn't accept an
std::initializer list as Span has no constructor that takes an
initializer list. Callers are thus forced to create temporary objects
explicitly, which isn't nice.
Fix the issue by providing a ControlList::set() function that takes an
std::initializer_list, and convert it to a Span internally.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add array controls support to the ControlValue class. The polymorphic
class can now store more than a single element and supports access and
creation through the use of Span<>.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add a data() function to the ControlValue class to expose the raw data
stored by the class as a Span<const uint8_t>. This will be useful to
simplify the serialization of ControlValue instances.
The size computation for the raw data is moved from the
ControlSerializer, which is updated accordingly to use the data()
function in order to access the size. Simplification of the
ControlSerializer will happen in a subsequent change.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
To avoid defining all specializations of the Control constructor
manually, move the definition of those functions to controls.h and turn
them into a single template function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
To avoid defining all specializations of the ControlValue constructor
manually, move the definition of those functions to controls.h and turn
them into a single template function. The default constructor is still
kept in controls.cpp.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
To avoid defining all specializations of ControlValue::get() and
ControlValue::set() manually, move the definition of those functions to
controls.h and turn them into single template functions.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
These will be used to implement ControlValue::get() and set() as
template functions.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The ControlList::get() and ControlValue::get() methods return the
control value by reference. This requires the ControlValue class to
store the control value in the same form as the one returned by those
functions. For the array controls that are soon to be added, the
ControlValue class would need to store a span<> instance in addition to
the control value itself, which would increase the required storage
space.
Prepare for support of array controls by returning from get() by value.
As all control values are 8 bytes at most, this doesn't affect
efficiency negatively.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The ControlList::set() method takes a reference to a Control<T>, and
requires the value to be a reference to T. This prevents the set()
method from being used with value types that are convertible to T, and
in particular with std::array or std::vector value types when the
Control type is a Span<> to support array controls.
Fix this by decoupling the control type and value type in the template
parameters. The compiler will still catch invalid conversions, including
cases where the constructor of type T from the value type is explicit.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Reorder functions in ControlValue class to group const methods together.
Cosmetic change only.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The <ipa/ipa_controls.h> header makes use of uint*_t types, but doesn't
include stdint.h. Fix it, and include ipa_controls.h in ipa_controls.cpp
to test compilation of the header on its own.
While at it, fix the comment as the top of ipa_controls.cpp to refer to
the correct file name.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The ipa_control_range_data structure is only used to document the IPA
control serialization format, but isn't used in code at all as the
ControlRange entries are directly serialized to a byte stream buffer.
This applies to the ipa_control_value_data structure that is solely used
by ipa_control_range_data.
Expand the documentation of the IPA control serialization format to
describe the layout of the control range data in words and diagrams
instead of through a C structure. Remove the unused structures as a
result.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
C++20 will contain a std::span<> class that provides view over a
contiguous sequence of objects, the storage of which is owned by some
other object.
Add a compatible implementation to the utils namespace. This will be
used to implement array controls.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
C++14 introduced useful type traits helpers named std::*_t as aliases to
std::*<...>::type. Use them to simplify the code.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Add a method to the Camera class to retrieve the Camera properties
registered by the pipeline handler.
While at it, reword the Camera::controls() operation documentation to
specify that the camera control information are constant during the
camera lifetime not their value, while the camera properties value are
the actually static information.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Augment the the ControlRange class to store the control default value.
This is particularly relevant for v4l2 controls used to create
Camera properties, which are constructed using immutable video device
properties, whose value won't change at runtime.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Re-use the Control generation infrastructure to generate libcamera properties
and define the first 'Location' property.
Introduce three additional files:
- include/libcamera/property_ids.h
Defines the properties ids
- src/libcamera/property_ids.cpp
Defines the properties Control<> instances
- src/libcamera/property_ids.yaml
Provide the first 'Location' property definition.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Import a temporary version of the v4l2-controls.h with the newly added
definition of V4L2_CID_CAMERA_SENSOR_LOCATION and
V4L2_CID_CAMERA_SENSOR_ROTATION controls.
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Use the d-pointer idiom ([1], [2]) to hide the private data members from
the Camera class interface. This will ease maintaining ABI
compatibility, and prepares for the implementation of the Camera class
threading model.
The FrameBufferAllocator class accesses the Camera private data members
directly. In order to hide them, this pattern is replaced with new
private member functions in the Camera class, and the
FrameBufferAllocator is updated accordingly.
[1] https://wiki.qt.io/D-Pointer
[2] https://en.cppreference.com/w/cpp/language/pimpl
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Making CameraManager::cameras() thread-safe requires returning a copy of
the cameras vector instead of a reference. This is also required for
hot-plugging support and is thus desirable.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Use the d-pointer idiom ([1], [2]) to hide the private data members from
the CameraManager class interface. This will ease maintaining ABI
compatibility, and prepares for the implementation of the CameraManager
class threading model.
[1] https://wiki.qt.io/D-Pointer
[2] https://en.cppreference.com/w/cpp/language/pimpl
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>
|
|
The slots list is touched from most of the Signal template functions. In
order to prepare for thread-safety, move handling of the list to a small
number of non-template functions in the SignalBase class.
This incidently fixes a bug in signal disconnection handling where the
signal wasn't removed from the object's signals list, as pointed out by
the signals unit test.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Now that we're using C++-14, replace the manual implementation of
std::integer_sequence with std::index_sequence, a specialization of
std::integer_sequence with the integer type equal to std::size_t. The
template parameter S that denotes a sequence is replaced with I to align
with the usage examples of cppreference.com.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
With the FrameBuffer rework completed there is no reason to keep the
camera prepared state around as buffer allocations are now decoupled
from the camera state. Remove the camera state simplifying the API.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Delete all dead code after switching to the FrameBuffer interface.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Switch to the FrameBuffer interface where all buffers are treated as
external buffers and are allocated outside the camera. Applications
allocating buffers using libcamera are switched to use the
FrameBufferAllocator helper.
Follow-up changes to this one will finalize the transition to the new
FrameBuffer interface by removing code that is left unused after this
change.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
buffers
The FrameBuffer interface is based on the idea that all buffers are
allocated externally to libcamera and are only used by it. This is meant
to create a simpler API centered around usage of buffers, regardless of
where they come from.
Linux however lacks a centralized allocator at the moment, and not all
users of libcamera are expected to use another device that could provide
suitable buffers for the camera. This patch thus adds a helper class to
allocate buffers internally in libcamera, in a way that matches the
needs of the FrameBuffer-based API.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Move the metadata retrieved when dequeuing a V4L2 buffer into a
FrameMetadata object. This is done as a step to migrate to the
FrameBuffer interface as the functions added to Buffer around
FrameMetadata match the ones in FrameBuffer.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
In the FrameBuffer interface the stream will not be available from the
buffer object as the buffer might be allocated externally. The
application needs to explicitly state which stream the buffer is being
added for to the request.
Extend the addBuffer() function to get this information explicitly from
the caller.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
There is no need to have a private helper function to access a private
data member when a friend statement is needed anyhow. Remove the helper
function to simplify the code and make it clear that a private member of
Buffer is accessed.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
There are no users left of the Plane class, drop it.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
It is not libcamera's responsibility to handle memory mappings. Switch
from the soon to be removed Plane class which deals with memory
mappings to FrameBuffer::Plane which just describes it. This makes the
transition to the full FrameBuffer easier.
As the full FrameBuffer interface has not yet spread to all parts of
libcamera core it is hard to create efficient caching of memory mappings
in the qcam application. This will be fixed in a later patch, for now
the dmabuf is mapped and unmapped each time it is seen by the
application.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Switch the IPA interfaces and implementations to use the Framebuffer
interface.
- The IPA interface is switched to use the simpler FrameBuffer::Plane
container when carrying dmabuf descriptions (fd and length) over the
pipeline/IPA boundary.
- The RkISP1 IPA implementation takes advantage of the new simpler and
safer (better control over file descriptors) FrameBuffer interface.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a new FrameBuffer class to describe memory used to store frames.
This change just adds the new interface, future patches will migrate all
parts of libcamera to use this and replace the old Buffer interface.
This change needs to specify the const keyword for Plane::length() as to
not get Doxygen confused with FrameBuffer::Plane::length added in this
change.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
With the introduction of FrameBuffer objects, the metadata information
related to captured frames will not be stored directly in the frame
buffer object. Add a new FrameMetadata class to hold this information.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a helper to make it easier to pass file descriptors around. The
helper class duplicates the fd which decouples it from the original fd
which could be closed by its owner while the new FileDescriptor remains
valid.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The association of buffers to a request can be done directly in
addBuffer() instead of when the request is queued to the camera. Keep
the check that a request contains buffers by moving it to
Camera::queueRequest() where prepare() was previously called.
As a bonus we can remove a friend statement in Request.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Most of the bound method classes are named with a BoundMethod prefix,
except for BoundMemberMethod and BoundStaticMethod. Rename them to
BoundMethodMember and BoundMethodStatic respectively to make the code
more coherent.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Propagate the return value of the bound method all the way to the caller
of activate(). The value is stored in the arguments pack for indirect
invocation.
As C++ doesn't allow instantiating a variable of type void, we need to
specialize the template class BoundMethodPack for methods returning
void. This in turn requires template specialization for the
BoundMethodArgs class in order to store the return value in the pack,
and for the BoundMemberMethod class to extract the return value from the
pack.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The bound method arguments pack will need to be accessed by the method
invoker in order to retrieve the method return value when using a
blocking connection type. We thus can't delete the pack unconditionally
in the bound method target thread. We also can't delete it
unconditionally in the invoker's thread, as for queued connections the
pack will be used in the target thread after the invoker completes.
This shows that ownership of the arguments pack is shared between two
contexts. As a result, manage it using std::shared_ptr<>.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
