Age | Commit message (Collapse) | Author |
|
When streamOff() is called, ensure the cache entries for the remaining queued
buffers are freed since this will not happen via the dequeueBuffer() mechanism.
Additionally, add a V4L2BufferCache::isEmpty() function and assert that the
cache is empty at the end of the streamOff() call.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
If the device is in the process of being stopped (i.e. Stopping state), any
call to queueBuffer() must fail. This is to ensure the integrity of the buffer
queue, as it gets cleared at the end of streamOff.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Replace the existing streaming_ state variable with an enum to track the
following three state: Streaming, Stopping, and Stopped. The alternate states
will be used in a subsequent commit.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The original use of RPi::Stream::reset() was to clear the external flag state
and free/clear out the framebuffers for the stream. However, the latter is now
done through PipelineHandlerRPi::configure(). Rework
PipelineHandlerRPi::configure() to call RPi::Stream::setExternal() instead of
RPi::Stream::reset() to achieve the same thing.
Repurpose RPi::Stream::reset() to instead reset the state of the buffer handling
logic, where all internally allocated buffers are put back into the queue of
available buffers. As such, rename the function to RPi::Stream::resetbuffers().
This resetbuffers() is now called from PipelineHandlerRPi::start(), allowing the
pipeline handler to correctly deal with start()/stop()/start() sequences and
reusing the buffers allocated on the first start().
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Currently, all framebuffer allocations get freed and cleared on a stop in
PipelineHandlerRPi::stopDevice(). If PipelineHandlerRPi::start() is then called
without an intermediate PipelineHandlerRPi::configure(), it will re-allocate and
prepare all the buffers again, which is unnecessary.
Fix this by not freeing the buffer in PipelineHandlerRPi::stopDevice(), but
insted doing it in PipelineHandlerRPi::configure(), as the buffers might have
to be resized.
Add a flag to indicate that buffer allocations need to be done on the next
call to PipelineHandlerRPi::start().
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This function used to clear the camera buffers does not belong in the
PipelineHandlerRPi class as it only access members of the RPiCameraData,
so move it.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The V4L2DeviceFormat structure for the ISP Output 1 node was a copy of what is
used ISP Output 0 node, but with the size changed. However, the plane size and
stride values were not updated. So there is a possibility that the buffer might
be over-sized for the requested resolution.
Fix this by only copying the relevant fields from the ISP Output 0
V4L2DeviceFormat structure, and let the device driver size the planes as needed.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The start(unsigned int msec) overload is error-prone, as the argument
unit can easily be mistaken in callers. Drop it and update all callers
to use the start(std::chrono::milliseconds) overload instead.
The callers now need to use std::chrono_literals. The using statement
could be added to timer.h for convenience, but "using" is discouraged in
header files to avoid namespace pollution. Update the callers instead,
and while at it, sort the "using" statements alphabetically in tests.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The RkISP1Path::generateConfiguration() function limits the maximum
resolution to the sensor resolution, to avoid upscaling. It however
doesn't take the sensor aspect ratio into account, which leads to a
maximum (and default) resolution of 1920x1920 when using the self path
with a sensor that has a higher resolution.
Fix it by constraining the minimum and maximum resolutions to match the
sensor's aspect ratio.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The IPARkISP1Interface currently uses event-type based structures in
order to communicate with the pipeline-handler (and vice-versa).
Replace the event based structures with dedicated functions associated
to each operation.
The translated naming scheme of operations to dedicated functions:
ActionV4L2Set => setSensorControls
ActionParamFilled => paramsBufferReady
ActionMetadata => metdataReady
EventSignalStatBuffer => processStatsBuffer()
EventQueueRequest => queueRequest()
The lexical of IPARkISP1::metadataReady() will now conflict with the
metadataReady Signal being introduced in this patch as part of the
interface change. Hence, rename IPARkISP1::metadataReady() to
IPARkISP1::prepareReady() to prevent the conflict.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
s/bytesused/bytes used/
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add a comment to clarify why we set v4l2_buffer timestamp while
queuing the buffer (VIDIOC_QBUF). The timstamps are required to
be supplied for memory-to-memory devices for output streams which
then are copied to capture stream buffers with the help of
V4L2_BUF_FLAG_TIMESTAMP_COPY (set by the driver).
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The struct v4l2_buffer documentation [1] clearly states
that setting of the sequence is done by the driver. libcamera does
not really need to set this field while queuing the buffer(s).
[1]: https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/buffer.html#struct-v4l2-buffer
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add an entry to the sensor properties for the ov5640. Only the first
test pattern is included as the others that are exposed by the kernel
don't correspond to any that are defined in the libcamera control.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The Sony IMX296 is a global shutter sensor with a 1456x1088 pixel array
size, with a recommended resolution after CFA interpolation of
1440x1080.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add camera sensor property entries for the OmniVision 2740 camera
sensor.
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When configuring the pipeline we want to share the controls for any
VCM device against the sensor too - pass them to the lensControls
member of configInfo
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add a function to the CameraLens class to fetch the V4L2 controls
for its V4L2 subdev
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add a function to check for and initialise any VCMs linked to the
CameraSensor's entity by ancillary links. This should initialise
the lens_ member with the linked entity. Call the new function
during CameraSensor::init().
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The populateLinks() function can't currently handle ancillary links
which causes an error to be thrown in process() when the MediaObject
cannot be cast to a MediaPad.
Add explicit handling for the different link types, creating either
pad-2-pad links or else storing the pointer to the ancillary device
MediaEntity in the ancillaryEntities_ member of the primary.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
With kernel support for ancillary links, we can describe the
relationship between two devices represented individually as instances
of MediaEntity. As the only property of that relationship is its
existence, describe those relationships in libcamera simply as a
vector of MediaEntity pointers to the ancillary devices.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The CameraLens class implements a function named "setFocusPostion".
There is a typo here, fix it.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
We must calculate the initial scaler crop when the camera is
configured, otherwise the metadata will report this rectangle as being
all zeroes.
Because the calculation is identical to that performed later in handling
the scaler crop control, we factor it into a small helper function,
RPiCameraData::scaleIspCrop.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Simplify the image and embedded buffer matching logic by removing the assumption
that we require a buffer match between the two streams. Instead, if an image
buffer does not match with an embedded data buffer, simply use the ControlList
provided by DelayedControls for the sensor parameters.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
If Stream::returnBuffer() gets passed an internally allocated buffer, it now
simply re-queues it back to the device. With this change, the pipeline handler
code can be simplified slightly as it does not need multiple code paths for
internally allocated and non-internally allocated buffers.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Objects are not expected to be connected to the same signal more than
once. Doing so likely indicates a bug in the code, and can be
highlighted in debug builds with an assert that performs a lookup on the
signals_ list.
While it is possible to allow the implementation to let objects connect
to a specific signal multiple times, there are no expected use cases for
this in libcamera and this behaviour is restricted to favour defensive
programming by raising an error when this occurs.
Remove the support in the test framework which uses multiple Signal
connections on the same object, and update the test to use a second
Signal.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Provide a call allowing requests to be registered and associated with
the pipeline handler after being constructed by the camera.
This provides an opportunity for the PipelineHandler to connect any
signals it may be interested in receiving for the request such as
getting notifications when the request is ready for processing when
using a fence.
While here, update the existing usage of the d pointer in
Camera::createRequest() to match the style of other functions.
Bug: https://github.com/raspberrypi/libcamera-apps/issues/217
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
external
Remove the code that marks the Embedded Data stream as external with the Unicam
Image (RAW) stream. This was needed for legacy reasons when matching image and
embedded buffers, but is not needed any more.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The ISP input stream currently only allocates a single slot in the
V4L2VideoDevice cache as it follows the number of buffers allocated for use.
However, this is wrong as the ISP input stream imports buffers from Unicam
image stream. As a consequence of this, only one cache slot was used during
runtime for the ISP input stream, and if multiple buffers were to be queued
simultaneously, the queue operation would return a failure.
Fix this by passing the same number of RAW buffers available from the Unicam
image stream. Additionally, double this count in the cases where buffers could
be allocated externally from the application.
Bug: https://github.com/raspberrypi/libcamera-apps/issues/236
Bug: https://github.com/raspberrypi/libcamera-apps/issues/238
Bug: https://github.com/raspberrypi/libcamera-apps/issues/240
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Fix a typo in a logging message.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The libcamerasrc gstreamer component does seem to not allow stream resolutions
that are not advertised by PipelineHandler::generateConfiguration(). This has
been raised in a bug report [1].
Fix this behavior by advertising a SizeRange from the minimum ISP resolution, up
to the sensor resolution from PipelineHandlerRPi::generateConfiguration().
[1] https://bugs.libcamera.org/show_bug.cgi?id=105
Fixes: f16acb275c85 ("pipeline: raspberrypi: Restrict the advertised maximum ISP output resolution")
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Now that the sensor is defined to list mbus codes using its native
(untransformed) Bayer order, the method of obtaining it can be
simplified. We don't have to try and reset the flips, we just use the
value directly from the sensor.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
We clear the V4L2_CID_HFLIP and V4L2_CID_VFLIP controls immediately
after opening the camera device. This means the camera's Bayer format
and mbus codes will be in the sensor's "native" order, and we document
this to be the case so that it can be relied upon.
Clearing the flips is harmless where sensor flips do not affect the
Bayer order.
This also fixes a bug in the Raspberry Pi pipeline handler where the
native Bayer order was being computed wrongly, but the new behaviour
here will be helpful to other pipeline handlers too. A subsequent
commit will tidy up the Raspberry Pi pipeline handler in this area as
it can now be simplified.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Fixes: 83a512816189 (pipeline: raspberrypi: Convert the pipeline handler to use media controller)
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Switch the "no buffers available" log message from Info to Debug so that it does
not get output by default.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
If the sensor exposes the V4L2_CID_NOTIFY_GAINS control, assume it
means the sensor wants to be told the latest colour gains.
We store whether the control exists and if so its default value, to
save us checking for it on every frame.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
V4L2Device::setControl and V4L2Device::updateControl are both updated
to handle ControlTypeInteger32 array controls.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This change will allow the pipeline handler to enumerate and control Video
Mux or Bridge devices that may be attached between sensors and a particular
Unicam instance. Cascaded mux or bridge devices are also handled.
A new member function RPiCameraData::enumerateVideoDevices(), called from
PipelineHandlerRPi::registerCamera(), is used to identify and open all mux and
bridge subdevices present in the sensor -> Unicam link.
Relevant links are enabled/disabled and pad formats correctly set in
PipelineHandlerRPi::configure() before the camera is started.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Enumerate the sensor device entities in PipelineHandlerRPi::match() and loop
over PipelineHandlerRPi::registerCamera() for each sensor found. This will
allow the pipeline handler to register multiple cameras attached to a single
Unicam instance with a Video Mux device.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The pkg-config version should not be hardcoded, and it should match the
version of the library, ideally with point releases where possible.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The PipelineHandler lock() and unlock() functions are documented as
thread-safe, but they're not. Fix them using a mutex.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The MediaDevice lock is meant to prevent concurrent usage of multiple
cameras from the same pipeline handlers. As media devices are acquired
by pipeline handlers, we can't have multiple pipeline handlers trying to
lock the same media device. The recursive locking detection can thus be
moved to the pipeline handler. This simplifies the media device
implementation that now implements true lock semantics, and prepares for
support of concurrent camera usage.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The ASSERT() macro integrates with the logging infrastructure, use it to
replace assert().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The Entity::link member has an ambiguous name. Rename it to sourceLink
to clarify that it stores the link on the source pad.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The Raspberry Pi pipeline handler now sets color spaces correctly.
In generateConfiguration() it sets them to reasonable default values
based on the stream role.
validate() now calls validateColorSpaces() to ensure that the
requested color spaces are sensible, before proceeding to check what
the hardware can deliver.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This function forces raw streams to have the "raw" color space, and
also optionally makes all non-raw output streams to share the same
color space as some platforms may require this.
When sharing color spaces we take the shared value to be the one from
the largest of these streams. This choice is ultimately arbitrary, but
can be appropriate if smaller output streams are used for image
analysis rather than human consumption, when the precise colours may
be less important.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The ColorSpace from the StreamConfiguration is now handled
appropriately in the V4L2Subdevice.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This adds a ColorSpace field to the V4L2SubdeviceFormat so that we can
set and request particular color spaces from V4L2.
This commit simply adds the field and fixes some occurrences of brace
initializers that would otherwise be broken. A subsequent commit will
pass and retrieve the value correctly to/from V4l2 itself.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The ColorSpace from the StreamConfiguration is now handled
appropriately in the V4L2VideoDevice.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add functions to the V4L2Device class to convert to and from
libcamera ColorSpace.
These functions are added to the base V4L2Device class so that they can
be shared both by the video device class and subdevices.
With the ColorSpace class, the color space and related other fields
are stored together, corresponding to a number of fields in the
various different V4L2 format structures. Template functions are
therefore a convenient implementation, and we must explicitly
instantiate the templates that will be needed.
Note that unset color spaces are converted to requests for the
device's "default" color space.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This is so that applications can choose appropriate color spaces which
will then be passed down to the V4L2 devices.
The ColorSpace field is actually optional. If it is not set you will
get the camera's default color space.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|