summaryrefslogtreecommitdiff
path: root/src/android/camera_device.cpp
AgeCommit message (Collapse)Author
2021-08-06android: camera_device: Propagate the requested test pattern modeHirokazu Honda
Propagate the requested test pattern mode to libcamera::Camera through libcamera::Request and also set the android metadata to the test pattern mode contained by the complete Request. 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: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-04android: Override camera as "Internal" provided found in HAL configUmang Jain
Currently, all UVC cameras are reported with CameraLocationExternal [1] by libcamera-core since there is no universal information or standard, to know the location of these cameras. However, in the libcamera HAL layer, we can make an informed decision whether it's external or internal, simply by checking its presence in the HAL configuration file. The CameraHalManager will now assign the numerical id of the camera accordingly when initializing the CameraDevice, based on the camera facing value set in the HAL config file. [1] 76809320bb1a ("libcamera: pipeline: uvcvideo: Treat all UVC cameras as external") Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2021-08-02android: Add skeletal still and manual request templatesPaul Elder
Add skeletal still and manual request templates so that we can expand them for FULL support. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-06-28android: camera_device: Fix null pointer dereferenceLaurent Pinchart
Commit 7532caa2c77b ("android: camera_device: Reset config_ if Camera::configure() fails") reworked the configuration sequence to ensure that the CameraConfiguration pointers gets reset when configuration fails. This inadvertently causes a null pointer dereference, as the CameraStream constructor accesses the camera configuration through CameraDevice::cameraConfiguration() before the internal config_ pointer is set. Fix this by passing the configuration pointer explicitly to the CameraStream constructor. Fixes: 7532caa2c77b ("android: camera_device: Reset config_ if Camera::configure() fails") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Tested-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Tested-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-06-28android: camera_device: Check if a request is configured on ↵Hirokazu Honda
processCaptureRequest() Add a check on processCaptureRequest() if a given capture request contains a camera stream that has been configured. 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-06-28android: camera_device: Reset config_ if Camera::configure() failsLaurent Pinchart
The config_ pointer is reset in all error paths of the CameraDevice::configureStreams() function, except when Camera::configure() fails. Fix it by using a local unique pointer to store the configuration until the end of the function, to avoid similar issues in the future. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Umang Jain <umang.jain@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-06-25libcamera/base: Move utils to the base libraryKieran Bingham
Move the utils functionality to the libcamera/base library. Reviewed-by: Hirokazu Honda <hiroh@chromium.org> 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-06-23android: Introduce CameraCapabilties classJacopo Mondi
The camera_device.cpp has grown a little too much, and it has quickly become hard to maintain. Break out the handling of the static information collected at camera initialization time to a new CameraCapabilities class. Break out from the camera_device.cpp file all the functions related to: - Initialization of supported stream configurations - Initialization of static metadata - Initialization of request templates Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Acked-by: Paul Elder <paul.elder@ideasonboard.com> Tested-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-06-17android: camera_device: Simplify leftover CameraMetadata callsPaul Elder
There were some CameraMetadata calls that were left in the old version. Update them. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-06-15android: camera_device: Drop HAL_PIXEL_FORMAT_RAW_OPAQUE supportHirokazu Honda
HAL_PIXEL_FORMAT_RAW_OPAQUE is requested only for Zero-Shutter-Lag (ZSL). ZSL requires RAW and YUV reprocessing. Since either of them is not supported by libcamera, supporting RAW_OPAQUE format doesn't make sense. Drop the format from the supported format list. 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-06-14android: CameraDevice: Report queried test pattern modesHirokazu Honda
Report to the Android camera stack the list of supported test pattern modes constructed by inspecting the values reported by libcamera through the controls::draft::TestPatternMode control. 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: Jacopo Mondi <jacopo@jmondi.org>
2021-06-14android: Implement flush() camera operationJacopo Mondi
Implement the flush() camera operation in the CameraDevice class and make it available to the camera framework by implementing the operation wrapper in camera_ops.cpp. Introduce a new camera state State::Flushing to handle concurrent flush() and process_capture_request() calls. As flush() can race with processCaptureRequest() protect it by introducing a new State::Flushing state that processCaptureRequest() inspects before queuing the Request to the Camera. If flush() is in progress while processCaptureRequest() is called, return the current Request immediately in error state. If flush() has completed and a new call to processCaptureRequest() is made just after, start the camera again before queuing the request. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-06-14android: Rename CameraDevice::mutex_Jacopo Mondi
With the introduction of an additional mutex class member, the name of the existing one is too generic. Rename CameraDevice::mutex_ in CameraDevice::descriptorsMutex_ and use the libcamera provided libcamera::Mutex type to align the style with the rest of the code base. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-06-14android: Guard access to the camera stateJacopo Mondi
Guard access to the camera state and the start/stop sequences with a mutex. Currently only stop() and the first call to processCaptureRequest() start and stop the camera, and they're not meant to race with each other. With the introduction of flush() the camera can be stopped concurrently to a processCaptureRequest() call, hence access to the camera state will need to be protected. Prepare for that by guarding the existing paths with a mutex. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-06-14android: Replace scoped_lock<> with libcamera::MutexLockerJacopo Mondi
The CameraDevice class uses std::scoped_lock<> to guard access to the class' descriptors_ member. std::scoped_lock<> provides a set of features that guarantees safety when locking multiple mutexes in a critical section, while for single locks happening in a scoped block it does not provides benefits compared to the simplest std::unique_lock<> which libcamera provides the MutexLocker type for. Replace usage of std::scoped_lock<> with libcamera::MutexLocker to make the implementation consistent with the rest of the code base. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-06-14android: camera_device: Replace running_ with CameraStateJacopo Mondi
The CameraDevice class maintains the camera state in the 'running_' boolean flag to check if the camera has to be started at the first received process_capture_request() call which happens after the camera had been stopped. So far this was correct, as the operations that change the camera could only start or stop the camera, so a simple boolean flag was enough. To prepare to handle the flush() operation that will introduce a new 'flushing' state, replace the simple plain boolean flag with an enumeration of values that define the CameraState. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-06-14android: Rework request completion notificationJacopo Mondi
The current implementation of CameraDevice::requestComplete() which handles event notification and calls the framework capture result callback does not handle error notification precisely enough. In detail: - Error notification is an asynchronous callback that has to be notified to the framework as soon as an error condition is detected, and it independent from the process_capture_result() callback - Error notification requires the HAL to report the precise error cause, by specifying the correct CAMERA3_MSG_ERROR_* error code. The current implementation only notifies errors of type CAMERA3_MSG_ERROR_REQUEST at the end of the procedure, before the callback invocation. Rework the procedure to: - Notify CAMERA3_MSG_ERROR_DEVICE and perform library tear-down in case a Fatal error is detected - Notify CAMERA3_MSG_ERROR_REQUEST if the libcamera::Request::status is different than RequestCompleted and immediately call process_capture_result() with all buffers in error state. - Notify the shutter event as soon as possible - Notify CAMERA3_MSG_ERROR_RESULT in case the metadata cannot be generated correctly and call process_capture_result() with the right buffer state regardless of metadata availability. - Notify CAMERA3_MSG_ERROR_BUFFER for buffers whose post-processing failed While at it, return the CameraStream buffer by calling cameraStream->putBuffer() regardless of the post-processing result. No regression detected when running CTS in LIMITED mode. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-06-02android: Make FRAME_DURATION result key available in static metadataUmang Jain
Report ANDROID_SENSOR_FRAME_DURATION as an available result key for CTS to read out the value of frame duration we set in CameraDevice::getResultMetadata(). Failing to do so might fail the CTS test: - android.hardware.camera2.cts.CaptureRequestTest#testNoiseReductionModeControl Fixes: 3beb1accac1d ("android: camera_device: Fix sensor frame duration") 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> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-05-31android: Don't rely on indirect inclusion of unistd.hLaurent Pinchart
The standard C library close() and lseek() functions require inclusion of the unistd.h header. Include it explicitly where needed instead of relying on indirect inclusion. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Tested-by: Paul Elder <paul.elder@ideasonboard.com>
2021-05-27android: camera_device: Fix sensor frame durationPaul Elder
The sensor frame duration should be set by IPA. Get the information for the result metadata from libcamera. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-05-27controls: Split FrameDurations into FrameDuration and FrameDurationLimitsPaul Elder
We need a separate control to report the nominal frame duration, but it's also useful to report the min/max frame duration values that will be used. Split the FrameDurations control into FrameDuration and FrameDurationLimits respectively to support both of these. Signed-off-by: Paul Elder <paul.elder@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-05-26android: camera_metadata: Add functions for instrumenting resizingPaul Elder
Add utility functions to CameraMetadata to check if it has been resized, and for outputting the actual entry and data count. This is meant to be used to output information on resizing, to assist developers in choosing proper initial sizes to avoid resizing. Also make CameraDevice use these functions for static and result metadata. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-05-25android: camera_device: Get properties from configurationJacopo Mondi
Open the HAL configuration file in the Camera HAL manager and get the camera properties for each created CameraDevice and initialize it with them. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-05-25android: CameraDevice: Report proper min and max frame durationsPaul Elder
The HAL layer was getting the min and max frame durations from the camera, then rounding it to fps to report as available fps ranges. The same min and max frame durations were then being reported as min and max frame durations. Since the fps are integer values while the frame durations are in ns, this caused a rounding error making it seem like we were reporting an available max fps that was higher than what was allowed by the minimum frame duration. An example is if the minimum frame duration is reported as 33366700ns. The HAL layer would then convert it to fps, which is 29.97, but it would be rounded and reported as 30 fps. When 30 fps is converted to a frame duration it is 33333333ns, which is less than the minimum frame duration that we report. Thus the minimum frame duration that we report contradicts the fps range that we report. Fix this by recalculating the frame durations based on the rounded fps values. This allows the following CTS test to pass: - android.hardware.camera2.cts.SurfaceViewPreviewTest#testPreviewFpsRange Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-05-14android: camera_device: Use the new CameraMetadata functionsPaul Elder
Now that CameraMetadata supports more convenient functions, use those instead. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-05-14android: camera_metadata: Auto-resize CameraMetadataPaul Elder
Previously we had to manually declare the size of CameraMetadata on allocation, and its count could not be changed after construction. Change CameraMetadata's behavior so that the user can simply add or update entries, and the CameraMetadata will auto-resize (double the size) as necessary. Also remove everything involved with calculating the initial size for any CameraMetadata instances. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-05-12android: camera_device: Fix typo in result metadata allocation errorPaul Elder
Fix an error message typo s/static/result/. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-05-10android: camera_device: Report sensor physical sizeJacopo Mondi
Calculate the value of the ANDROID_SENSOR_INFO_PHYSICAL_SIZE property multiplying the number of sensor's readable pixels with the pixel unit cell size if provided by the Camera. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-05-06android: camera_device: Use controls::SensorTimestampJacopo Mondi
Use the controls::SensorTimestamp value to populate ANDROID_SENSOR_TIMESTAMP result metadata. The Camera is assumed to provide the control in the Request metadata. Reviewed-by: Hirokazu Honda <hiroh@chromium.org> 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>
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-04-20android: CameraDevice: Add stop()Hirokazu Honda
This adds CameraDevice::stop(), which cleans up the member variables of CameraDevice. It is called in CameraDevice::close() and CameraDevice::configureStreams(). 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: 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: 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-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-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: 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: 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-22android: camera_device: Do not default External to FrontJacopo Mondi
Now that the camera location is not defaulted anymore in the library but doesn't get registered if the firmware interface does not provide the information, do not default it to FRONT if LocationExternal is reported. To maintain compatibility with CTS requirements, default location to FRONT only if the camera property is not available. Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-09android: camera_device: Generate template for VideoJacopo Mondi
The capture request template for video recording use cases requires a fixed FPS range. Generate the request templates for the VIDEO_RECORD and VIDEO_SNAPSHOT capture intents using the preview template and updating the supported FPS range. This change fixes the CTS tests android.hardware.camera2.cts.CameraDeviceTest#testCameraDeviceRecordingTemplate Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-09android: camera_device: Fail template on no FPS rangeJacopo Mondi
The camera supported FPS range is crucial to distinguish between capture templates for preview and video recording. If the pipeline handler did not specify an available FPS range by registering the controls::FrameDurations property so far the control was simply not added to the generated capture template. In order to prepare to generate templates for video recording which require a fixed FPS range, fail earlier in generating any template at all if the available FPS range is not provided by the Camera. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-09android: camera_device: Refuse unsupported templatesJacopo Mondi
The current implementation of constructDefaultRequestSettings() returns the same capture template for all the capture intent. As the correctness of the generated template is verified by CTS it is better to return an error for unsupported capture use cases. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-09android: camera_device: Return AE FPS rangeJacopo Mondi
The result metadata reports an arbitrary {30, 30} FPS range for the AE algorithm. The actual FPS range should be returned in the Request::metadata, but as libcamera currently does not support that feature temporarily work around the issue and return the FPS range requested by the camera framework. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>