| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
The end semicolons with LOG_DECLARE_CATEGORY and
LOG_DEFINE_CATEGORY are unnecessary.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Return the Camera wrapped by the CameraDevice as a shared_ptr.
This will be required to construct the FrameBuffer allocator in
the CameraStream class.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
According to the Android camera HAL C interface documentation, the
camera service is supposed to set callbacks after initializing the HAL
and calling get_number_of_cameras(), before any other calls to the
module. We rely on this behaviour and use callbacks unconditionally,
which would lead to a crash if the camera service behaved incorrectly.
While the camera service isn't supposed to behave incorrectly,
gracefully handling the error when opening cameras isn't costly, and
provides better diagnostic than a crash.
While at it, removed an unneeded [[maybe_unused]] attribute.
Reported-by: Coverity CID=298638
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Umang Jain <email@uajain.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Extend the support for camera hotplug from libcamera's CameraManager
to CameraHalManager. Use camera module callbacks to let the framework
know about the hotplug events and change the status of cameras being
hotplugged or unplugged via camera_device_status_change().
Introduce a map cameraIdsMap_ which book-keeps all cameras seen in the
past by the CameraHalManager. If the camera is seen for the first time,
a new id is assigned to it. If the camera has been seen before by the
manager, its old id is reused. IDs for internal cameras start with
'0' and for external cameras, they start with '1000'. Accesses to
cameraIdsMap_ and cameras_ are protected by a mutex.
Signed-off-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
CameraDevice needs to be wrapper into the std::shared_ptr instead
of std::unique_ptr to enable refcounting. The refcounting will help
us to support hotplug and hot-unplug CameraHalManager operations
in the subsequent commit.
Signed-off-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
camera_module_callbacks are invoked to inform the framework about
the events occurring module-wide. Allow to set these callbacks in
camera_hal_manager as this will be used to integration camera hotplug
support via camera_module_callbacks::camera_device_status_change in
subsequent commit.
Signed-off-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The CameraHalManager::getCameraInfo() method hardcodes the camera facing
side and orientation (which corresponds, confusingly, to libcamera's
location and rotation properties).
Instead of hard-coding the values based on the camera id, inspect the
libcamera properties that report the camera location and rotation in a
new initialize() method, and use them to report the android camera info
and to populate the static metadata buffer.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Report the supported API version in the camera_info structure provided
to the framework.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The libcamera internal headers are located in src/libcamera/include/.
The directory is added to the compiler headers search path with a meson
include_directories() directive, and internal headers are included with
(e.g. for the internal semaphore.h header)
#include "semaphore.h"
All was well, until libcxx decided to implement the C++20
synchronization library. The __threading_support header gained a
#include <semaphore.h>
to include the pthread's semaphore support. As include_directories()
adds src/libcamera/include/ to the compiler search path with -I, the
internal semaphore.h is included instead of the pthread version.
Needless to say, the compiler isn't happy.
Three options have been considered to fix this issue:
- Use -iquote instead of -I. The -iquote option instructs gcc to only
consider the header search path for headers included with the ""
version. Meson unfortunately doesn't support this option.
- Rename the internal semaphore.h header. This was deemed to be the
beginning of a long whack-a-mole game, where namespace clashes with
system libraries would appear over time (possibly dependent on
particular system configurations) and would need to be constantly
fixed.
- Move the internal headers to another directory to create a unique
namespace through path components. This causes lots of churn in all
the existing source files through the all project.
The first option would be best, but isn't available to us due to missing
support in meson. Even if -iquote support was added, we would need to
fix the problem before a new version of meson containing the required
support would be released.
The third option is thus the only practical solution available. Bite the
bullet, and do it, moving headers to include/libcamera/internal/.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Now that libcamera creates threads internally and doesn't rely on an
application-provided event loop, remove the thread from the Android
Camera HAL layer. The CameraProxy class becomes meaningless, remove it
and communicate directly from the CameraHalManager to the CameraDevice.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraManager class is not supposed to be instantiated multiple
times, which led to a singleton implementation. This requires a global
instance of the CameraManager, which is destroyed when the global
destructors are executed.
Relying on global instances causes issues with cleanup, as the order in
which the global destructors are run can't be controlled. In particular,
the Android camera HAL implementation ends up destroying the
CameraHalManager after the CameraManager, which leads to use-after-free
problems.
To solve this, remove the CameraManager::instance() method and make the
CameraManager class instantiable directly. Multiple instances are still
not allowed, and this is enforced by storing the instance pointer
internally to be checked when an instance is created.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraHalManager starts the libcamera CameraManager and creates
CameraProxy instances for each camera in the system. Clean up those
resources when the CameraHalManager terminates.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraHalManager::close() method isn't used, remove it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraHalManager starts a thread that is never stopped. This leads
to the thread being destroyed while running, which causes a crash. Fix
this by stopping the thread and waiting for it to finish in the
destructor of the CameraHalManager.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraHalManager::getCameraInfo() validates the camera id it
receives from the camera service, and in doing so generates a compiler
error with gcc as the id is an unsigned integer and can never be
negative:
../src/android/camera_hal_manager.cpp: In member function ‘CameraProxy* CameraHalManager::open(unsigned int, const hw_module_t*)’:
../src/android/camera_hal_manager.cpp:89:9: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
if (id < 0 || id >= numCameras()) {
Fix it by removing the unneeded comparison.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraHalManager::getCameraInfo() validates the camera id it
receives from the camera service, and in doing so compares it with an
unsigned integer, generating a compiler error:
src/android/camera_hal_manager.cpp:121:9: error: comparison of integers of different signs: 'int' and 'unsigned int' [-Werror,-Wsign-compare]
if (id >= numCameras() || id < 0) {
~~ ^ ~~~~~~~~~~~~
Fix this by turning the id into an unsigned int, as camera ids can't be
negative. If a negative id is received from the camera service it will
be converted to a large unsigned integer that will fail the comparison
with numCameras().
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>
|
|
Add libcamera Android Camera HALv3 implementation.
The initial camera HAL implementation supports the LIMITED hardware
level and uses statically defined metadata and camera characteristics.
Add a build option named 'android' and adjust the build system to
selectively compile the Android camera HAL and link it against the
required Android libraries.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
