RFC: API change: Make CameraManager provide a list of CameraDescription objects

[Hans de Goede]

Hi All,

Currently libcamera opens /dev nodes at camera creation time and keeps them
open as long as the CameraManager exists.

This has a number of advantages:

- This simplifies error handling, no need to worry about problems opening
  /dev nodes after camera creation

- This allows things like CameraConfiguration::validate() to work without
  first needing to do something like call open() or acquire() on the camera

- This is useful for pre-allocating kernelbuffers which may be tied to
  a certain fd and which will be automatically free-ed when closing the fd

But this also has a few disadvantages, which are especially problematic
with long running daemons like pipewire.

- This keeps kernel resources associated to the fds tied-up all the time
- In some cases (e.g. uvcvideo, atomisp, VCM subdevs) this will keep
  the device associated with the /dev node powered up all the time leading
  to a significant increased battery drain

For uvcvideo the increased power-consumption is a really big problem and
a blocker for rolling out pipewire libcamera support in Linux distros (1).

I have discussed how to solve this with Laurent and we have come up with
a proposal to change the libcamera API to move the creation of Camera
objects from the CameraManager to the application, which keeps
the advantages, while removing the resource / power consumption issue
for long running daemons which don't need the camera open the whole time.

The idea is that PipelineHandler::match() will open the /dev nodes
temporarily to collect camera capabilities and then registers
objects of a new CameraDescription class with the CameraManager instead
of directly creating and registering Camera objects.

At the API level this means replacing the cameras list in CameraManager:

        std::vector<std::shared_ptr<Camera>> cameras() const;

with:

        std::vector<std::shared_ptr<CameraDescription>> cameras() const;

Applications can then use the CameraDescription objects to either pick
a camera themselves or e.g. show a choice of available cameras to the user.

Then once a camera has been selected the application can call
CameraManager::get() to get the camera (2), after which everything works
as before.

Input on this proposal is much appreciated, comments anyone ?

Regards,

Hans


1) I've posted a patch with a short-term fix for uvcvideo where
the unwanted power-consumption is a really big problem:
https://lists.libcamera.org/pipermail/libcamera-devel/2024-August/044279.html

2) This requires Camera ids to be unique, which according to:
https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/708
they are not at the moment