summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-04-12libcamera: bound_method: Fix type of pack for void methodsLaurent Pinchart
The BoundMethodPack used by the void BoundMethodArgs variant incorrectly specified the template argument as void * instead of void. This causes no functional problem, but results in space for an unused void * return value being reserved. Fix it. 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>
2021-04-12lc-compliance: Add test stopping single stream with requests queuedNiklas Söderlund
Add a test which stops a camera while requests are still queued. This intends to test cleanup paths where requests are dequeued from video devices in an uncompleted state. Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
2021-04-12lc-compliance: Add a libcamera compliance toolNiklas Söderlund
Add a compliance tool to ease testing of cameras. In contrast to the unit-tests under test/ that aims to test the internal components of libcamera the compliance tool aims to test application use-cases and to some extent the public API. This change adds the boilerplate code of a simple framework for the creation of tests. The tests aim both to demonstrate the tool and to catch real problems. The tests added are: - Test that if one queues exactly N requests to a camera exactly N requests are eventually completed. - Test that a configured camera can be started and stopped multiple times in an attempt to exercise cleanup code paths otherwise not often tested with 'cam' for example. Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
2021-04-07libcamera: camera_manager: Remove \todo on hotplug/unplug of camerasUmang Jain
Fixes: e9b47217b44c ("libcamera: camera_manager: Introduce signals when a camera is added or removed") Signed-off-by: Umang Jain <email@uajain.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>
2021-04-07libcamera: thread: Fix typo in commentSebastian Fricke
s/This method enter/This method enters/ Signed-off-by: Sebastian Fricke <sebastian.fricke@posteo.net> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-04-05Add alternative meson install commandVedant Paranjape
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>
2021-04-04android: CameraDevice: Deny non ROTATION_0 stream configurationHirokazu Honda
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>
2021-04-04android: CameraDevice: Log rotation variables in camera3_streamHirokazu Honda
|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>
2021-04-04android: CameraDevice: Validate crop_rotate_scale_degrees in configurationHirokazu Honda
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>
2021-04-04android: Define OS_CHROMEOS macro if android_platform=crosHirokazu Honda
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>
2021-04-04android: mm: cros: Fix compilationLaurent Pinchart
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>
2021-04-04android: CameraDevice: Add more camera3_capture_request validationHirokazu Honda
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>
2021-04-04android: cameraDevice: Factorize the code of validating camera3_capture_requestHirokazu Honda
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>
2021-04-04android: CameraDevice: Deny if the streams is emptyHirokazu Honda
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>
2021-04-04android: mm: cros: Handle buffer registration failureHirokazu Honda
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>
2021-04-03libcamera: pipeline_handler: Make queueRequest() void functionHirokazu Honda
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>
2021-04-03Documentation: Add getting started sectionLaurent Pinchart
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>
2021-03-29android: camera_device: Add null check for ScalerCrop controlPhi-Bang Nguyen
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>
2021-03-29libcamera: thread: Remove the unused setEventDispatcher() functionLaurent Pinchart
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>
2021-03-29ipa: raspberrypi: Fix typo and improve wordingSebastian Fricke
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>
2021-03-29pipeline: raspberrypi: Remove unused getFormat callSebastian Fricke
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>
2021-03-29libcamera: pipeline: ipu3: frames: Use the request sequenceKieran Bingham
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>
2021-03-29libcamera: camera: Extend with a Stopping stateKieran Bingham
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>
2021-03-29libcamera: camera: Report function which fails access controlKieran Bingham
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>
2021-03-29libcamera: camera: Validate requests are completed in Running stateKieran Bingham
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>
2021-03-29libcamera: request: Add a toString()Kieran Bingham
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>
2021-03-29libcamera: request: Provide a sequence numberKieran Bingham
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>
2021-03-29libcamera: buffer: Break friendship with RequestKieran Bingham
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>
2021-03-29utils: ipc: proxy: Track IPA with a state machineKieran Bingham
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>
2021-03-29libcamera: pipeline: ipu3: Fix typosLaurent Pinchart
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>
2021-03-28pipeline: uvcvideo: Avoid reference to temporary objectKhem Raj
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>
2021-03-28pipeline: raspberryPi: Fix typo in commentSebastian Fricke
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>
2021-03-28ipa: raspberrrypi: Remove duplicate commentSebastian Fricke
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>
2021-03-28meson: Summarize which applications and adaptation layers are builtLaurent Pinchart
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>
2021-03-27ipa: rkisp1: Do not set controls during configureSebastian Fricke
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>
2021-03-25libcamera: camera_manager: Document the CameraManager destructorLaurent Pinchart
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>
2021-03-25Documentation: contributing: Add link to bugs.libcamera.orgLaurent Pinchart
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>
2021-03-25android: meson: Remove unneeded android_enabled checkLaurent Pinchart
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>
2021-03-25android: CameraDevice: Mark getResultMetadata() const functionHirokazu Honda
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>
2021-03-25android: CameraDevice: Manage requestTemplates_ with std::unique_ptrHirokazu Honda
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>
2021-03-25android: CameraDevice: Manage staticMetadata_ with std::unique_ptrHirokazu Honda
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>
2021-03-25android: Camera3RequestDescriptor: Manage buffers with std::vectorHirokazu Honda
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>
2021-03-25android: CameraDevice: Return const shared_ptr& by camera()Hirokazu Honda
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>
2021-03-25android: CameraDevice: Take shared_ptr in constructorHirokazu Honda
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>
2021-03-25android: CameraHalManager: Fix a function call of a moved CameraHirokazu Honda
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>
2021-03-25android: CameraHalManager: Hold CameraManager with std::unique_ptrHirokazu Honda
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>
2021-03-25android: CameraHalManager: Hold CameraDevice with std::unique_ptrHirokazu Honda
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>
2021-03-24libcamera: v4l2_videodevice: Prevent queueing buffers without a cacheKieran Bingham
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>
2021-03-24ipa: ipu3: Do not set controls during configureKieran Bingham
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>
2021-03-24libcamera: pipeline: ipu3: frames: Associate buffers with the requestKieran Bingham
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>