summaryrefslogtreecommitdiff
path: root/src/android
AgeCommit message (Collapse)Author
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: Add CameraHalConfig classJacopo Mondi
Add a CameraHalConfig class to the Android Camera3 HAL layer. 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-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-05-18android: camera_metadata: Add type sanity check to updateEntry()Laurent Pinchart
The CameraMetadata::updateEntry() functions cast the data pointer to a void pointer, which is then used internally to call update_camera_metadata_entry(). If the caller passes a pointer to an incorrect data type, the behaviour is undefined, with possible crashes if the incorrect data type is smaller than expected by the Android metadata library. To avoid crashes, make all public updateEntry() functions take typed pointers, and pass the element size to the internal function. The element size is then checked against the expected size, and an error message logged if they don't match. This won't catch incorrect data types that have the same size as the correct type, but will at least avoid potential crashes. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Tested-by: Paul Elder <paul.elder@ideasonboard.com>
2021-05-18android: camera_metadata: Make internal functions privateLaurent Pinchart
The resize() function and the addEntry() override that takes a void pointer are not meant to be called by the user of the CameraMetadata class. Make them private. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Tested-by: Paul Elder <paul.elder@ideasonboard.com>
2021-05-18android: camera_metadata: Constify argument to addEntry() and updateEntry()Laurent Pinchart
The addEntry() and updateEntry() overrides that take a reference to a container don't need to modify the container. Make it const. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Tested-by: Paul Elder <paul.elder@ideasonboard.com>
2021-05-18android: camera_metadata: Rename sizeofT argument to elementSizeLaurent Pinchart
The sizeofT argument to CameraMetadata::addEntry() stores the size of one element. Its name is a bit cryptic as the function isn't a template function with a typename T. Rename it to elementSize. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Tested-by: Paul Elder <paul.elder@ideasonboard.com>
2021-05-14android: jpeg: post_processor: Use the new metadata 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_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>
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-10 18:13:24 +0000