diff options
author | Laurent Pinchart <laurent.pinchart@ideasonboard.com> | 2020-01-22 21:30:10 +0200 |
---|---|---|
committer | Laurent Pinchart <laurent.pinchart@ideasonboard.com> | 2020-02-13 12:34:35 +0200 |
commit | 1aa49db823870532adc52ecd6f405b13a4da29ec (patch) | |
tree | 3602b8c9b39cfff7e8b77482c443eb0d646226f5 /test/v4l2_subdevice/test_formats.cpp | |
parent | 09c45cc1faa9805124168de414df7eba007acfee (diff) |
libcamera: camera_manager: Run the camera manager in a thread
Relying on the application event loop to process all our internal events
is a bad idea for multiple reasons. In many cases the user of libcamera
can't provide an event loop, for instance when running through one of
the adaptation layers. The Android camera HAL and V4L2 compatibility
layer create a thread for this reason, and the GStreamer element would
need to do so as well. Furthermore, relying on the application event
loop pushes libcamera's realtime constraints to the application, which
isn't manageable.
For these reasons it's desirable to always run the camera manager, the
pipeline handlers and the cameras in a separate thread. Doing so isn't
too complicated, it only involves creating the thread internally when
starting the camera manager, and synchronizing a few methods of the
Camera class. Do so as a first step towards defining the threading model
of libcamera.
The event dispatcher interface is still exposed to applications, to
enable cross-thread signal delivery if desired.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Diffstat (limited to 'test/v4l2_subdevice/test_formats.cpp')
0 files changed, 0 insertions, 0 deletions