With support for metadata in the streams API, the v4l2_meta_format
structure has been extended with width, height and bytesperline fields.
Support them in the V4L2VideoDevice getFormat() and setFormat()
functions is the video device is meta capture device and if the
pixel format is one of the generic line-based metadata formats.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Source files in libcamera start by a comment block header, which
includes the file name and a one-line description of the file contents.
While the latter is useful to get a quick overview of the file contents
at a glance, the former is mostly a source of inconvenience. The name in
the comments can easily get out of sync with the file name when files
are renamed, and copy & paste during development have often lead to
incorrect names being used to start with.
Readers of the source code are expected to know which file they're
looking it. Drop the file name from the header comment block.
The change was generated with the following script:
----------------------------------------
dirs="include/libcamera src test utils"
declare -rA patterns=(
['c']=' \* '
['cpp']=' \* '
['h']=' \* '
['py']='# '
['sh']='# '
)
for ext in ${!patterns[@]} ; do
files=$(for dir in $dirs ; do find $dir -name "*.${ext}" ; done)
pattern=${patterns[${ext}]}
for file in $files ; do
name=$(basename ${file})
sed -i "s/^\(${pattern}\)${name} - /\1/" "$file"
done
done
----------------------------------------
This misses several files that are out of sync with the comment block
header. Those will be addressed separately and manually.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Commit f25ad4a2b1 ("libcamera: formats: Reimplement V4L2
PixelFormatInfo::info()") changed the PixelFormatInfo::info(const
V4L2PixelFormat &format) function overload to:
return info(format.toPixelFormat());
As part of the series that contains such commit, the PixelFormatInfo for the
pixel format applied to a video device is now retrieved at
V4L2VideoDevice::open() time. Some video devices register formats not
available to applications, for example metadata formats or, in the case
of ISP devices, formats to describe the ISP statistics and parameters.
This causes the
format.toPixelFormat()
call to output a WARN message, which spams the log and unnecessarily alerts
the users.
Augment V4L2PixelFormat::toPixelFormat() with an optional argument to
suppress warnings in the case a V4L2 pixel format is not known, to
restore the behaviour preceding commit f25ad4a2b1 and returns an
invalid PixelFormatInfo without outputting any unnecessary warning
message.
Fixes: f25ad4a2b1 ("libcamera: formats: Reimplement V4L2 PixelFormatInfo::info()")
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
The V4L2_PIX_FMT_JPEG and V4L2_PIX_FMT_MJPEG formats are under-specified
and are used interchangeably by kernel drivers.
Map both of them to formats::MJPEG and use the newly re-introduced
V4L2VideoDevice::toV4L2PixelFormat() to map to the one actually used by
the video device.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
Multiple V4L2 formats can be associated with a single PixelFormat.
Now that users of V4L2PixelFormat::fromPixelFormat() have been converted
to use V4L2VideoDevice::toV4L2PixelFormat(), return the full list of
V4L2 formats in order to prepare to match them against the ones
supported by the video device.
The V4L2 compatibility layer, not having any video device to interact
with, is converted to use the first returned format unconditionally.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
To each libcamera PixelFormat two V4L2 formats are associated, the
'single' and 'multi' format variants.
The two versions list plane contiguous and non-contiguous format
variants, and an optional argument to V4L2PixelFormat::fromPixelFormat()
was used to select which one to pick.
In order to prepare to remove V4L2PixelFormat::fromPixelFormat(), and
considering that no caller in the codebase uses the non-contiguous
format variant, merge the two formats vectors in a single one and
default the selection to the first available one, which is functionally
equivalent to what is currently implemented.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
Extend planar YUV format support with 4:4:4 formats. Those formats are
used by the i.MX8 ISI driver that will be supported by the simple
pipeline handler.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Add V4L2 description strings to the map of V4L2 formats. To achieve
this, create an Info struct to wrap them. Update the one current user of
the old map.
This will be used later in the V4L2 compatibility layer to report the
V4L2 format description.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
V4L2 describes multi-planar formats with different 4CCs depending on
whether or not the planes are stored contiguously in memory. Support
this when translating between PixelFormat and V4L2PixelFormat.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Move the functionality for the following components to the new
base support library:
- BoundMethod
- EventDispatcher
- EventDispatcherPoll
- Log
- Message
- Object
- Signal
- Semaphore
- Thread
- Timer
While it would be preferable to see these split to move one component
per commit, these components are all interdependent upon each other,
which leaves us with one big change performing the move for all of them.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
We build libcamera with -Wno-unused-parameter and this doesn't cause
much issue internally. However, it prevents catching unused parameters
in inline functions defined in public headers. This can lead to
compilation warnings for applications compiled without
-Wno-unused-parameter.
To catch those issues, remove -Wno-unused-parameter and fix all the
related warnings with [[maybe_unused]].
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>
The libcamera source files are named after class names, using
snake_case. pixelformats.h and pixelformats.cpp don't comply with that
rule. Fix them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
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>
Add the 8-, 10- and 12-but Bayer formats, in both unpacked and
MIPI-packed variants, to the format tables in PixelFormatInfo and
V4L2PixelFormat.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
To prepare for storing more information about pixel formats in
PixelFormatInfo, move the class to formats.cpp and document it. The
pixel formats database is moved to the same file, and a new static
function is added to PixelFormatInfo to retrieve a PixelFormatInfo for a
PixelFormat.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Replace the two big manual switch...case with maps. This should not just
improve efficiency when we will have a larger number of formats, but
also paves the way to storing more format information to create
additional helpers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
