summaryrefslogtreecommitdiff
path: root/src/android
AgeCommit message (Collapse)Author
2021-10-15android: capabilities: Initialize camera state when building propertiesJacopo Mondi
Now that building the list of supported stream configuration requires applying a configuration to the Camera, re-initialize the camera controls by applying a configuration generated for the Viewfinder stream role before building the list of static metadata. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-10-15android: capabilities: Collect per-stream frame durationsJacopo Mondi
Collect the per-stream frame durations while building the list of supported stream formats and resolutions. In order to get an updated list of controls it is necessary to apply to the Camera the configuration we're testing, which was so far only validated. The per-configuration durations will be used to populate the Android ANDROID_SCALER_AVAILABLE_MIN_FRAME_DURATIONS static metadata. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-10-13android: Check if Stream configurations were generated correctlyJavier Martinez Canillas
The libcamera Android Camera HAL generates camera configurations for the StillCapture, Raw and ViewFinder stream roles. But there is only a check if the configuration generation failed, for the StillCapture stream role. This could lead to a NULL pointer dereference if a pipeline handler fails to generate a default configuration for one of the other two stream roles. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-10-12android: camera_device: Fix crash in calling CameraDevice::close()Hirokazu Honda
The problem is happening because we seem to add a CameraStream associated buffer (depending on the CameraStream::Type) to the Request, in CameraDevice::processCaptureRequest(). However, when the camera stops, all the current buffers are marked with FrameMetadata::FrameCancelled and proceed to completion. But the buffer associated with the CameraStream (that was previously added to the request) has now been cleared out with a part of streams_.clear(), even before the camera stop() has been invoked. Any access to those request buffers after they have been cleared, will result in a crash. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-10-10android: camera_stream: Fix error message for buffer creationLaurent Pinchart
Creating a CameraBuffer instance doesn't map memory. Fix the error message accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-10-06android: camera_stream: Set right format for processor output bufferHirokazu Honda
CameraStream always sets the format of processor output buffer to MJPEG. This fixes the issue. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
2021-09-30android: camera_device: Send capture results by inspecting the queueUmang Jain
There is a possibility that an out-of-order completion of capture request happens by calling process_capture_result() directly on error paths. The framework expects that errors should be notified as soon as possible, but the request completion order should remain intact. An existing instance of this is abortRequest(), which sends the capture results on flushing state, without considering order-of-completion. Since we have a queue of Camera3RequestDescriptor tracking each capture request placed by framework to libcamera HAL, we should be only sending back capture results from a single location, by inspecting the queue. As per the patch, this now happens in CameraDevice::sendCaptureResults(). Each descriptor is now equipped with its own status to denote whether the capture request is complete and ready to be send back to the framework or needs to be waited upon. This ensures that the order of completion is respected for the requests. Since we are fixing out-of-order request completion in abortRequest(), change the function to read from the Camera3RequestDescriptor directly, instead of camera3_capture_request_t. The descriptor should have all the information necessary to set the request buffers' state to error. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-09-30android: camera_device: Mark abortRequest() and notifyError() as constUmang Jain
abortRequest() and notifyError() do not modify any members of CameraDevice hence, these functions can be const. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-09-30android: camera_device: Transform descriptors_ map to queueUmang Jain
The descriptors_ map holds Camera3RequestDescriptor(s) which are per-capture requests placed by the framework to libcamera HAL. CameraDevice::requestComplete() looks for the descriptor for which the camera request has been completed and removes it from the map. Since the requests are placed in form of FIFO and the framework expects the order of completion to be FIFO as well, this calls for a need of a queue rather than a std::map. This patch still keeps the same lifetime of Camera3RequestDescriptor as before i.e. in the requestComplete(). Previously, a descriptor was extracted from the map and its lifetime was bound to requestComplete(). The lifetime is kept the same by manually calling .pop_front() on the queue. In the subsequent commit, this is likely to change with a centralized location of dropping descriptors from the queue for request completion. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-09-30android: camera_worker: Use Camera3RequestDescriptor as cookieUmang Jain
Use Camera3RequestDescriptor as cookie for the Capture Request. The cookie is used to lookup descriptors map in CameraDevice::requestComplete(). The map will be transformed to a queue in subsequent commit. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-09-29android: Wait on fences in CameraStream::process()Jacopo Mondi
Acquire fences for streams of type Mapped generated by post-processing are not correctly handled and are currently ignored by the camera HAL. Fix this by adding CameraStream::waitFence(), executed before starting the post-processing in CameraStream::process(). The change applies to all streams generated by post-processing (Mapped and Internal) but currently acquire fences of Internal streams are handled by the camera worker. Postpone that to post-processing time by passing -1 to the Worker for Internal streams. Also correct the release_fence handling for failed captures, as the framework requires the release fences to be set to the acquire fence value if the acquire fence has not been waited on. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Tested-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-09-28android: camera_device: Fix race on queuing capture requestUmang Jain
The Camera3RequestDescriptor containing the capture request is added to the descriptors_ map after a call to CameraWorker::queueRequest(). This is a race condition since CameraWorker::queueRequest() queues requests to libcamera::Camera asynchronously. The requests may thus complete before they get added to descriptors_, in which case requestComplete() will fail to lookup the request in the map. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
2021-09-27android: Fix generation of thumbnail for EXIF dataUmang Jain
Generation of thumbnail is not occuring currently because ANDROID_JPEG_THUMBNAIL_SIZE is not set for request metadata passed to PostProcessorJpeg::process(). The commit 1264628d3c92("android: jpeg: Configure thumbnailer based on request metadata") introduced the mechanism to retrieve the thumbanil size from request metadata, however it didn't add the counterpart i.e. inserting the size in the request metadata in request metadata template, at the first place. The patch fixes this issue by setting ANDROID_JPEG_THUMBNAIL_SIZE in the request metadata template populated by CameraCapabilities::requestTemplatePreview(). The value for ANDROID_JPEG_THUMBNAIL_SIZE is set to be the first non-zero size reported by static metadata ANDROID_JPEG_AVAILABLE_THUMBNAIL_SIZES. Fixes: 1264628d3c92("android: jpeg: Configure thumbnailer based on request metadata") Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-27android: camera_capabilities: Clarify CameraMetadata allocationUmang Jain
CameraMetadata's constructor take in number of entries and number of bytes to be allocated for those entries. However, CameraMetadata is already capable of resizing its container on the fly, in case more entries are added to it. Hence, the numbers passed in during the construction acts as hint values for initialization. Clarify this in CameraCapabilities::requestTemplatePreview() and remove the \todo, as the arguments and the \todo gives the perspective that we need to be quite accurate with the numbers of entries / bytes, which is not the case. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-24android: camera_device: Return unique_ptr from createFrameBufferLaurent Pinchart
Returning a non-managed pointer can cause leaks. Use a unique_ptr<> instead to avoid possible future issues. The std::move() for the planes argument to the FrameBuffer constructor is dropped as it's misleading. FrameBuffer has no constructor that takes an rvalue reference to planes, so the vector was copied despite the move. This only clarifies the intent, no functional change is introduced. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2021-09-22android: camera_device: Configure one stream for identical stream requestsHirokazu Honda
An Android HAL client may request multiple identical streams. It is redundant that a native camera device produces a separate stream for each of the identical requests. Configure the camera with a single stream in that case. The other identical HAL streams will be produced by the YUV post-processor. 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-09-22android: camera_stream: Support PostProcessorYuv in CameraStreamHirokazu Honda
CameraStream creates PostProcessorYuv if the destination format is NV12. 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-09-22android: camera_stream: Create post processor in configure()Hirokazu Honda
CameraStream creates PostProcessor and FrameBufferAllocator in the constructor. CameraStream assumes that a used post processor is JPEG post processor. Since we need to support various post processors, we would rather move the creation to configure() so as to return an error code if no proper post processor is found. This also moves FrameBufferAllocator and Mutex creation for consistency. 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-09-21android: jpeg: Rectify variable naming style.Umang Jain
Rectify variable renaming style for YPlaneSize, UVPlaneSize. libcamera uses camelCase where first letter should be in lower case. Fixes: e355ca0087cd9("android: jpeg: Split and pass the thumbnail planes to encoder") Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-09-21android: yuv: Remove CameraDevice forward-declareUmang Jain
YUV post-processor doesn't need any instance reference from CameraDevice class. Remove it. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-09android: jpeg: Split and pass the thumbnail planes to encoderUmang Jain
After multi-planar support was introduced for jpeg encoding as well, EncoderLibJpeg::encode() expects a vector of planes as the source of framebuffer to be encoded. Currently, we are passing a contiguous buffer which is treated as only one plane (instead of two, as thumbnail is NV12). Hence, split the thumbnail data into respective planes according to NV12. This fixes a crash in encoding of thumbnails. Fixes: 894ca69f6043("android: jpeg: Support multi-planar buffers") Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-09-09android: mm: cros_camera_buffer: Log failure error on cleanupUmang Jain
Failure can still happen by CameraBufferManager during Unlock() and/or Deregister() of camera3Buffer handles. We should be logging those errors as well. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07android: jpeg: Support multi-planar buffersLaurent Pinchart
The JPEG post-processor uses MappedFrameBuffer to access pixel data, but only uses data from the first plane. Pass the vector of planes to the encode() function to correctly handle multi-planar formats (currently limited to NV12). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Umang Jain <umang.jain@ideasonboard.com> Tested-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07android: jpeg: Use stride instead of image width for line addressLaurent Pinchart
When calculating the luma line address, the image width is used instead of the stride. Without padding at the end of the line the the values should be identical, but this is conceptually incorrect in any case. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
2021-09-07android: camera_device: Don't assume all planes use the same fdLaurent Pinchart
Now that libcamera correctly supports frame buffers with different dmabuf for each plane, remove the assumption that a single dmabuf is used. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07libcamera: formats: Add planeSize() helpers to PixelFormatInfoLaurent Pinchart
Add two helpers functions to the PixelFormatInfo class to compute the byte size of a given plane, taking the frame size, the stride, the alignment constraints and the vertical subsampling into account. Use the new functions through the code base to replace manual implementations. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-06android: Cleanup libcamera namespace usageUmang Jain
Usually .cpp files are equipped with using namespace libcamera; Hence, it is unnecessary mentioning the explicit namespace of libcamera at certain places. While at it, a small typo in a comment was noticed and fixed as part of this patch. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-08-31libcamera: mapped_framebuffer: Rename maps() to planes()Hirokazu Honda
MappedFrameBuffer::maps() returns planes_. This renames the function name to planes(). 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-08-31android: generic_camera_buffer: Fix bufferLength_ initializationLaurent Pinchart
The bufferLength_ member variabled is checked to have a positive value before being used, to catch usage before the variable is set. The variable is initialized to zero at construction time, which renders the checks useless. Fix this by initializing the variable to -1 at construction time. Fixes: c5e2ed7806be ("android: camera_buffer: Map buffer in the first plane() call") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-08-31android: Refuse Manual template if not supportedJacopo Mondi
If the camera devices does not support the MANUAL_SENSOR capabilities there is no point in generating a request template for the Manual capture use case. This change fixes CTS tests android.hardware.camera2.cts.CameraDeviceTest#testCameraDeviceManualTemplate android.hardware.camera2.cts.NativeCameraDeviceTest#testCameraDeviceCreateCaptureRequest For devices that do not support MANUAL_SENSOR capabilities. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-30android: camera_device: Fill offset and right length in CreateFrameBuffer()Hirokazu Honda
CameraDevice::CreateFrameBuffer() fills the length of the buffer to each FrameBuffer::Plane::length. It should rather be the length of plane. This also changes CreateFrameBuffer() to fill offset of FrameBuffer::Plane. 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-08-30libcamera: mapped_framebuffer: Return plane begin address by ↵Hirokazu Honda
MappedBuffer::maps() MappedBuffer::maps() returns std::vector<MappedBuffer::Plane>. Plane has the address, but the address points the beginning of the buffer containing the plane. This makes the Plane point the beginning of the plane. So MappedBuffer::maps()[i].data() returns the address of i-th plane. 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-08-27android: camera_buffer: Add stride/offset/size functionHirokazu Honda
This adds getter functions of stride, offset and size to CameraBuffer interface. 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-08-27android: camera_buffer: Map buffer in the first plane() callHirokazu Honda
CameraBuffer implementation maps a given buffer_handle_t in constructor. Mapping is redundant to only know the plane info like stride and offset. Mapping should be executed later in the first plane() call. 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-08-27android: generic_camera_buffer: Correct buffer mappingHirokazu Honda
buffer_handle_t doesn't provide sufficient info to map a buffer properly. cros::CameraBufferManager enables handling the buffer on ChromeOS, but no way is provided for other platforms. Therefore, we put the assumption that planes are in the same buffer and they are consecutive. This modifies the way of mapping in generic_camera_buffer with the assumption. 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-08-16libcamera: base: extensible: Pass private pointer as unique_ptr<>Laurent Pinchart
The Extensible constructor takes a pointer to a Private instance, whose lifetime it then manages. Make this explicit in the API by passing the pointer as a std::unique_ptr<Private>. 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-08-10libcamera: MappedFrameBuffer: Use typed Flags<MapModes>Kieran Bingham
Remove the need for callers to reference PROT_READ/PROT_WRITE directly from <sys/mman.h> by instead exposing the Read/Write mapping options as flags from the MappedFrameBuffer class itself. While here, introduce the <stdint.h> header which is required for the uint8_t as part of the Plane. 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-08-10libcamera: Give MappedFrameBuffer its own implementationKieran Bingham
The MappedFrameBuffer is a convenience feature which sits on top of the FrameBuffer and facilitates mapping it to CPU accessible memory with mmap. This implementation is internal and currently sits in the same internal files as the internal FrameBuffer, thus exposing those internals to users of the MappedFramebuffer implementation. Move the MappedFrameBuffer and MappedBuffer implementation to its own implementation files, and fix the sources throughout to use that accordingly. 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-08-10src: Remove all unused sys/mman.h inclusionsKieran Bingham
Remove leftover inclusions of the sys/mman header file. 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-08-09libcamera: Rename 'method' to 'function'Laurent Pinchart
Usage of 'method' to refer to member functions comes from Java. The C++ standard uses the term 'function' only. Replace 'method' with 'function' or 'member function' through the whole code base and documentation. While at it, fix two typos (s/backeng/backend/). The BoundMethod and Object::invokeMethod() are left as-is here, and will be addressed separately. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-06android: mm: cros_camera_buffer: Fix unused parameterHirokazu Honda
cameraBuffer function in private constructor is unused. Mark it as such. Fixes: 33dd4fab9d39("libcamera: base: class: Don't pass Extensible pointer to Private constructor") Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
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>