summaryrefslogtreecommitdiff
path: root/src/android
AgeCommit message (Collapse)Author
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-05-05src: android: Rectify internal header's #include pathUmang Jain
libcamera internal headers are not installed system-wide. Hence, any inclusion of internal headers should follow the #include directive form: #include "libcamera/internal/header.h" This was not the case for a few of the class in android HAL. Fix them. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-04-21libcamera: Drop argument from LIBCAMERA_DECLARE_PRIVATEJacopo Mondi
The LIBCAMERA_DECLARE_PRIVATE() macro, used by the library classes that inherit from libcamera::Extensible in order to implement the PIMPL pattern, expands to: public: \ class Private; \ friend class Private; The 'klass' argument is not used and it might confuse developers as it might hint that the class that defines the pattern's implementation can be freely named, while it is actually hardcoded to 'Private'. Drop the argument from the macro definition. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Hanlin Chen <hanlinchen@google.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: 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-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: 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-23android: Return -EUSERS when failed to open a Camera that's in usePaul Elder
The correct return value for the HAL for hal_dev_open() when trying to open a camera that's already opened is EUSERS. Make hal_dev_open() return -EUSERS, and plumb the logic for this through CameraHalManager::open(). This allows the following CTS tests to pass: - android.hardware.camera2.cts.CameraManagerTest#testCameraManagerOpenAllCameras - android.hardware.camera2.cts.MultiViewTest#testDualCameraPreview 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-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-10android: jpeg: exif: change GPS method encoding from ASCII to NoEncodingPaul Elder
According to the EXIF specification, the GPS method should be UNDEFINED, and the first 8 bytes will designate the type. However, CTS expects the first 8 bytes to be part of the data. Remove the 8-byte encoding designator by changing the encoding to NoEncoding to appease CTS. This is part of the fix that allows the following CTS test to pass: - android.hardware.cts.CameraTest#testJpegExif 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-03-10android: jpeg: exif: Fix setGPSLocation longitudePaul Elder
There was a copy-paste error that caused the latitude to be set twice and the longitude never. Fix this. This is part of the fix that allows the following CTS test to pass: - android.hardware.cts.CameraTest#testJpegExif 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> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-10android: jpeg: exif: Simplify setGPSDateTimestamp and setGPSDMSPaul Elder
Now that setRational() supports setting multiple rational values, use that in setGPSDateTimestamp and setGPSDMS which previously set every rational manually. 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> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-10android: jpeg: exif: Fix and expand setRationalPaul Elder
setRational was not working properly for EXIF tags in the GPS IFD due to libexif not supporting those tags in exif_entry_initialize(). Manually specify the size of the EXIF entry to fix this. While at it, add support for setting multiple rationals, as that is a common use case for rational EXIF tags. As Rational types are no longer initialized by libexif directly, the EXIF_TAG_{X,Y}_RESOLUTION exif tags will not have their default values populated. This allows the GPS altitude to be set properly, and is part of the fix to allow the following CTS test to pass: - android.hardware.cts.CameraTest#testJpegExif 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> Reviewed-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>
2021-03-09android: camera_device: Use AE FPS range in templateJacopo Mondi
The request template returned by requestTemplatePreview() uses an arbitrary {15, 30} Auto-Exposure algorithm FPS range. Use the one calculated at static metadata creation time, which is consistent with the camera limits. Once template generation will be performed inspecting the requested capture intent, the FPS range over which the AE algorithm can range shall be tuned accordingly. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-09android: camera_device: Compute frame durationsJacopo Mondi
Use the FrameDuration control reported by pipeline handlers to register the Auto-Exposure routine FPS range, the minimum stream frame durations and the sensor maximum frame duration. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-05android: camera_device: Update gralloc usage flags for streamsLaurent Pinchart
When configuring streams, the camera HAL is supposed to update the gralloc usage flags to reflect the operations it will need to do on the stream buffers. Failure to do so leads to incorrect format selection by gralloc for the HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED format, as gralloc will not take into consideration the need of the camera to access the buffers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03cros: Support the new cros camera API with set_up and tear_downPaul Elder
Implement and expose the symbol and functions that the new cros camera API requires. Since we don't actually need them, leave them empty. Update meson accordingly. 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-03-03android: Introduce Chromium OS buffer managerJacopo Mondi
Introduce the CameraBuffer backend for the Chromium OS operating system and the associated meson option. The Chromium OS CameraBuffer implementation uses the cros::CameraBufferManager class to perform mapping of 1 plane and multiplane buffers and to retrieve size information. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03android: mm: Provide helper macro for PIMPLJacopo Mondi
Each memory backend has to declare a CameraBuffer class implementation that bridges the API calls to each CameraBuffer::Private implementation. As the code is likely the same for most (if not all) backends, provide a convenience macro that expands to the CameraBuffer class declaration. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03android: jpeg: Use CameraBuffer::jpegBufferSize()Jacopo Mondi
Use the newly introduced function to retrieve the size of the JPEG encoding destination buffer, in order to calculate where the JPEG_BLOB_ID should be placed. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03android: camera_buffer: Add method to get the JPEG blob sizeJacopo Mondi
To maintain compatibility with platforms that do not provide a memory backend implementation add a method to be return the size of the buffer used for JPEG encoding capped to a maximum size. Platforms that implement a memory backend will always calculate the correct buffer size. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03android: post_processor: Use CameraBuffer APIJacopo Mondi
Use the newly introduced CameraBuffer class as the type for the destination buffer in the PostProcessor class hierarchy in place of the libcamera::MappedFrameBuffer one and use its API to retrieve the length and the location of the CameraBuffer plane allocated for JPEG post-processing. Remove all the assumption on the underlying memory storage and only go through the CameraBuffer API when dealing with memory buffers. To do so rework the Encoder interface to use a raw pointer and an explicit size to remove access to the Span<uint8_t> maps that serve as memory storage for the current implementation but might not be ideal for other memory backend. Now that the whole PostProcessor hierarchy has been converted to use the CameraBuffer API remove libcamera::MappedBuffer as base class of the CameraBuffer interface and only reply on its interface. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03android: camera_buffer: Implement libcamera::ExtensibleJacopo Mondi
In order to prepare to support more memory backends, make the CameraBuffer class implement the PIMPL (pointer-to-implementation) pattern by inheriting from the libcamera::Extensible class. Temporary maintain libcamera::MappedBuffer as the CameraBuffer base class to maintain compatibility of the CameraStream::process() interface that requires a MappedBuffer * as second argument and will be converted to use a CameraBuffer in the next patch. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
2021-03-03android: Move buffer mapping to CameraStreamJacopo Mondi
The destination buffer for the post-processing component is currently first mapped in the CameraDevice class and then passed to CameraStream which simply calls the post-processor interface. Move the mapping to CameraStream::process() to tie the buffer mapping to the lifetime of the CameraBuffer instance. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>