| Age | Commit message (Collapse) | Author |
|---|
|
Set buffer flag V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC at VIDIOC_REQBUFS
after the buffers have been allocated.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Clear the reserved field in arg struct v4l2_reqbuffers of
VIDIOC_REQBUFS.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Free buffers, if any were previously allocated, at VIDIOC_REQBUFS with
count > 0.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Previously, since we acquired the libcamera camera upon open(), it was
impossible to support multiple open, as any subsequent opens would
return error because the camera would already be acquired.
To fix this, we first initialize the camera in the first call to
V4L2CameraProxy::open(), just to heat up the stream format cache. We
then add ownership by a V4L2CameraFile of a V4L2Camera via the
V4L2CameraProxy. All vidioc ioctls prior to reqbufs > 0 (except for
s_fmt) are able to access the camera without ownership. A call to
reqbufs > 0 (and s_fmt) will take ownership, and the ownership will be
released at reqbufs = 0. While ownership is assigned, the eventfd that
should be signaled (and cleared) by V4L2Camera and V4L2CameraProxy is
set to the V4L2CameraFile that has ownership, and is cleared when the
ownership is released. In case close() is called without a
reqbufs = 0 first, the ownership is also released on close().
We also use the V4L2CameraFile to contain all the information specific
to an open instance of the file. This removes the need to keep track of
such information within V4L2CameraProxy via multiple maps from int fd to
info.
Since V4L2 does not expect reqbufs 0 to ever return error, make
V4L2CameraProxy::freeBuffers() return void.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Prepare for using the V4L2CameraFile as a container for file-specific
information in the V4L2 compatibility layer by making it a required
argument for all V4L2CameraProxy calls that are directed from
V4L2CompatManager, which are intercepted via LD_PRELOAD. Change
V4L2CameraFile accordingly.
Also change V4L2CompatManager accordingly. Instead of keeping a map of
file descriptors to V4L2CameraProxy instances, we keep a map of
V4L2CameraFile instances to V4L2CameraProxy instances. When the
proxy methods are called, feed the file as a parameter.
The dup function is also modified, in that it is removed from
V4L2CameraProxy, and is handled completely in V4L2CompatManager, as a
map from file descriptors to V4L2CameraFile instances.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
With relation to opening files, the kernel has three objects related to
files:
- inodes, that represent files on disk
- file objects, that are allocated at open() time and store all data
related to the open file
- file descriptors, that are integers that map to a file
In the V4L2 compatibility layer, V4L2CameraProxy, which wraps a single
libcamera camera via V4L2Camera, is more or less equivalent to the
inode. We also already have file descriptors (that are really eventfds)
that mirror the file descriptors. Here we create a V4L2CameraFile to
model the file objects, to contain information related to the open file,
namely if the file has been opened as non-blocking, and the V4L2
priority (to support VIDIOC_G/S_PRIORITY later on). This new class
allows us to more cleanly support multiple open later on, since we can
move out of V4L2CameraProxy the handling of mapping the fd to the open
file information.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This simply wires up the libcamera sharpness control in the Raspberry
Pi IPAs so that it controls the strength of the Raspberry Pi sharpness
control algorithm.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The sharpness control is, loosely speaking, a gain applied to
the amount of sharpening added to an image. We also report the
sharpness setting used back to the caller in metadata.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
No need for it to be std::atomic as SwitchMode runs synchronously with
Prepare.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The control is a single float value with minimum, default and maximum
values. Please read the description for more details.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Print format names defined in formats namespace instead of the hex
values in toString() as they are easier to comprehend. For this add
a property of 'name' in PixelFormatInfo' so as to map the formats
with their names. Print fourcc for formats which are not used in
libcamera.
Signed-off-by: Kaaira Gupta <kgupta@es.iitr.ac.in>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
When replacing DRM FourCCs with libcamera formats IPU3 format
descriptors where missing resulting in RAW capture not being possible.
Fix this by adding the missing descriptors.
Fixes: 56c99424edd64c5a ("libcamera: pipeline: Replace explicit DRM FourCCs with libcamera formats")
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add an option to control compilation of the qcam test application. The
default behavior is to compile qcam, no change in behavior without user
intervention.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
These formats can be helpful when downstream applications or libraries
support them natively (avoiding a costly conversion).
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The id in the camera name is confusing and is of little use for users.
Camera names are not (yet) required to be unique and appending which
numerical CIO2 unit the sensor is attached to is just as good as
depending on the i2c bus information already present in the entity name.
Before this change,
$ cam -l
Available cameras:
1: ov13858 2-0010 0
2: ov5670 4-0036 1
After this change,
$ cam -l
Available cameras:
1: ov13858 2-0010
2: ov5670 4-0036
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The two public unsigned integer fields of StreamConfiguration, stride
and bufferCount where not initialized, fix this to match other members
being initialized to their 'zero' state.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
mode changes
This commit causes the AGC to recalculate its camera exposure/gain
values when the camera mode changes. For example it's possible
that the exposure profile could be changed by the application so
the division between exposure time and analogue gain may be
different.
The other underlying reason (and which this commit accomplishes too)
is that the sensor's line timing may change in a new mode, and because
V4L2 drivers store a number of exposure _lines_, the resulting _time_
will "change under our feet". So we have to go through the process of
recalculating the correct number of lines and writing this back to the
sensor with every mode switch, regardless of anything else.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This commit adds a Metadata parameter to the SwitchMode method
enabling it to return camera and other settings to the caller
(usually the configure method, just after the camera mode has been
selected).
In future this will allow the Raspberry Pi IPAs to take those settings
(such as exposure and analogue gain) and program them directly into
the camera or ISP before the camera is even started.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Some applications (eg. Firefox, Google Chrome, Skype) use open64,
openat64, and mmap64 instead of their non-64 versions that we currently
intercept. Intercept these calls as well. _LARGEFILE64_SOURCE needs to
be set so that the 64-bit symbols are available and not synonymous to
the non-64-bit versions on 64-bit systems.
Also, since we set _FILE_OFFSET_BITS to 32 to force the various open and
mmap symbols that we export to not be the 64-bit versions, our dlsym to
get the original open and mmap calls will not automatically be converted
to their 64-bit versions. Since we intercept both 32-bit and 64-bit
versions of open and mmap, we should be using the 64-bit version to
service both. Fetch the 64-bit versions of openat and mmap directly.
musl defines the 64-bit symbols as macros that are equivalent to the
non-64-bit symbols, so we put compile guards that check if the 64-bit
symbols are defined.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> # Compile with musl
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Use the new pixel format constants to replace usage of macros from
drm_fourcc.h.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Use the new pixel format constants to replace usage of macros from
drm_fourcc.h.
The IPU3 pipeline handler still uses DRM FourCCs for IPU3-specific
formats that are not defined in the libcamera public API.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Use the new pixel format constants to replace usage of macros from
drm_fourcc.h.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Use the new pixel format constants to replace usage of macros from
drm_fourcc.h.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Use the new pixel format constants to replace usage of macros from
drm_fourcc.h.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
libcamera uses pixel format FourCC and modifier values from DRM. This
requires inclusion of drm_fourcc.h, creating a dependency on a header
that is packaged differently between distributions, and causing possible
issues with third-party applications.
Define constants for the supported pixel formats in the new formats.h
public API header, in order to remove the dependency on drm_fourcc.h.
The header is generated by a Python script from a list of supported
formats. The numerical values for the FourCC and modifier are extracted
from drm_fourcc.h by the script, ensuring that numerical values are not
inadvertently modified and preserving the direct interoperability.
The pixel formats constants can't be generated solely from drm_fourcc.h,
as that header defines FourCC values and modifier values, but doesn't
list the valid combinations. The supported formats are thus stored in a
YAML file, which contains the FourCC and optional modifier for each
supported format. We may later extend the YAML file to include formats
documentation, and possibly formats metadata to populate the
pixelFormatInfo map (in formats.cpp) automatically.
Now that two formats.h header are present (one in include/libcamera/ and
one in include/libcamera/internal/), we need to explicitly qualify the
Doxygen \file directive with a path.
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>
|
|
The return value of the write to the eventfd (to signal POLLIN) from
V4L2Camera and the read from the eventfd (to clear POLLIN) from
V4L2CameraProxy was ignored. Check the return value, and print an error
message.
Reported-by: Coverity CID=290743
Reported-by: Coverity CID=290744
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Fix a typo in the documentation in the StreamConfiguration constructor.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Hook up various QCam UI bits with hotplug support introduced
in previous commits. This looks good-enough as first steps
to see how the hotplugging functionality is turning out to be
from application point-of-view.
One can still think of few edge case nuances not yet covered
under this implementation especially around having only one
camera in the system and hotplugging/hot-unplugging it.
Hence, those are intentionally kept out of scope for now. It
might require some thinking on how to handle it on application
level having additional time on hand.
Signed-off-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Emit 'cameraAdded' and 'cameraRemoved' from CameraManager to enable
hotplug and hot-unplug support in application like QCam.
To avoid use-after-free race between the CameraManager and the
application, emit the 'cameraRemoved' with the shared_ptr version
of <Camera *>. This requires to change the function signature of
CameraManager::removeCamera() API.
Also, until now, CameraManager::Private::addCamera() transfers the
entire ownership of camera shared_ptr to CameraManager using
std::move(). This patch changes the signature of Private::addCamera to
accept pass-by-value camera parameter. It is done to make it clear from
the caller point of view that the pointer within the caller will still
be valid after this function returns. With this change in, we can emit
the camera pointer via 'cameraAdded' signal without hitting a segfault.
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>
|
|
Emit a signal whenever new MediaDevices are added to the
DeviceEnumerator. This will allow CameraManager to be notified
about the new devices and it can re-emumerate all the devices
currently present on the system.
Device enumeration by the CameraManger is an expensive operation hence,
we want one signal emission per 'x' milliseconds to notify multiple
devices additions as a single batch, by the DeviceEnumerator.
Add a \todo to investigate the support for that.
Signed-off-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This commit introduces no functional changes.
Split pipelines creation code into a separate function,
so that the function can be re-used for upcoming hotplug
functionality in subsequent commits.
Also, fixup correct tag for \todo.
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>
|
|
The pipes_ vector was initially used to store pipeline handlers
instances with the CameraManager when it cannot be referenced from
anywhere else. It was used to retrieve cameras and deleting pipeline
handlers when stopping the camera manager.
In f3695e9b09ce ("libcamera: camera_manager: Register cameras with the
camera manager"), cameras started to get registered directly with camera
manager and in 5b02e03199b7 ("libcamera: camera: Associate cameras with
their pipeline handler") pipeline handlers started to get stored in a
std::shared_ptr<> with each camera starting to hold a strong reference
to its associated pipeline-handler. At this point, both the camera
manager and the camera held a strong reference to the pipeline handler.
Since the additional reference held by the camera manager gets released
only on cleanup(), this lurking reference held on pipeline handler did
not allow it to get destroyed even when cameras instances have been
destroyed. This situation of having a pipeline handler instance around
without having a camera may lead to problems (one of them explained
below) especially when the camera manager is still running.
It was noticed that, there was a dangling driver directory issue (tested
for UVC camera - in /sys/bus/usb/drivers/uvcvideo) on 'unbind' → 'bind'
operation while the CameraManager is running. The directories were still
kept around even after 'unbind' because of the lurking reference of
pipeline handler holding onto them. That reference would clear if and
only if the CameraManager is stopped and then only directories were
getting removed in the above stated path.
Rather than writing a fix to release the pipeline handlers' reference
from camera manager on camera disconnection, it is decided to eliminate
the pipes_ vector from CameraManager moving forwards. There is no
point in holding a reference to it from camera manager's point-of-view
at this stage. It also helps us to fix the issue as explained above.
Now that the pipeline handler instances are referenced via cameras only,
it can happen that the destruction of last the camera instance may
result in destruction of the pipeline handler itself. Such a possibility
exists in PipelineHandler::disconnect(), where the pipeline handler
itself can get destroyed while removing the camera. This is acceptable
as long as we make sure that there is no access of pipeline handler's
members later on in the code path. Address this situation and also add a
detailed comment about it.
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>
|
|
If the EXIF directory is empty due to no metadata being available tools
such as tiffinfo complains that the directory is malformed.
TIFFFetchDirectory: Sanity check on directory count failed, this is probably not a valid IFD offset.
TIFFReadCustomDirectory: Failed to read custom directory at offset 0.
Always record the creation time in the EXIF directory instead of adding
complexity to skip creating the EXIF directory if there is no metadata
to record. This ensures there are at least some entries in the EXIF
directory and that makes tiffinfo happy.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Modify toString() to print mbus format name instead of its hex code as
the name is easier to understand.
Signed-off-by: Kaaira Gupta <kgupta@es.iitr.ac.in>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add support for the Bayer formats produced on the IPU3. The format uses
a memory layout that is hard to repack and keep the 10-bit sample size,
therefore scale the samples to 16-bit when creating the scanlines.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
As the ELF parsing code uses non-const pointers to the ELF mapping, we
have to map the module in private read-write mode. This causes issues
with valgrind, due to the IPA manager mapping the module in shared
read-only mode and valgrind having trouble loading debugging symbols
later at dlopen time due to conflicting mappings.
This is likely a bug in valgrind (reported as [1]), but we can easily
work around it by using shared read-only mappings only. As such a
mapping shouldn't be less efficient than private read-write mappings,
switch the mapping type. This requires modifying the ELF parsing
functions to operate on const memory, which is a good idea anyway as
they're not supposed to modify the ELF file.
[1] https://bugs.kde.org/show_bug.cgi?id=422601
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The logic of the code guarantees that the PipelineHandler pointer passed
to the RkISP1Frames constructor is an instance of PipelineHandlerRkISP1.
We can thus use static_cast<> instead of dynamic_cast<>.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Until N4387 (https://wg21.link/N4387, applied as a defect report for
C++11), a function could not return a tuple using
copy-list-initialization. This affects gcc-5 that was released before
N4387 was integrated, and causes a compilation error:
../../src/android/camera_device.cpp: In member function ‘std::tuple<unsigned int, unsigned int> CameraDevice::calculateStaticMetadataSize()’:
../../src/android/camera_device.cpp:391:32: error: converting to ‘std::tuple<unsigned int, unsigned int>’ from initializer list would use explicit constructor ‘constexpr std::tuple<_T1, _T2>::tuple(_U1&&, _U2&&) [with _U1 = unsigned int&; _U2 = unsigned int&; <template-parameter-2-3> = void; _T1 = unsigned int; _T2 = unsigned int]’
return { numEntries, byteSize };
Fix it by using std::make_tuple().
Fixes: a80d38109f65 ("android: camera_device: Calculate metadata size")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Specify the license of the Feather icons files in the .reuse/dep5 file.
Technically speaking the SVG format supports comments, SPDX could thus
be used, but that would be impractical both due to the large number of
files, and the fact that they would then diverge from the upstream
project.
We can remove the README.md file, as it now only contains redundant or
incorrect information: the license and project URL are contained in the
DEP5 file, and the comment related to generation of the GRC file is
outdated as the file is now manually edited to only include the icons
that we need.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Add missing SPDX headers to miscellaneous small files. Use CC0-1.0 for
meson.build, .gitignore and the small include/linux/README, and licenses
matching the corresponding component for other files.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Swap the pipeline handler to use "LGPL-2.1-or-later" license. This is
to unify with the libcamera core source code license.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Starting from Qt v5.15.0, the QTextStreamFunctions::fixed function
used to configure formatting on QTextStream is deprecated in favour of
Qt::fixed. This causes a compilation error:
../src/qcam/main_window.cpp:634:16: error: ‘QTextStream& QTextStreamFunctions::fixed(QTextStream&)’ is deprecated: Use Qt::fixed [-Werror=deprecated-declarations]
634 | << "fps:" << fixed << qSetRealNumberPrecision(2) << fps;
| ^~~~~
Fix it by using Qt::fixed, and provide backward compatibility with Qt
versions older than v5.14.0 that didn't provide Qt::fixed.
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> # 5.12.8
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add an entry for MJPEG in V4L2CameraProxy's PixelFormatInfo list to
allow proper calculation of sizeimage for MJPEG, such that the
parameters to mmap can align properly instead of failing. This allows
MJPEG to be used in the V4L2 compatibility layer.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The V4L2 compatibility layer uses devnum to match video device nodes to
libcamera Cameras. Some pipeline handlers don't report a devnum for
their camera, which prevents the V4L2 compatibility layer from matching
video device nodes to these cameras. To fix this, we first allow the
camera manager to map multiple devnums to a camera. Next, we walk the
media device and entity list and tell the camera manager to map every
one of these devnums that is a video capture node to the camera.
Since we decided that all video capture nodes that belong to a camera
can be opened via the V4L2 compatibility layer to map to that camera, it
would cause confusion for users if some pipeline handlers decided that
only specific device nodes would map to the camera. To prevent this
confusion, remove the ability for pipeline handlers to declare their own
devnum-to-camera mapping. The only pipeline handler that declares the
devnum mapping is the UVC pipeline handler, so remove the devnum there.
We considered walking the media entity list and taking the devnum from
just the one with the default flag set, but we found that some drivers
(eg. vimc) don't set this flag for any entity. Instead, we take all the
video capture nodes (entities with the sink pad flag set).
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Translate the Android format code to the libcamera format code
at stream configuration time, using the translation map built at
camera device initialization time.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Replace the hardcoded stream configuration map with the information
collected at CameraDevice initialization time.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
As we move to have more and more dynamically generated static metadata
entries, the size of the metadata buffer has to be calculated
dynamically inspecting the information collected from the camera.
Provide a method to perform metadata buffers size calculation and
use it when generating camera static metadata.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Initialize the stream configuration map by applying the Android Camera3
requested resolutions and formats to the libcamera Camera device.
For each required format test a list of required and optional
resolutions, construct a map to translate from Android format to the
libcamera formats and store the available stream configuration to
be provided to the Android framework through static metadata.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The NV24 pixelFormatInfo table entry defines an incorrect horizontal
sub-sampling.
Update to the correct value.
Fixes: 29c5508075c1 ("v4l2: camera_proxy: Create format info array")
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The V4L2 compatibility layer keeps track of the index of the next buffer
to be dequeued, to handle VIDIOC_DQBUF. This index is set to 0 on
startup and incremented (modulo #frames), and is otherwise never reset.
This means that if the last handled frame index is not #frames-1, and
the stream is restarted without restarting libcamera and the V4L2
compatilibity layer, the buffer index number won't match with the
libcamera buffer index number, causing a segfault. Fix this by resetting
the current buffer index to zero on VIDIOC_STREAMON.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
