[libcamera-devel] [PATCH 0/3] libcamera: Add new Camera devices property

[Jacopo Mondi]

HI Laurent

On Thu, Apr 20, 2023 at 05:57:37AM +0300, Laurent Pinchart wrote:
> On Wed, Apr 19, 2023 at 01:11:39PM +0100, Kieran Bingham via libcamera-devel wrote:
> > On 19/04/2023 10:45, Jacopo Mondi wrote:
> > > On Wed, Apr 19, 2023 at 09:58:18AM +0100, Kieran Bingham via libcamera-devel wrote:
> > >> It can be beneficial to allow reporting the devices used by a camera to
> > >> facilitate de-duplication of resources when handling cameras from a
> > >> centralised infrastructure such as PipeWire.
> > >
> > > This series allows to retrieve the list of dev_t a libcamera::Camera
> > > handles by using a camera properties.
> > >
> > > The CameraManager class however maintains a camerasByDevnum_ map that
> > > associates a dev_t with the Camera it is owned by. It would be trivial
> > > to reverse the map. Have you considered that ? Getting dev_t from the
> > > manager seems more natural than doing so from the Camera (and would
> > > avoid the additional template specialization for dev_t you don't like)
> >
> > No I haven't, so that's an interesting point. I'll take a look.
> >
> > Robert/Wim,
> >
> > Do you have any specific requirements here? Do you need to be able to
> > map which devices are used by each camera? Or is a single list sufficient?
> >
> > Or maybe returning a map of camera (id?) to device list is best all round?
> >
> > My only thought on the separation is the list would have to be
> > re-obtained for hotplugged cameras, while it's available at the 'camera'
> > when on the object. Conversely, perhaps hotplug is a reason to
> > centralize the whole list as after a camera is removed it would need to
> > be updated anyway.
> >
> > So - I'll see if I can add in a call on the Camera Manager that returns
> > a map of camera id / dev_t.
>
> The map we expose through the CameraManager is meant for the V4L2
> adaptation layer only. I'm actually thinking about how we could avoid

It's for V4L2 layer only because so far we had no other use cases,
isn't it ?

> exposing it in the public API. A camera property seems a nicer solution
> for the problem at hand.
>

However it will require getting hold of all camera intances, fetch and
read the properties. As Kieran said with hotplug it gets even worse.
Isn't it better to get it from the manager which maintains an overall
view of all resources in the system ?

> --
> Regards,
>
> Laurent Pinchart