| Age | Commit message (Collapse) | Author |
|---|
|
When constructing the camera, we parse the available controls on the
video capture device, and map supported controls to libcamera controls,
and initialise the defaults.
The controls are handled during queueRequestDevice for each request and
applied to the device through the capture node.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The VIVID pipeline handler retains state globally of it's controls.
Ensure that when we configure this specific pipeline we set initial
parameters on the device that suit our (specific) needs.
This introduces how controls can be set directly on a device, however
under normal circumstances controls should usually be set from libcamera
controls as part of a request. These are VIVID specific only.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When a request is given to a pipeline handler, it must parse the request
and identify what actions the pipeline handler should take to enact on hardware.
In the case of the VIVID pipeline handler, we identify the buffer from the only
supported stream, and queue it to the video capture device.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
We can now add buffer management, and connect up our bufferReady signal
to a callback.
Note that we provide the ability to export buffers from our capture
device (data->video_) using the exportBuffers() functionality from the
V4L2VideoDevice which allows a FrameBufferAllocater to obtain buffers
from this device.
When buffers are obtained through the exportFrameBuffers API, they are
orphaned and left unassociated with the device, and must be reimported
at start() time anyway. This allows the same interface to be used
whether internal buffers, or external buffers are used for the stream.
When a buffer completes, we call the buffer completion handler on the
pipeline handler, and because we have only a single stream, we can also
immediately complete the request.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When the configurations have been generated and validated, they can be
applied to a device.
Vivid supports only a single stream, so it directly obtains the first
StreamConfiguration from the CameraConfiguration.
The VIVID catpure device is a V4L2Video device, so we generate a
V4L2DeviceFormat to apply directly to the capture device node.
Note that we convert the libcamera Format stored in
cfg.pixelFormat to a V4L2PixelFormat using V4L2PixelFormat helper. This
currently defaults to the single-planar formats, and should be extended
to support the Multiplanar configuration from the V4L2Device.
[todo Repair the link between the multiplanar configuration of the
V4L2VideoDevice and the pixel format selection]
Following the call to set the format using the Kernel API, if the format
has been adjusted in any way by the kernel driver, then we have failed
to correctly handle the validation stages, and thus the configure
operation is idendified has having failed.
Finally stream specific data can be directly stored and set as
reflecting the state of the stream.
[NOTE: the cfg.setStream() call here associates the stream to the
StreamConfiguration however that should quite likely be done as part of
the validation process. TBD]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Implement the support for Generating and Validating the streams the
Camera can provide.
Vivid is a simple case with only a single stream.
Test the configurations can be generated and reported with cam -I:
"""
LIBCAMERA_LOG_LEVELS=Pipeline,VIVID:0 ./src/cam/cam -c 1 -I
[232:02:09.633067174] [2882911] INFO IPAManager ipa_manager.cpp:136 libcamera is not installed. Adding '/home//libcamera/build-vivid/src/ipa' to the IPA search path
[232:02:09.633332451] [2882911] WARN IPAManager ipa_manager.cpp:147 No IPA found in '/usr/local/lib/x86_64-linux-gnu/libcamera'
[232:02:09.633373414] [2882911] INFO Camera camera_manager.cpp:283 libcamera v0.0.11+714-d1ebd889-dirty
Using camera vivid
0: 1280x720-BGR888
* Pixelformat: NV21 (320x180)-(3840x2160)/(+0,+0)
- 320x180
- 640x360
- 640x480
- 1280x720
- 1920x1080
- 3840x2160
* Pixelformat: NV12 (320x180)-(3840x2160)/(+0,+0)
- 320x180
- 640x360
- 640x480
- 1280x720
- 1920x1080
- 3840x2160
* Pixelformat: BGRA8888 (320x180)-(3840x2160)/(+0,+0)
- 320x180
- 640x360
- 640x480
- 1280x720
- 1920x1080
- 3840x2160
* Pixelformat: RGBA8888 (320x180)-(3840x2160)/(+0,+0)
- 320x180
- 640x360
- 640x480
- 1280x720
- 1920x1080
- 3840x2160
"""
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Create a VividCameraData inheriting from the CameraData to handle camera
specific data, and use it to create and register the camera with the
CameraManager.
This can now be tested to see that the camera becomes available to
applications:
"""
LIBCAMERA_LOG_LEVELS=Pipeline,VIVID:0 ./src/cam/cam -l
[231:44:49.325333712] [2880028] INFO IPAManager ipa_manager.cpp:136 libcamera is not installed. Adding '/home/libcamera/build-vivid/src/ipa' to the IPA search path
[231:44:49.325428449] [2880028] WARN IPAManager ipa_manager.cpp:147 No IPA found in '/usr/local/lib/x86_64-linux-gnu/libcamera'
[231:44:49.325446253] [2880028] INFO Camera camera_manager.cpp:283 libcamera v0.0.11+713-d175334d-dirty
Available cameras:
1: vivid
"""
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Verify that we can match on our expected device(s).
Use a temporary debug print to check that the pipeline finds
our device:
"""
LIBCAMERA_LOG_LEVELS=Pipeline,VIVID:0 ./src/cam/cam -l
<snipped>
[230:51:10.670503423] [2872877] DEBUG VIVID vivid.cpp:81 Obtained Vivid Device
"""
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
To make sure we always build the Vivid pipeline in this branch,
explicitly add it to the build targets, and remove it from the pipeline
configuration choices.
This is not any kind of best practice for pipeline handlers, but is here
to ensure that this pipeline is always compiled on this branch who's
sole purpose is to use and demonstrate the vivid pipeline handler.
|
|
Explicitly disable the unused-parameter warning in this pipeline handler.
Parameters are left unused while they are introduced incrementally, so for
documentation purposes only we disable this warning so that we can compile
each commit independently without breaking the flow of the development
additions.
This is not recommended practice within libcamera, please listen to your
compiler warnings.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Provide all of the skeleton stubs to succesfully compile
and register a new Pipeline Handler for the Vivid test device.
Meson must be reconfigured to ensure that this pipeline handler is
included in the selected pipelines configuration, and after building, we
can test that the PipelineHandler is successfully registered by listing
the cameras on the system with LIBCAMERA_LOG_LEVELS enabled:
"""
LIBCAMERA_LOG_LEVELS=Pipeline:0 ./build-vivid/src/cam/cam -l
[230:30:03.624102821] [2867886] DEBUG Pipeline pipeline_handler.cpp:680 Registered pipeline handler "PipelineHandlerVivid"
Available cameras:
"""
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Failure can still happen by CameraBufferManager during Unlock() and/or
Deregister() of camera3Buffer handles. We should be logging those
errors as well.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
A lot of code used in the single stream test is boiler plate and common
across every gstreamer test. Factor out this code into a base class
called GstreamerTest.
Also update the gstreamer_single_stream_test to use the GstreamerTest
base class.
Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The V4L2 compatibility layer supports the single-planar API only, and
thus exposes a single V4L2 buffer plane to applications, regardless of
the number of planes in the FrameBuffer. For multi-planar frame buffers,
the bytesused value isn't correct as it only takes the first plane into
account. Fix it by summing the bytesused values for all FrameBuffer
planes.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
|
|
Now that the ViewFinderQt receives an Image, move the Converter API to
take an Image as well, and enable multi-planar buffer support.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Now that the ViewFinderGL receives an Image, it can trivially support
multi-planar buffers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Replace the manual implementation of frame buffer mapping with the Image
class to improve code sharing. The ViewFinder API is updated to take an
Image pointer in the render() function to prepare for multi-planar
buffer support.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Fix the debug message that prints frame metadata to print the number of
bytes used for each plane, not just the first one.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When creating a DRM frame buffer, the dmabufs for the planes are
imported as GEM objects. For multi-planar formats, all planes may use
the same dmabuf, which results in multiple imports. This doesn't cause
any issue at import time, as DRM detects this situation and returns the
same GEM object. However, when destroying the frame buffer, the same GEM
object ends up being closed multiple times, which generates an error.
Fix this by avoiding multiple imports of the same dmabuf for the same
frame buffer. While the issue may theoretically occur with identical
dmabufs for different frame buffers, this is quite unlikely and is thus
not addressed.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Now that libcamera supports per-plane offsets, pass the values to
drmModeAddFB2(). The KMS sink in cam is now capable of rendering
multi-planar formats.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The stride is not always identical for all planes for multi-planar
formats. Semi-planar YUV formats without horizontal subsampling often
have a chroma stride equal to twice the luma stride, and tri-planar YUV
formats with a 1/2 horizontal subsampling often have a chroma stride
equal to half the luma stride. This isn't correctly taken into account
when creating a DRM frame buffer, as the same stride is set for all
planes.
libcamera doesn't report per-plane stride values yet, but uses chroma
strides that match the above description for all currently supported
platforms. Calculation the chrome strides appropriately in the KMSSink
class, and pass them to DRM::createFrameBuffer().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Replace the manual implementation of frame buffer mapping with the Image
class to improve code sharing.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The new Image class represents a multi-planar image with direct access
to pixel data. It currently duplicates the function of the
MappedFrameBuffer class which is internal to libcamera, and will serve
as a design playground to improve the API until it is considered ready
to be made part of the libcamera public API.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The JPEG post-processor uses MappedFrameBuffer to access pixel data, but
only uses data from the first plane. Pass the vector of planes to the
encode() function to correctly handle multi-planar formats (currently
limited to NV12).
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When calculating the luma line address, the image width is used instead
of the stride. Without padding at the end of the line the the values
should be identical, but this is conceptually incorrect in any case. Fix
it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
|
|
Now that libcamera correctly supports frame buffers with different
dmabuf for each plane, remove the assumption that a single dmabuf is
used.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The number of metadata planes should always match the number of frame
buffer planes. Enforce this by making the vector private and providing
accessor functions.
As this changes the public API, update all in-tree users accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
The metadata planes are allocated by V4L2VideoDevice when dequeuing a
buffer. This causes the metadata planes to only be allocated after a
buffer gets dequeued, and doesn't provide any strong guarantee that
their number matches the number of FrameBuffer planes. The lack of this
invariant makes the FrameBuffer class fragile.
As a first step towards fixing this, allocate the metadata planes when
the FrameBuffer is constructed. The FrameMetadata API should be further
improved by preventing a change in the number of planes.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
Replace a manual counter with the utils::enumerate() utility function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
When dequeueing a buffer from a V4L2VideoDevice, the number of planes in
the FrameBuffer may not match the number of V4L2 buffer planes if the
PixelFormat is multi-planar (has multiple colour planes) and the V4L2
format is single-planar (has a single buffer plane). In this case, we
need to split the single V4L2 buffer plane into FrameBuffer planes. Do
so, and add checks to reject invalid V4L2 buffers in case of a driver
issue.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
When queueing a buffer to a V4L2VideoDevice, the number of planes in the
FrameBuffer may not match the number of V4L2 buffer planes if the
PixelFormat is multi-planar (has multiple colour planes) and the V4L2
format is single-planar (has a single buffer plane). In this case, we
need to coalesce all FrameBuffer planes into a single V4L2 buffer plane.
Do so, and add validity checks to reject frame buffers that can't be
described using a single V4L2 buffer plane.
This change prepares for proper multi-planar support, but isn't expected
to result in a change of behaviour with existing pipeline handlers, as
none of them queue an output buffer with multiple FrameBuffer planes or
use non-contiguous buffers for either capture or output.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
When creating FrameBuffer instances, the V4L2VideoDevice computes plane
offsets using minimal stride for the format. This doesn't always produce
a valid result when the device requires padding at the end of lines. Fix
it by computing offsets using the stride reported by V4L2.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The V4L2VideoDevice::createBuffer() calculates offsets manually when
using a multi-planar pixel format and a single-planar V4L2 format. The
process isn't trivial, document it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Cache the PixelFormatInfo instead of looking it up in every call to
createBuffer(). This prepares for usage of the info in queueBuffer(), to
avoid a looking every time a buffer is queued.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
Multi-planar frame buffers can store their planes contiguously in
memory, or split them in discontiguous memory areas. Add a private
function to check in which of these two categories the frame buffer
belongs. This will be used to correctly handle the differences between
the V4L2 single and multi planar APIs.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
The FrameBuffer::planes() function checks that planes are correctly
initialized with an offset. This can be done at construction time
instead, as the planes are constant. The backtrace generated by the
assertion will show where the faulty frame buffer is created instead of
where it is used, easing debugging.
As the runtime overhead is reduced, there's no real need to drop the
assertion in the future anymore, it can be useful to ensure that the
planes are correctly populated by the caller. Drop the comment that
calls for removing the check.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
V4L2 describes multi-planar formats with different 4CCs depending on
whether or not the planes are stored contiguously in memory. Support
this when translating between PixelFormat and V4L2PixelFormat.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
|
|
Add two helpers functions to the PixelFormatInfo class to compute the
byte size of a given plane, taking the frame size, the stride, the
alignment constraints and the vertical subsampling into account.
Use the new functions through the code base to replace manual
implementations.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
Move the PixelFormatPlaneInfo structure within the PixelFormatInfo class
definition and rename it to Plane, to align the naming scheme with other
parts of libcamera, such as FrameBuffer::Plane or FrameMetadata::Plane.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Replace manual searches for V4L2 pixel format in the PixelFormatInfo
with the V4L2PixelFormat::fromPixelFormat() helper function. This
prepares for multi-planar support that will modify how V4L2 pixel
formats are stored in PixelFormatInfo.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The V4L2VideoDevice::toV4L2PixelFormat() function is incorrectly
implemented, as it will pick a multi-planar format if the device
supports the multi-planar API, even if only single-planar formats are
supported. This currently works because the implementation calls
V4L2PixelFormat::fromPixelFormat(), which ignores the multiplanar
argument and always returns a single-planar format.
Fixing this isn't trivial. As we don't need to support multi-planar V4L2
formats at this point, drop the function instead of pretending
everything is fine, and call V4L2PixelFormat::fromPixelFormat() directly
from pipeline handlers. As the single-planar case is the most common,
set the multiplanar argument to false by default to avoid long lines.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
The inode is useful to check if two file descriptors refer to the same
file. Add a function to retrieve it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
The index generated by utils::enumerate() is an iteration counter, which
should thus be positive. Use std::size_t instead of the difference_type
of the container.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
Add camera sensor properties for the Hynix hi846 sensor. The part is
also called YACG4D0C9SHC and a datasheet can be found at
https://product.skhynix.com/products/cis/cis.go
This is the selfie camera in the Librem 5 phone.
Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Usually .cpp files are equipped with using namespace libcamera;
Hence, it is unnecessary mentioning the explicit namespace of
libcamera at certain places.
While at it, a small typo in a comment was noticed and fixed as
part of this patch.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
Replace the open-coded PixelFormat lookup with the
V4L2PixelFormat::toPixelFormat() helper function. This simplifies the
implementation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasoboard.com>
|
|
Many signals used in internal and public APIs carry the emitter pointer
as a signal argument. This was done to allow slots connected to multiple
signal instances to differentiate between emitters. While starting from
a good intention of facilitating the implementation of slots, it turned
out to be a bad API design as the signal isn't meant to know what it
will be connected to, and thus shouldn't carry parameters that are
solely meant to support a use case specific to the connected slot.
These pointers turn out to be unused in all slots but one. In the only
case where it is needed, it can be obtained by wrapping the slot in a
lambda function when connecting the signal. Do so, and drop the emitter
pointer from all signals.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
In many cases, the emitter object passed as a pointer from signals to
slots is also available as a class member. Use the class member when
this occurs, to prepare for removal of the emitter object pointer from
signals.
In test/event.cpp, this additionally requires moving the EventNotifier
to a class member.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
It can be useful to connect a signal to a functor, and in particular a
lambda function, while still operating in the context of a receiver
object (to support both object-based disconnection and queued
connections to Object instances).
Add a BoundMethodFunctor class to bind a functor, and a corresponding
Signal::connect() function. There is no corresponding disconnect()
function, as a lambda passed to connect() can't be later passed to
disconnect(). Disconnection typically uses disconnect(T *object), which
will cover the vast majority of use cases.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The BoundMethodArgs specialization for the void return type is only
needed to avoid accessing the ret_ member variable that is lacking from
the corresponding BoundMethodPack specialization. As the member variable
is only accessed in the invokePack() function, instead of specializing
the whole class we can use SFINAE to select between two different
implementations of the function.
SFINAE can only depend on the function template parameters, not the
parameters of the class template in which the function is defined:
"Only the failures in the types and expressions in the immediate context
of the function type or its template parameter types are SFINAE errors."
We thus can't use the type R in an std::enable_if expression for the
invokePack() function. To work around this, we have to add a type T to
the function template definition, which defaults to R, and use T with
std::enable_if.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
