| Age | Commit message (Collapse) | Author |
|---|
|
Now that YamlObject supports iteration, the memberNames() function isn't
useful anymore as it can be implemented using utils::map_keys() if
really needed. Drop it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Han-Lin Chen <hanlinchen@chromium.org>
|
|
Replace usage of YamlObject::memberNames() with the more efficient
iterator API.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Han-Lin Chen <hanlinchen@chromium.org>
|
|
Allow using range-based for loops over YamlObject instances by
implementing iterators. New YamlObject::DictAdapter and
YamlObject::ListAdapter adapter classes are introduced to provide
different iterators depending on the object type.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Han-Lin Chen <hanlinchen@chromium.org>
|
|
Existing code is hardcoded to card0. Since recent fedora upgrades, we
have noticed on more than one machine that card1 is present as the
lowest numbered device, could theoretically be higher. This technique
tries every file starting with card and continue only when we have
successfully opened one. These devices with card1 as the lowest device
were simply failing when they do not see a /dev/dri/card0 file present.
Reported-by: Ian Mullins <imullins@redhat.com>
Tested-by: Ian Mullins <imullins@redhat.com>
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The factor used right now in the IPU3 is 8192, as a multiplier of the
estimated gain. This is wrong, as the isp is adding 1.0 to the gain
applied, ie Pout = { Pin * (1 + Gx) }.
Fix it, and to ease the reading, introduce a small helper function.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
As the simple pipeline handler targets simple pipelines on the SoC side,
it often gets used with platforms that have a YUV sensor capable of
outputting different sizes. Extend the heuristics used for pipeline
discovery and configuration to scale as much as possible on the sensor
side, in order to minimize the required bandwidth.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When enumerating the supported configurations, store the corresponding
sensor resolution in the SimpleCameraData::Configuration structure and
use it when configuring the camera, instead of hardcoding the sensor
full resolution. This prepares for support of downscaling in the camera
sensor.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
To prepare for the implementation of a more complex format discovery
method, factor out code that tries a pipeline configuration to a
separate function. No functional change intended.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add a section to the documentation at the top of the file to describe in
a bit more details how the media graph is traversed.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When pipeline configuration fails, print the format returned by the
kernel in addition to the one requested by libcamera, to ease debugging.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
THe FILE object isn't very user-friendly as it requires manual close.
Replace it with File to provide RAII-style resource management in the
YamlParser API.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Dictionaries have a size too, extend the size() function to support
them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Turn the Type enum into an enum class to force qualifying 'List' and
'Dictionary' in the YamlObject namespace scope. This will help avoiding
ambiguities when adding iterator support.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
When a request completes, a debug message is generated to help
identify the request and the number of streams it contains.
The printed number of streams is however the number of output buffers
requested by the camera framework, not the number of streams generated
by libcamera. In facts, some output buffers are generated by
post-processing, and not directly from the camera.
As the debug message prints the libcamera identifier for the Request, it
is more logical to print the number of streams generated by the camera
instead of the total number of streams.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
When creating the list of StreamConfiguration to be requested to the camera,
map NV12 streams of equal size and format together, so that they will be
generated by using the YUV post-processor.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Mapped streams are generated by post-processing and always require a
source buffer to process image data from.
In case a Mapped stream is requested but its source stream is not, it
is required to allocate a buffer on the fly and add it to the
libcamera::Request.
Make sure a source stream is available for all mapped streams, and if
that's not the case, add a dedicated buffer to the request for that
purpose.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Originally buffer allocation was only required for Internal streams
which are not backed by a frame buffer provided by the Android
framework.
Now that mapped streams can be generated without the corresponding
source stream being part of the Android's provided stream list, also
buffers of type Mapped can be required to allocate buffers on demand.
Create CameraStream::allocator_ and the associated mutex unconditionally
for all types of stream.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a sourceStream field to the CameraStream class, meant to contain a
reference to the direct stream which produces actual image data for
streams of type CameraStream::Mapped.
The sourceStream of mapped streams will be used in later patches to make
sure for each Mapped stream at least one libcamera::Stream is queued to
the libcamera::Camera.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a Python version of simple-cam from:
https://git.libcamera.org/libcamera/simple-cam.git
Let's keep this in the libcamera repository until the Python API has
stabilized a bit more, and then we could move this to the simple-cam
repo.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a slightly more complex, and I think a more realistic, example,
where the script reacts to events and re-queues the buffers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add an example to showcase the more-or-less minimal capture case.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add coloring to the log prefix to increase log readability.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Extend the logger to support coloring messages. The log level is
colorized with per-level colors, and the category with a fixed color.
This makes the log output more readable.
Coloring is enabled by default when logging to std::cerr, and can be
disabled by setting the LIBCAMERA_LOG_NO_COLOR environment variable.
When logging to a file with LIBCAMERA_LOG_FILE, coloring is disabled. It
can be enabled for file logging using the logSetFile() function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
If a sensor driver does not support test patterns (e.g. IMX477),
libcamera throws an unnecessary error message during initialisation when
it sets the test pattern to off.
Fix this by moving the error message into setTestPatternMode() where the
pipeline handler explicitly requests to set a test pattern.
Signed-off-by: Naushir Patuck <naush@raspberrypi.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>
|
|
With the recent addition of operator<<() in most libcamera core classes
to replace usage of the toString() function the Request class was left
behind.
Add operator<<() for the Request class and reimplement toString().
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Fix a comment line wrongly indented with spaces instead of tabs.
Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
We always call CameraManager.read_event() and
CameraManager.get_ready_requests(), so to simplify the use merge the
read_event() into the get_ready_requests().
This has the side effect that get_ready_requests() will now block if
there is no event ready. If we ever need to call get_ready_requests() in
a polling manner we will need a new function which behaves differently.
However, afaics the only sensible way to manage the event loop is to use
select/poll on the eventfd and then call get_ready_requests() once,
which is the use case what the current merged function supports.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The format is 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>
|
|
The format is 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>
|
|
The V4L2_MBUS_FMT_* macros that define media bus formats are deprecated.
Use the MEDIA_BUS_FMT_* macros instead.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
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>
|
|
The YVU422 pixel format is defined in both DRM and V4L2. libcamera
already supports YUV422, add support for the opposite chroma order.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Instead of doing an mmap and munmap every time a Request is complete,
mmap all the buffers once at the start of the program.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add 'fb' property to expose the underlying FrameBuffer.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Implement non-contextmanager use to MappedFrameBuffer so that we can
either:
with MappedFrameBuffer(fb) as mfb:
...
or
mfb = MappedFrameBuffer(fb)
mfb.mmap()
...
mfb.munmap()
While at it, improve the error handling a bit.
Note that the mmap() returns self. In other words, one can do this:
mfb = MappedFrameBuffer(fb).mmap()
...
mfb.munmap()
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Implement FrameBufferPlane class and adjust the methods and uses
accordingly.
Note that we don't expose the fd as a SharedFD, but as an int.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add FrameMetadataPlane class and adjust the methods and uses
accordingly.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add Request.__str__() which maps directly to Request::toString().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
We can use Qt directly to accomplish the same as we do with PIL.
A minor downside is that loading MJPEG frame with Qt produces a "Corrupt
JPEG data" warning. The resulting picture looks fine, though. So add a
message handler to ignore that warning.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Move conversion functions from cam_qt.py to helpers.py to clean up the
code and so that they can be used from other cam renderers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
If the log file specified through LIBCAMERA_LOG_FILE can't be opened,
logging is currently completely disabled. This doesn't match the
documented behaviour that tells std::cerr is used instead. Fix it to
match the documentation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
While std::cerr and stderr both target the same file by default, this
may be overridden by applications. Update the documentation to use
std::cerr instead of stderr to be accurate.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The output local variable in Logger::logSetTarget() isn't necessary.
Remove it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
libcamera uses double quotes for #include directives for internal
headers. A few <...> have found their way in the code base over time.
Fix them.
While at it, move an Android header include to the right location.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Commit 8a845ab078c3 ("libcamera: Replace toString with operator<<() for
format classes") incorrectly converted some of the toString() usages,
resulting in pointer values being printed instead of formats. Fix it.
Fixes: 8a845ab078c3 ("libcamera: Replace toString with operator<<() for format classes")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
We create symlinks from the Python bindings build dir to the source dir
so that 1) the build dir can be used to use the bindings, and 2) to
allow modifications of the source .py files to be used right away
without rebuilding.
The symlinks were recently fixed and changed to use absolute paths.
However, absolute paths ruin one main use case I have: using the
bindings from the build dir via nfs from an ARM device.
So move back to relative paths, but accomplish this with the --relative
parameter for ln, instead of guessing the right relative path as was
done before the above-mentioned fix.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Generate bindings for properties in a very similar way as done for
controls. We do need to distinguish between the two, and thus I added
--properties flag to gen-py-controls.py.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Perhaps it's better to have a more descriptive name here. I also
considered just renaming 'efd' to 'fd', but 'event_fd' won.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add ControlInfo class and change the controls related methods to
resemble the C++ API (e.g. no more string based control methods).
We don't implement ControlList or ControlInfoMap but just expose the
same data via standard Python dict.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The Python bindings controls generation was not very good. It only
covered the enums and they were in the main namespace.
This adds the controls somewhat similarly to the C++ side. We will have
e.g.:
libcamera.controls.Brightness
libcamera.controls.AeMeteringModeEnum.CentreWeighted
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
