| Age | Commit message (Collapse) | Author |
|---|
|
While installing meson using pip3 install --user meson, due to python
path issues, build.ninja can't be located by ninja. meson generates
ninja files fine, but then when you run ninja, it is unable to find
meson's build.ninja python module due to path issues.
It gives the following error on ninja -C build install:
ninja: Entering directory `build'
ninja: error: loading 'build.ninja': No such file or directory
After uninstalling meson using pip3 and installing it again using pip
without --user argument solved the issue.
Add a troubleshooting section to the readme to describe this issue and
suggest possible solutions.
Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
libcamera doesn't handle crop_rotate_scale_degrees. Therefore,
if it is requested, that is, crop_rotate_scale_degrees is not
CAMERA3_STREAM_ROTATION_0, the configuration should fail.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
|rotation| and |crop_rotate_scale_degrees| are important info of
a configuration. They should be logged.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
libcamera doesn't handle |crop_rotate_scale_degrees| in
camera3_stream at all. This adds the validation of the requested
|crop_rotate_scale_degrees| in configuration, but still not
handle the specified values.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Android Camera HAL 3 API used in ChromeOS has a ChromeOS own
extension, for example, crop_rotate_scale_degrees in
camera3_stream. As those extensions are not available on Android
platforms, introduce a OS_CHROMEOS macro that can be used to
compile CrOS-specific code conditionally. The macro is defined
if and only if android_platform is 'cros'.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Commit 7d7879833812 ("android: mm: cros: Handle buffer registration
failure") mistakenly tried to initialize the CameraBuffer::Private
registered member variable instead of registered_. This reults in a
compilation failure. Fix it.
Fixes: 7d7879833812 ("android: mm: cros: Handle buffer registration failure")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This adds more validation to camera3_capture_request mainly
about buffer_handle values.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
CameraDevice::processCaptureRequest() checks the validity of a
provided camera3_capture_request. This factorizes the code in
order to add more validation to the request later.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
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 checks if the number of streams is zero on configuration
and then returns -EINVAL.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
cros::CameraBufferManager::Register() fails if a buffer handle
is invalid. We should mark CameraBuffer as invalid on the failure
of Register().
While the cros::CameraBufferManager Unlock() and Deregister() functions
should be able to handle buffers that haven't been locked and
registered, this isn't an API guarantee, and errors will be logged.
Avoid this by skipping unlocking and unregistration of buffers that
haven't been locked or registered.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
PipelineHandler::queueRequest() is asynchronously invoked in
Camera::queueRequest(). Therefore the return value of
PipelineHandler::queueRequest() is useless. This changes the
function to a void function.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Pull the "getting started" of README.rst in the documentation tree, as
done on libcamera.org, to ensure documentation build coverage of the
whole README.rst.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The ScalerCrop control does not contain the null check which can cause
the camera HAL crash at boot. Fix it.
Fixes: 31a1a628cd0e ("android: camera_device: Register MAX_DIGITAL_ZOOM")
Signed-off-by: Phi-Bang Nguyen <pnguyen@baylibre.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>
|
|
Custom event dispatchers for threads was an API meant to provide a way
to integrate libcamera in the application's event loop. This isn't used
anymore, as libcamera now creates internal threads. Drop the unused
Thread::setEventDispatcher() function, and update the documentation
accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
s/Return the validated limits out though metadata./
Return the validated limits via metadata./
Signed-off-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The comment states, that we get the device format to pass it to the IPA,
but the variable `sensorFormat` is not used again after it's assignment.
Remove it, together with the comment.
Signed-off-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
For all frame indexes, use the same sequence number as generated
by the Request object.
This allows clear matching of what operations occurred to which request.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When the camera is being stop()ped, active requests will complete. These
may trigger an application to re-queue those requests to the camera but
that is not permitted, and is an error in the application.
Extend the camera state to include a stopping state which is entered as
soon as a call to stop() is made. At this point, any request queued will
be rejected with a warning, while any pending requests are either
successfully completed or cancelled.
When the pipeline handler has finished stopping, the camera state will
transition to the CameraConfigured state where it can begin to accept
requests again, and be restarted.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The camera object has a state machine to ensure calls are only made
when in the correct state. It isn't easy to identify where things happen
when assertions fail so add extra information to make this clearer.
The error level of the isAccessAllowed is raised from Debug to Error as
this is important information for applications to know if they have made
a request in an invalid state.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
All requests must have completed before the Camera has fully stopped.
Requests completing when the camera is not running represent an internal
pipeline handler bug.
Trap this event with a fatal error.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Provide a toString helper to assist in printing Request state
for debug and logging contexts.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Provide a sequence number on Requests which are added by the pipeline
handler.
Each pipeline handler keeps a requestSequence per CameraData and
increments everytime a request is queued on that camera.
The sequence number is associated with the Request and can be utilised
for assisting with debugging, and printing the queueing sequence of in
flight requests.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The FrameBuffer class is only friends with Request so that the request
can be associated with the buffers.
FrameBuffer already has a helper to setRequest(), so let's use that
directly instead.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Asynchronous tasks can only be submitted while the IPA is running.
Further more, the shutdown sequence can not be tracked with a simple
running flag. We can also be in the state 'Stopping' where we have not
yet completed all events, but we must not commence anything new.
Refactor the running_ boolean into a stateful enum to track this.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Fix two simple typos.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
A range-based for loop whose range expression is an array of char
pointers and range variable declaration is a const reference to a
std::string creates a temporary string from the char pointer and binds
the range variable reference to it. This creates a const reference to a
temporary, which is valid in C++, and extends the lifetime of the
temporary to the lifetime of the reference.
However, lifetime extension in range-based for loops is considered as a
sign of a potential issue, as a temporary is created for every
iteration, which can be costly, and the usage of a reference in the
range declaration doesn't make it obvious that the code isn't simply
binding a reference to an existing object. gcc 11, with the
-Wrange-loop-construct option, flags this:
uvcvideo.cpp:432:33: error: loop variable 'name' of type 'const string&' {aka 'const std::__cxx11::basic_string<cha
r>&'} binds to a temporary constructed from type 'const char* const' [-Werror=range-loop-construct]
| 432 | for (const std::string &name : { "idVendor", "idProduct" }) {
| | ^~~~
To please the compiler, make the range variable a const char *. This may
bring a tiny performance improvement, as the name is only used once, in
a location where the compiler can use
operator+(const std::string &, const char *)
instead of
operator+(const std::string &, const std::string &)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Use a const char * type instead of auto, and update the commit message
accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
s/Will need to/We'll need to/
Signed-off-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The exact same comment is used two times within 5 lines.
Remove one of them as it is redundant.
Signed-off-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add the application and adaptation layers being built to the meson
summary. The summary now prints
libcamera 0.0.0
Configuration
Enabled pipelines: ipu3
raspberrypi
rkisp1
simple
uvcvideo
vimc
Android support: True
GStreamer support: True
V4L2 emulation support: True
cam application: True
qcam application: True
Unit tests: True
Subprojects
libyuv: YES
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
Do not send events back to the pipeline handler, while the IPA thread
has not been started.
If information needs to be returned from configure it should be returned
directly.
Move the initial call to setControls() out of configure() and into the
start() method which is called after the IPA running_ state is updated.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The destructor stops the camera manager if it is running. This is at the
moment an implementation detail, but makes sense to guarantee in the
API. Document it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Reference the issue tracker in the documentation, as relying on tribal
knowledge isn't a great option.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
We return early with subdir_done() if android_enabled is false. There's
no need to check the variable later in the file.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
CameraDevice::getResultMetadata() doesn't change either
|descriptor| and member variables. It should be marked as a
const function and |descriptor| should be passed with const
lvalue reference.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
CameraMetadata stored in requestTemplates_ in CameraDevice is
not necessary to be a raw pointer. This reduces the manual
new/delete code by changing the type to std::unique_ptr.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
staticMetadata_ in CameraDevice is not necessary to be a raw
pointer. This reduces the manual new/delete code by changing the
type to std::unique_ptr.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Camera3RequestDescriptor has a length and an allocated buffer
for camera_stream_buffer_t array. This replaces the variables
with std::vector.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
CameraDevice::camera() originally returns shared_ptr. It is
mandatory to make a copy by calling camera() in this way. There
is no need of copying if a caller needs the reference of the
camera like const shared_ptr<Camera> &cam = camera(). That is, it
is a caller that copying is required. This changes the return
type of camera() to const shared_ptr&, so that we are able to
reduce one redundant copy in the above case.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
CameraDevice takes the ownership of Camera. Therefore,
shared_ptr would rather be used than const shared_ptr&.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
libcamera::Camera::id() is called after std::move() in
cameraAdded(). This fixes the issue by not executing std::move().
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
CameraManager is owned by CameraHalManager. The ownership of the
object is not shared with other classes. So CameraHalManager
should manage CameraManager with std::unique_ptr.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
CameraDevice is owned by CameraHalManager. The ownership of the
object is not shared with other classes. So CameraHalManager
should manage CameraDevice with std::unique_ptr.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The V4l2 buffer cache allows us to map incoming buffers to an instance
of the V4L2 buffer required to actually queue.
If the cache_ is not available, then the buffers required to allow
queuing to a device have been released, and this indicates an issue at
the pipeline handler.
This could be a common mistake, as it could happen if a pipeline handler
always requeues buffers to the device after they complete, without
checking if they are cancelled.
Catch any invalid queueing of buffers to the V4L2 video device when
resources have been released by adding a Fatal log message to highlight
the error during development.
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The configure operation is synchronous and should not send events back
to the pipeline handler.
If information needs to be returned from configure it should be handled
through the interface directly.
Move the initial call to setControls() out of configure() and into the
start() method which is called after the IPA running_ state is updated.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Ensure that the buffers are associated with the request even if they are
used internally to be able to correctly map back to the resources they
are being used to fulfil.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Ensure that checks on resource availability are handled first, and then
operate on the queues only after the resources are confirmed as
available.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When the imguOutputBufferReady() detects a cancelled frame, it is
reporting that the metadata has been processed in order to be able to
complete the cancelled request.
This causes the FrameInfo to be completed and deleted early, but then an
active buffer on the IMGU can complete and be unable to find the
FrameInfo for it to complete correctly.
Do not mark metadataProcessed early on the event that a single buffer is
detected as cancelled. The stopping of the V4L2 devices will ensure
that all queued buffers are returned to us and we can follow the normal
and expected shutdown sequence.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The IPA should be stopped before the hardware devices to ensure that
all asynchronous actions have completed within the IPA before resources
are removed and released.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Events may be queued to the pipeline handler between the pipeline
handler entering the ::stop() function, and before the call to stop the
IPA has completed.
Handle these events by dispatching all pending messages at the proxy
after the IPA has fully stopped.
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Signals and calls from the IPA should not occur after the IPA has been
put into the stopped state.
Add assertions to catch and prevent any messages being processed after
this.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
