summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2024-09-02libcamera: libcamera: Remove unused includesMilan Zamazal
The includes that are not used can be removed. Additionally, add some directly used includes not listed. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-09-02libcamera: v4l2: Fix indirect includeMilan Zamazal
Use the direct include of V4L2PixelFormat. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-09-02libcamera: v4l2: Fix an include placementMilan Zamazal
Put the inclusion of geometry.h to the right place. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-09-02libcamera: v4l2: Remove unused includesMilan Zamazal
The includes that are not used can be removed. Also, some directly used includes not listed are added. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-09-02libcamera: uvcvideo: Fix includesMilan Zamazal
The includes that are not used can be removed and there are also directly used includes not listed. Let's fix both. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-09-02libcamera: libipa: Remove unused includesMilan Zamazal
The includes that are not used can be removed. And two identified missing includes (directly used but available only through other includes) are added. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-09-02libcamera: rkisp1: Formatting improvementsMilan Zamazal
The LSP autoformatter doesn't like some of the current formatting, let's make it happier. Note that not all of its suggestions were accepted because readability is preferred and adjusting .clang-format may not be easy or possible. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-09-02libcamera: rkisp1: Remove unused includesMilan Zamazal
The includes that are not used can be removed. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-09-02libcamera: ipu3: Formatting improvementsMilan Zamazal
The LSP autoformatter doesn't like some of the current formatting, let's make it happier. Note that not all of its suggestions were accepted because readability is preferred and adjusting .clang-format may not be easy or possible. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-09-02libcamera: ipu3: Replace wrong includeMilan Zamazal
v4l2_videodevice.h is not used but logging is imported through it. Remove the unused include and include log.h instead. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-09-02libcamera: ipu3: Remove unused includesMilan Zamazal
The includes that are not used can be removed. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-30pipeline: uvcvideo: Implement acquireDevice() + releaseDevice()Hans de Goede
The uvcvideo pipeline handler always keeps the uvcvideo /dev/video# node for a pipeline open after enumerating the camera. This is a problem for uvcvideo, as keeping the /dev/video# node open stops the underlying USB device and the USB bus controller from being able to enter runtime-suspend causing significant unnecessary power-usage. Implement acquireDevice() + releaseDevice(), openening /dev/video# on acquire and closing it on release to fix this. And make validate do a local video_->open() + close() around validate() when not open yet, to keep validate() working on unacquired cameras. Bug: https://bugs.libcamera.org/show_bug.cgi?id=168 Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-30libcamera: camera: Use invokeMethod() for pipe_->acquire() and pipe_->release()Hans de Goede
The uvcvideo driver needs to open / close its /dev/video# node from pipe_->acquireDevices() / pipe_->releaseDevices(). V4L2VideoDevice::open() creates an EventNotifier and this notifier needs to be created from the CameraManager thread. Use invokeMethod() for pipe_->acquire() and pipe_->release() so that the EventNotifiers are created from the CameraManager thread context. Running pipe_->acquire() and pipe_->release() from the CameraManager thread context serializes all calls to them. Drop PipelineHandler::lock_ this now is no longer necessary and update the "\context" part of the documentation for acquire[Device]() and release[Device]() to match. Note the delayed opening of /dev/video# is a special case because the kernel uvcvideo driver powers on the USB device as soon as /dev/video# is opened. This behavior should *not* be copied by other pipeline handlers. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-30pipeline_handler: Add acquireDevice() function to mirror releaseDevice()Hans de Goede
libcamera always keeps all /dev/video# and /dev/v4l2_subdev# nodes for a pipeline open after enumerating the camera. This is a problem for the uvcvideo pipeline handler. Keeping /dev/video# open stops the UVC USB device from being able to enter runtime-suspend causing significant unnecessary power-usage. Add a stub acquireDevice() function to the PipelineHandler class which pipeline handlers can override. The uvcvideo pipeline handler will use this to delay opening /dev/video# until the device is acquired. This is a special case because the kernel uvcvideo driver powers on the USB device as soon as /dev/video# is opened. This behavior should *not* be copied by other pipeline handlers. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Harvey Yang <chenghaoyang@chromium.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-27ipa: rkisp1: blc: Add support for BLS in compandPaul Elder
Extend the RkISP1 BLC algorithm to use the ISP 'companding' block for versions of the ISP (such as the one on the i.MX8MP) that lack the dedicated BLS block but implement BLS as part of the companding block. As access to the companding block requires the extensible parameters format, disable BLC when using the legacy parameters format on i.MX8MP to avoid crashes at runtime with older kernels. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
2024-08-27ipa: rkisp1: Add compand feature flag to ipa contextPaul Elder
Add a compand feature flag to the hardware settings section of the IPA context, so that we can act accordingly for black level subtraction, and to pave the way to skipping companding appropriately when support for it is added. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
2024-08-27ipa: rkisp1: params: Add companding blocksLaurent Pinchart
Extend the RkISP1 parameters helper with support for the new companding blocks. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-27pipeline: rkisp1: Use the extensible parameters formatJacopo Mondi
Now that the IPA module supports the extensible parameters format, switch to it when available. If the kernel driver doesn't support the new format, setFormat() will adjust paramFormat to the legacy format, which will be passed to the IPA module, preserving backward compatibility. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-27ipa: rkisp1: Use the new ISP parameters abstractionLaurent Pinchart
Use the new ISP parameters abstraction class RkISP1Params to access the ISP parameters in the IPA algorithms. The class replaces the pointer to the rkisp1_params_cfg structure passed to the algorithms' prepare() function, and is used to access individual parameters blocks. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
2024-08-27ipa: rkisp1: Add ISP parameters abstraction classLaurent Pinchart
Individual algorithms of the rkisp1 IPA module access their corresponding ISP parameters through the top-level structure rkisp1_params_cfg. This will not work anymore with the new parameters format. In order to ease the transition to the new format, abstract the ISP parameters in a new RkISP1Params class that offers the same interface regardless of the format. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
2024-08-27ipa: rkisp1: Pass parameters buffer size to pipeline handlerJacopo Mondi
The ISP parameters buffer currently has a fixed payload size, which is hardcoded in the pipeline handler. To prepare for support of the extensible parameters format that has a variable payload size, pass the size from the IPA module to the pipeline handler explicitly. Keep the size hardcoded to sizeof(struct rkisp1_params_cfg) for now, this will be udpated later. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-27ipa: rkisp1: Pass parameters buffer format to IPA moduleLaurent Pinchart
The rkisp1 driver supports two formats for the ISP parameters buffer, the legacy fixed format and the new extensible format. In preparation of support for the new format, pass the parameters buffer format from the pipeline handler to the IPA module and store it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-25libcamera: controls: Fix example for ExposureValueFang Hui
EV = [-2, -1, 0.5, 0, 0.5, 1, 2] should change to EV = [-2, -1, -0.5, 0, 0.5, 1, 2] Signed-off-by: Fang Hui <hui.fang@nxp.com> Reviewed-by: Harvey Yang <chenghaoyang@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-25libcamera: pipeline_handler: Call releaseDevice() before unlocking media devicesHans de Goede
It is better / more logical to call releaseDevice() before unlocking the devices. At the moment the only pipeline handler implementing releaseDevice() is the rpi pipeline handler which releases buffers from its releaseDevice() implementation. Releasing buffers before unlocking the media devices is ok to do and arguably it is better to release the buffers before unlocking. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Harvey Yang <chenghaoyang@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-25libcamera: pipeline_handler: Fix unlocking media devices too earlyHans de Goede
PipelineHandler::acquire() only locks the media devices when the first camera is acquired. If a second camera of a pipeline is acquired only useCount_ is increased and nothing else is done. When releasing cameras PipelineHandler::release() should only unlock the media devices when the last camera is released. But the old code unlocked on every release(). Fix PipelineHandler::release() to only release the media devices when the last camera is released. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Harvey Yang <chenghaoyang@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-16libcamera: controls: Improve formatting of control descriptions in YAMLLaurent Pinchart
The control descriptions from YAML files are extracted to generate Doxygen documentation blocks for the controls, which are then compiled to HTML. The extraction script uses the first line of the description as the Doxygen \brief, and preserves blank lines to keep paragraphs. The control descriptions in the YAML files have however not all been written with this in mind. Many description elements are not formatted as block string scalars, in the first place, so blank lines are lost when parsing YAML. Furthermore, they often start with a long initial paragraph, making the \brief description very long. Improve the documentation formatting by marking all multiline descriptions as block string scalars, and try to provide a short one-line first paragraph to be used as a \brief. While at it, reflow the documentation to the 80 columns limit. The draft controls are left as-is, as they should evolve to non-draft controls eventually (and ideally sooner than later). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-08-16py: gen-py-controls: Convert to jinja2 templatesLaurent Pinchart
Jinja2 templates help separate the logic related to the template from the generation of the data. The python code becomes much clearer as a result. As an added bonus, we can use a single template file for both controls and properties. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Acked-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-16py: gen-py-controls: Use Control classLaurent Pinchart
Replace manual extraction of data from YAML with the Control helper class. This centralizes YAML parsing and avoids manual mistakes. In order to import the controls module, add the utils/codegen/ directory to the PYTHONPATH through the Python build environment. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-16utils: codegen: gen-controls.py: Move helper classes to separate fileLaurent Pinchart
The ControlEnum and Control helper classes defined in gen-controls.py are useful for other generator scripts. Move them to a separate file to make it possible to share them. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-08-16utils: codegen: gen-controls.py: Convert to jinja2 templatesLaurent Pinchart
Jinja2 templates help separate the logic related to the template from the generation of the data. The python code becomes much clearer as a result. As an added bonus, we can use a single template file for both controls and properties. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-16meson: utils: Provide environment for Python scriptsLaurent Pinchart
Python scripts run as part of the build process need to take a few actions specific to the environment in which they operate. One of those is disabling the Python bytecode cache, to avoid writing .pyc files to the source tree. This is done manually in the IPC generate.py and parser.py scripts. The current implementation is not ideal because it hardcodes in the scripts information related to the environment in which they operate. As those scripts are part of libcamera this is more of a theoretical issue than a practical one. A second issue is that future Python scripts will need to duplicate similar mechanisms, resulting in a higher maintenance burden. Address the issue with a different approach, by creating a meson environment for the Python scripts, and passing it to the custom_target() functions. The environment only disables the bytecode cache for now. The diffstat shows an increase in code size. This is expected to be offset by usage of the environment for more Python scripts, as well as support of more variables in the environment. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-15libcamera: Drop remaining file names from header comment blocksLaurent Pinchart
Commit 829acb3ab0b1 ("libcamera: Drop file name from header comment blocks in templates") dropped file names from header comment blocks in templates, but forgot the control and property .cpp templates. Fix it. Fixes: 829acb3ab0b1 ("libcamera: Drop file name from header comment blocks in templates") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-15meson: Fix mismatch in controls and properties generated file namesLaurent Pinchart
The header for controls and properties are generated from the control_ids.h.in and property_ids.h.in templates respectively, and the generated files are named control_ids.h and property_ids.h. For sources, the templates are named control_ids.cpp.in and property_ids.cpp.in, but the output files are named controls_ids.cpp and properties_ids.cpp. This discrepancy causes confusion. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-15meson: Store controls and properties YAML files in variablesLaurent Pinchart
When generating control headers, the YAML files to be used are determined dynamically based on the selected pipeline handlers. As part of this process, the build system populates an array of meson File objects used as an input for the control headers generation custom target, as well as an array of file names (as strings). The file names array is later used to generate the control source files for the libcamera core, as well as the source code for controls support in the Python bindings. Both of the source code generators manually turn the array of file names into File objects. This duplicates code and reduces readability. A third similar implementation has also been proposed to generate control support sources in the GStreamer element, making the issue worse. To simplify this, store File objects instead of file names in the controls_files array. As the meson configuration summary doesn't support File objects, create a separate controls_files_names to store the file names for that sole purpose. The exact same process occurs for properties, address them the same way. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-14libcamera: camera: Hide Camera::create() from the public APILaurent Pinchart
The Camera::create() function is internal. Hide it from the public API documentation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-08-14Documentation: Split public/private documentationDaniel Scally
The API reference pages generated by Doxygen are comprehensive, but therefore quite overwhelming for application developers who will likely never need to use the majority of the library's objects. To reduce the complexity of the documentation, split it into two runs of doxygen. The first run of doxygen is for the public API. We pass a specific list of source files to parse, which is built from the arrays of public headers and sources in meson build files. This ensures that we only generate the documentation for code from those files. A custom Python script is needed to add the list of input files to Doxyfile, as several of the objects included in the header and source array are custom_tgt objects, which can't be handled as strings to populate a variable in the configuration data. The headers defining the Extensible and Object classes (class.h and object.h respectively), as well as the corresponding source files, are excluded from the public API documentation despite being referenced in the meson public headers and sources arrays. This is due to the fact that public API classes inherit from Extensible and Object, making the Extensible and Object classes part of the public ABI. Those two base classes are however implementation details and must not be accessed directly by application code. The second run of doxygen is for the internal API. This contains documentation for all of the library's objects as it currently does. This set will now be output into build/Documentation/internal-api-html. Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-08-14Documentation: Add Thread safety pageDaniel Scally
Move the section of the Thread support page dealing with thread safety to a dedicated .dox file at Documentation/. This is done to support the splitting of the Documentation into a public and internal version. With a separate page, references can be made to thread safety without having to include the Thread class in the doxygen run. Some sections of the new page are still specific to internal implementations and so are hidden with the \internal flag and an internal section which is conditionally included. For now, hardcode it to be included in the Doxyfile. Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-12py: cam: Convert to PyQt6Tomi Valkeinen
Qt5 is now end of life. The libcamera 'qcam' application has removed support for Qt5, and updated to Qt6. Update the python 'cam' application accordingly to Qt6. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-12libcamera: simple: Fix a typo in a doc stringMilan Zamazal
Rectify incorrect phrase in the sentence -- s/their share/they share/. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-12ipa: libipa: Add missing CameraSensorHelper fn label in docsMilan Zamazal
The constructor reference was missing, causing the constructor documentation to appear in blackLevel() documentation. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> 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>
2024-08-12libcamera: formats: Adding Support for Y12Pwill whang
Add support for a 12-bit Mono format named formats::R12_CSI2P. This format is added to support the IMX585 mono sensor, which uses the MEDIA_BUS_FMT_Y12_1X12 media bus format. Signed-off-by: will whang <will@willwhang.com> Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-08-12libcamera: Fix header groupingLaurent Pinchart
The libcamera coding style groups the C and C++ standard library headers in a single group. Fix the few offenders in the source tree. While at it, add a missing blank line between header groups in a separate location. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-08-08libcamera: udev: Catch udev notification errorsKieran Bingham
The udev_monitor_receive_device() can return NULL on an error as detailed in the man pages for the function. The udevNotify() handler in the DeviceEnumeratorUdev directly uses the return value of udev_monitor_receive_device() in successive calls to process the event without having first checked the udev_device. Ensure we identify, and handle events where the udev_device can not be returned successfully. Bug: https://bugs.libcamera.org/show_bug.cgi?id=230 Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-08-07libcamera: ipa_manager: Remove singleton requirementLaurent Pinchart
The IPAManager class implements a singleton pattern due to the need of accessing the instance in a static member function. The function now takes a pointer to a PipelineHandler, which we can use to access the CameraManager, and from there, the IPAManager. Add accessors to the internal API to expose the CameraManager from the PipelineHandler, and the IPAManager from the CameraManager. This requires allocating the IPAManager dynamically to avoid a loop in includes. Use those accessors to replace the IPAManager singleton. Update the IPA interface unit test to instantiate a CameraManager instead of an IPAManager and ProcessManager, to reflect the new way that the IPAManager is accessed. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-08-07gstreamer: Fix missing "greater than" symbol in author stringJaslo Ziska
Signed-off-by: Jaslo Ziska <jaslo@ziska.de> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-07libcamera: Don't add libcamera_public_headers to libcamera_public_sourcesLaurent Pinchart
Now that libcamera_internal_sources is separate from libcamera_internal_headers, perform the same split for libcamera_public_sources and libcamera_public_headers to ensure consistency of the build system variables. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-08-07libcamera: Consolidate tracepoint header in libcamera_internal_headersLaurent Pinchart
The libcamera_tracepoint_header variable stores the tracepoints.h header custom target, for the sole purpose of being listed as a source of the libcamera shared library, through the libcamera_internal_sources variable. Add the tracepoints.h header to libcamera_internal_headers instead of libcamera_internal_sources, and list libcamera_internal_headers as a source of the shared library, alongside libcamera_internal_sources. This makes libcamera_internal_sources contain sources only, improving clarity of the build system variables. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-08-07libcamera: Consolidate all IPA headers in libcamera_ipa_headersLaurent Pinchart
The IPA headers are listed in two different meson variables, one for generated headers, and one for the other headers. There's no real reason for this split, consolidate all of them in the libcamera_ipa_headers variable. While at it, don't add the IPA headers to the libcamera_internal_sources variable, but list libcamera_ipa_headers in the sources for the shared library. This moves the libcamera_internal_sources variable towards holding source files, not header files, to improve clarity of the build system. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-08-07libcamera: Move IPA headers to the libcamera_private dependencyLaurent Pinchart
The IPA headers are listed in the libcamera_public and libcamera_private dependency objects, with the generated headers part of the private dependency object and the non-generated headers part of the public dependency object. As neither set of IPA headers are part of the public API, list them both in the libcamera_private dependency object. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-08-07libcamera: Drop libcamera_generated_ipa_headers from sourcesLaurent Pinchart
The libcamera_generated_ipa_headers variable, containing the list of generated IPA headers, is listed in the sources of IPA modules, as well as IPA tests. This was done to ensure that the modules and tests get rebuilt when the generate IPA headers change. However, the dependency is already handled through the libcamera_private dependency object, specified for all those modules and tests. There's no need to list the IPA generated headers as sources. Drop them. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>