summaryrefslogtreecommitdiff
path: root/src/android
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: nautilus: Add camera HAL configurationUmang Jain
Nautilus has two in-built cameras, one UVC and one attached to IPU3. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@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-04android: Disallow external location in HAL configUmang Jain
Error out on any camera's location if set to "external", in the HAL configuration file. The HAL configuration file is meant to override the location property, and overriding an internal camera location to external doesn't make sense. 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: Jacopo Mondi <jacopo@jmondi.org>
2021-08-04android: Instantiate CameraDevice after checking HAL config validityUmang Jain
Currently CameraDevice wrapper is created first and then HAL config validity is checked. If the validity checks fail, the code path will simply return, in which case, creating CameraDevice seems a futile exercise. This patch defers the creation of CameraDevice wrapper until the HAL config validity is checked for internal cameras. This will also enable us to infer a few things beforehand, by reading the config file before creating the CameraDevice wrapper. 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-03libcamera: base: class: Don't pass Extensible pointer to Private constructorLaurent Pinchart
The Extensible and Extensible::Private classes contain pointers to each other. These pointers are initialized in the respective class's constructor, by passing a pointer to the other class to each constructor. This particular construct reduces the flexibility of the Extensible pattern, as the Private class instance has to be allocated and constructed in the members initializer list of the Extensible class's constructor. It is thus impossible to perform any operation on the Private class between its construction and the construction of the Extensible class, or to subclass the Private class without subclassing the Extensible class. To make the design pattern more flexible, don't pass the pointer to the Extensible class to the Private class's constructor, but initialize the pointer manually in the Extensible class's constructor. This requires a const_cast as the o_ member of the Private class is const. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-08-02android, controls: Add and plumb MaxLatency controlPaul Elder
Add a MaxLatency control, and plumb it into the HAL accordingly. Bug: https://bugs.libcamera.org/show_bug.cgi?id=50 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-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-08-02android: capabilities: Make keys list into set and member variablePaul Elder
We need to be able to add additional characteristics/request/result keys into the corresponding list in the static metadata based on libcamera camera capabilities. We also need to be able to easily check if the lists have specific keys, for populating templates and result metadata. Turn the characteristics, requests, and results keys vectors into sets, and move them to member variables to achieve this. 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-08-02android: Add helpers for setting android metadata from libcamera controlsPaul Elder
Add helpers for setting android metadata from libcamera controls. There are two versions, for scalars and collections, both of which take a default value to fill in the android control if the libcamera control is not found. They both return the value that was set. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-02android: Add infrastructure for determining capabilities and hardware levelPaul Elder
Add the infrastructure for checking and reporting capabilities. Use these capabilities to determine the hardware level as well. Bug: https://bugs.libcamera.org/show_bug.cgi?id=55 Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-02android: jpeg: get ISO from SENSOR_SENSITIVITYPaul Elder
The data for the exif ISO tag needs to come from SENSOR_SENSITIVITY. Set it. 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-08-02android: metadata: Fix addEntry template typePaul Elder
Since we set entries with android tags directly, which are enums and not arithmetic types, the addEntry template fails to match. Fix this by also allowing enum values in addEntry. 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-08-02android: metadata: Add hasEntry and entryContainsPaul Elder
Add convenience functions for checking if an entry is present in a CameraMetadata instance, and to check if an array entry includes a specific value. 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-07-27android: capabilities: Centralize RAW support checkJacopo Mondi
The validation of RAW stream support is performed in two different places: - At initializeStreamConfigurations() time, by verifying that the libcamera format associated with HAL_PIXEL_FORMAT_BLOB is a Raw format and ensuring the Camera successfully validates it - As initializeStaticMetadata() time by generating a CameraConfiguration for the Raw stream role and ensuring it is a Raw format with a 16 bit depth The first check is used to build the list of supported Raw stream resolutions. The latter is used to register the ANDROID_REQUEST_AVAILABLE_CAPABILITIES_RAW capability. As building the list of supported Raw streams doesn't serve any purpose if the RAW capability is not registered, centralize the Raw format support verification at initializeStreamConfigurations() time by ensuring the supported format is a Raw one with a 16 bit depth. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-07-27android: capabilties: Rationalize get[YUV|Raw]Resolution namesJacopo Mondi
The getYUVResolutions() and getRawResolutions() functions are called from the initializeStreamConfigurations() function, which is called by initialize(). Rationalize the function naming scheme by renaming the two functions to initializeYUVResolutions() and initializeRawResolution(). Cosmetic change only. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-07-27android: capabilities: Use a throw-away config for YUV stream buildingJacopo Mondi
When building the list of supported YUV streams in getYUVResolutions() the CameraConfiguration provided by the caller as first parameters is used. As the CameraConfiguration will be later actually applied to the Camera, avoid any possible overlap of the configuration parameters by using a throw-away CameraConfiguration generated for the Viewfinder stream role in getYUVResolutions(). It's also nicer to avoid having two functions with a similar purpose such as getYUVResolutions() and getRawResolutions() with different parameter lists, as the presence of a CameraConfiguration as first parameter might be confusing to the reader. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2021-07-12libcamera: Drop the LIBCAMERA_D_PTR macro in favour of the _d() functionLaurent Pinchart
Now that all Extensible classes expose a _d() function that performs appropriate casts, the LIBCAMERA_D_PTR brings no real additional value. Replace it with direct calls to the _d() function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 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-07-06android: Disable copy and move for CameraDeviceLaurent Pinchart
Instances of the CameraDevice class should never be copied or moved, as they represent resources, Disable copying and moving for the class. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2021-07-06android: Disable copy and move for CameraHalManagerLaurent Pinchart
The CameraHalManager should be instantiated once only, and never copied or moved. Disable copying and moving. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@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: mm: cros_camera_buffer: Drop undefined functionsLaurent Pinchart
The CameraBuffer::Private::planeAddr() functions are declared but not defined (and of course not used). Drop them. Fixes: d8d6a78f223e ("android: Introduce Chromium OS buffer manager") 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-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: Validate internal headers as privateKieran Bingham
Headers which must not be exposed as part of the public libcamera API should include base/private.h. Any interface which includes the private.h header will only be able to build if the libcamera_private dependency is used (or the libcamera_base_private dependency directly). Build targets which are intended to use the private API's will use the libcamera_private to handle the automatic definition of the inclusion guard. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-06-25libcamera/base: Move span to base libraryKieran Bingham
Move span, and adjust the Doxygen exclusion as well. 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-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 class helpers to the base libraryKieran Bingham
Move the class support infrastructure to the base library. Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@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-25android: cros: Simplify integrationKieran Bingham
The ChromeOS specific Android HAL support was overly-complex to support linking an additional library, and then passing the built object into the libcamera.so build. Now that it has its own distinct libcamera-hal.so, simplify the CrOS integration to build directly into that library. The removal of the -Wno-shadow here is intentional, as it is not required for compilation of the camera3_hal.o object. 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-25android: Split HAL to its own shared libraryKieran Bingham
The libcamera Android HAL implementation should not be an integral part of libcamera, but a support library that utilises the libcamera public API. Move the implementation to its own distinct library. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-06-25android: mm: cros_camera_buffer: Fix wrong indexing in plane()Hirokazu Honda
CameraBuffer::plane() should be accessed in zero based index. Fix the wrong indexing in CameraBuffer::plane() in cros_camera_buffer.cpp. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Paul Elder <paul.elder@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-23android: Sort source files alphabeticallyJacopo Mondi
Sort the list of the Android HAL source file alphabetically. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
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-06-01android: Fix unused parameter warnings on Chrome OSLaurent Pinchart
The Chrome OS-specific code has multiple function parameters that are not used. This results in compilation warnings. Fix them with [[maybe_unused]]. 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-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: CameraHalManager: Create a static object dynamicallyHirokazu Honda
Originally CameraHalManager is created in the libcamera start up and destroyed in the libcamera termination. However, CameraHalManager destructor can access other static objects that has been destroyed. Avoid this issue by destroying CameraHalManager when tear_down() is called in ChromeOS or leaking it in other platforms. 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>