| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
When configuring streams, the camera HAL is supposed to update the
gralloc usage flags to reflect the operations it will need to do on the
stream buffers. Failure to do so leads to incorrect format selection by
gralloc for the HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED format, as
gralloc will not take into consideration the need of the camera to
access the buffers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Implement and expose the symbol and functions that the new cros camera
API requires. Since we don't actually need them, leave them empty.
Update meson accordingly.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Introduce the CameraBuffer backend for the Chromium OS operating system
and the associated meson option.
The Chromium OS CameraBuffer implementation uses the
cros::CameraBufferManager class to perform mapping of 1 plane and multiplane
buffers and to retrieve size information.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Each memory backend has to declare a CameraBuffer class implementation
that bridges the API calls to each CameraBuffer::Private implementation.
As the code is likely the same for most (if not all) backends, provide
a convenience macro that expands to the CameraBuffer class declaration.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Use the newly introduced function to retrieve the size of
the JPEG encoding destination buffer, in order to calculate where
the JPEG_BLOB_ID should be placed.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
To maintain compatibility with platforms that do not provide a memory
backend implementation add a method to be return the size of the buffer
used for JPEG encoding capped to a maximum size.
Platforms that implement a memory backend will always calculate the
correct buffer size.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Use the newly introduced CameraBuffer class as the type for the
destination buffer in the PostProcessor class hierarchy in place of the
libcamera::MappedFrameBuffer one and use its API to retrieve the length
and the location of the CameraBuffer plane allocated for JPEG
post-processing.
Remove all the assumption on the underlying memory storage and only go
through the CameraBuffer API when dealing with memory buffers. To do so
rework the Encoder interface to use a raw pointer and an explicit size
to remove access to the Span<uint8_t> maps that serve as memory storage
for the current implementation but might not be ideal for other memory
backend.
Now that the whole PostProcessor hierarchy has been converted to use
the CameraBuffer API remove libcamera::MappedBuffer as base class
of the CameraBuffer interface and only reply on its interface.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
In order to prepare to support more memory backends, make the
CameraBuffer class implement the PIMPL (pointer-to-implementation)
pattern by inheriting from the libcamera::Extensible class.
Temporary maintain libcamera::MappedBuffer as the CameraBuffer base
class to maintain compatibility of the CameraStream::process() interface
that requires a MappedBuffer * as second argument and will be converted
to use a CameraBuffer in the next patch.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The destination buffer for the post-processing component is
currently first mapped in the CameraDevice class and then passed
to CameraStream which simply calls the post-processor interface.
Move the mapping to CameraStream::process() to tie the buffer
mapping to the lifetime of the CameraBuffer instance.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The buffers passed to the post processor are currently named 'buffer'
and 'mapped', names that do not convey their role.
Use 'src' and 'dest' instead.
Cosmetic change only.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The buffer_handle_t type is defined as 'const native_handle_t*'.
Drop the 'const' specifier from the parameter of the CameraBuffer
class constructor and in the Android generic memory backend.
Also rename 'camera3buffer' in 'camera3Buffer' to comply with the
coding style guidelines.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
In order to provide support for different memory backends,
move the MappedCamera3Buffer class definition outside of the
CameraDevice class to its own file and rename it in CameraBuffer.
The interface defined in camera_buffer.h will be implemented by
different backends that will be placed in the src/android/mm
subdirectory.
Provide a first implementation for the 'generic android' backend
which matches the existing one.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Our android HAL implementation currently does not support external
cameras, so if the camera location property is external, set it to
front.
This allows the following CTS test to pass:
- android.hardware.camera2.cts.CameraManagerTest#testCameraManagerGetDeviceIdList
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
This adds PostProcessorYuv. It supports NV12 buffer scaling
using libyuv.
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>
|
|
The meson.build files mix array declarations with and without a space
after the opening and before the closing square bracket. The vast
majority of cases don't use spaces, so standardize on that.
While it it, fix indentation in a few places.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Calculate the JPEG maximum size using the maximum preview format size
multiplied by a 1.5 factor.
The same multiplication factor is used in the existing HAL
implementations in ChromeOS.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CaptureResultTest#testCameraCaptureResultAllKeys enforces the
presence of the ANDROID_STATISTICS_HOT_PIXEL_MAP_MODE result
metadata.
Report ANDROID_STATISTICS_HOT_PIXEL_MAP_MODE_OFF as the Camera HAL
does not support the generation of an hot pixel correction map.
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>
|
|
The CaptureResultTest#testCameraCaptureResultAllKeys enforces the
presence of the ANDROID_SENSOR_TEST_PATTERN_MODE result metadata.
Report the only supported value of ANDROID_SENSOR_TEST_PATTERN_MODE_OFF.
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>
|
|
The CaptureResultTest#testCameraCaptureResultAllKeys CTS test
enforces the presence of the auto focus mode in the preview
request template.
Add the only supported mode AF_MODE_OFF in the generated template.
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>
|
|
The camera HAL does currently list AF_MODE_OFF as the only supported
auto-focus mode in the ANDROID_CONTROL_AF_AVAILABLE_MODES static
metadata. For this reason reporting AF_MODE_AUTO as scene override
is wrong.
At the moment scene override is disabled in the Camera HAL, but this
is worth a fix nonetheless.
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>
|
|
The CaptureResultTest#testCameraCaptureResultAllKeys enforces the
presence of the ANDROID_CONTROL_AE_EXPOSURE_COMPENSATION result
metadata.
Report 0 as the current value for
ANDROID_CONTROL_AE_EXPOSURE_COMPENSATION in the result metadata
pack.
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>
|
|
The CaptureResultTest#testCameraCaptureResultAllKeys enforces the
presence of the ANDROID_COLOR_CORRECTION_ABERRATION_MODE result
metadata.
Report the only supported value of
ANDROID_COLOR_CORRECTION_ABERRATION_MODE_OFF.
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>
|
|
The list of the available thumbnail sizes is generated from the
list of available JPEG resolution, one for each aspect ratio.
This change fixes the CTS test
android.hardware.cts.CameraTest#testJpegThumbnailSize
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Fix a wrong comment.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
There are build environments where the wrap-based download is prohibited
by "--wrap-mode nodownload". In such cases, libyuv needs to be provided
by the build environment. To support this, this changes the meson file
to first try using a local libyuv, and if it fails, download libyuv code
and build with it as a fallback.
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>
|
|
Android HAL adaptation layer may need image processing, for
example, scaling and format conversion. Libyuv is a general image
processing. This adds libyuv to subprojects, so that it is forked
locally and can be used with Android HAL implementation code.
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 type of the destination buffer in PostProcessor::process() is
libcamera::Span. libcamera::Span is used for one dimension buffer
(e.g. blob buffer). The destination can be multiple dimensions
buffer (e.g. yuv frame). Therefore, this changes the type of the
destination buffer to MappedFrameBuffer.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The current logging to track the status of a Request when running the
Android camera HAL provide the following information:
When a Request is queued to libcamera:
HAL camera_device.cpp:1776 '\_SB_.PCI0.I2C2.CAM0': Queueing Request to libcamera with 1 HAL streams
When a Request completes:
Request request.cpp:268 Request has completed - cookie: 138508601719648
The queueing of a Request reports the number of streams it contains
while the completion of a Request reports the address of the associated
cookie.
This makes very hard to keep track of what Requests have completed, as
the logging associated with a queue/complete event does not allow to identify
a Request easily.
Add two more printouts to make it easier to track a Request life cycle.
To make it possible to print the Request cookie in the CameraDevice
class add a method to access it from the CameraRequest class.
The result looks like the following trace:
Request request.cpp:92 Created request - cookie: 140701719392768
HAL camera_device.cpp:1710 '\_SB_.PCI0.I2C2.CAM0': Queueing request 140701719392768 with 1 streams
HAL camera_device.cpp:1747 '\_SB_.PCI0.I2C2.CAM0': 0 - (4160x3104)[0x00000023] -> (4160x3104)[NV12] (direct)
...
Request request.cpp:268 Request has completed - cookie: 140701719392768
HAL camera_device.cpp:1800 '\_SB_.PCI0.I2C2.CAM0': Request 140701719392768 completed with 1 streams..
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
