summaryrefslogtreecommitdiff
path: root/src/android/camera_worker.h
AgeCommit message (Collapse)Author
2021-12-11android: Remove CameraWorkerJacopo Mondi
The CameraWorker class purpose was to handle acquire fences for incoming capture requests directed to libcamera. Now that fences are handled by the core library, it is not required to handle them in the HAL and the CameraWorker and CaptureRequest classes can be dropped. Update the core in CameraDevice class accordingly to queue Requests directly to the libcamera::Camera and set the release_fence to the value of the FrameBuffer::fence() for streams of type ::Direct. While at it make CameraRequest::StreamBuffer::fence a UniqueFD to ease the management of the fences file descriptor values. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-11-24android: Convert to pragma onceKieran Bingham
Remove the verbose #ifndef/#define/#endif pattern for maintaining header idempotency, and replace it with a simple #pragma once. This simplifies the headers, and prevents redundant changes when header files get moved. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
2021-09-30android: camera_worker: Use Camera3RequestDescriptor as cookieUmang Jain
Use Camera3RequestDescriptor as cookie for the Capture Request. The cookie is used to lookup descriptors map in CameraDevice::requestComplete(). The map will be transformed to a queue in subsequent commit. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-07-11libcamera: buffer: Rename buffer.h to framebuffer.hLaurent Pinchart
libcamera names header files based on the classes they define. The buffer.h file is an exception. Rename it to framebuffer.h. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-06-25libcamera/base: Move extended base functionalityKieran Bingham
Move the functionality for the following components to the new base support library: - BoundMethod - EventDispatcher - EventDispatcherPoll - Log - Message - Object - Signal - Semaphore - Thread - Timer While it would be preferable to see these split to move one component per commit, these components are all interdependent upon each other, which leaves us with one big change performing the move for all of them. Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-05-24android: camera_worker: Process all queued requests when stoppingLaurent Pinchart
When stopping the camera worker, queuedRequest() calls may have queued asynchronous function invocation messages to the worker thread, and some of those messages may not have been processed yet. The messages will stay in the thread's queue until the camera worker is restarted (when the camera service will start a new capture session). At that point, they will be dispatched, which will cause a crash due to the CaptureRequest passed to processRequest() having been deleted by CameraDevice::stop() calling descriptors_.clear(). Fix this by forcing dispatching of all function invocation messages when stopping the camera worker thread. Note that this is inherently racy, as more queueRequest() calls may arrive from the camera service while we're stopping. This race condition will be addressed by a subsequent patch series. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-04-20android: CameraDevice: Fix Camera3RequestDescriptor leakageHirokazu Honda
CameraDevice creates Camera3RequestDescriptor in processCaptureRequest() and disallocates in requestComplete(). Camera3RequestDescriptor can never be destroyed if requestComplete() is never called. This avoid the memory leakage by storing them in map CameraRequestDescriptor. 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-02-02libcamera: Improve Request life cycle trackingJacopo Mondi
The current logging to track the status of a Request when running the Android camera HAL provide the following information: When a Request is queued to libcamera: HAL camera_device.cpp:1776 '\_SB_.PCI0.I2C2.CAM0': Queueing Request to libcamera with 1 HAL streams When a Request completes: Request request.cpp:268 Request has completed - cookie: 138508601719648 The queueing of a Request reports the number of streams it contains while the completion of a Request reports the address of the associated cookie. This makes very hard to keep track of what Requests have completed, as the logging associated with a queue/complete event does not allow to identify a Request easily. Add two more printouts to make it easier to track a Request life cycle. To make it possible to print the Request cookie in the CameraDevice class add a method to access it from the CameraRequest class. The result looks like the following trace: Request request.cpp:92 Created request - cookie: 140701719392768 HAL camera_device.cpp:1710 '\_SB_.PCI0.I2C2.CAM0': Queueing request 140701719392768 with 1 streams HAL camera_device.cpp:1747 '\_SB_.PCI0.I2C2.CAM0': 0 - (4160x3104)[0x00000023] -> (4160x3104)[NV12] (direct) ... Request request.cpp:268 Request has completed - cookie: 140701719392768 HAL camera_device.cpp:1800 '\_SB_.PCI0.I2C2.CAM0': Request 140701719392768 completed with 1 streams.. Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-01-25android: camera_device: Handle SCALER_CROP_REGIONJacopo Mondi
Handle the SCALER_CROP_REGION control and dynamic metadata by translating it from the Android format to the associated libcamera control when processing a request, and the other way around when handling a request completion. Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2020-12-18android: camera_device: Report pipeline depthJacopo Mondi
Report the pipeline depth in the capture results if the pipeline reports it. Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2020-10-14android: camera_worker: Introduce CameraWorkerJacopo Mondi
The Android camera framework provides for each buffer part of a capture request an acquisition fence the camera HAL is supposed to wait on before using the buffer. As the libcamera HAL runs in the camera service thread, it is not possible to perform a synchronous wait there. Introduce a CameraWorker class that runs an internal thread to wait on a set of fences before queueing a capture request to the libcamera::Camera. Fences completion is handled through a simple poll, similar in implementation to the sync_wait() function provided by libdrm. Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>