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

[Laurent Pinchart]

On Thu, Apr 20, 2023 at 08:48:14AM +0200, Jacopo Mondi wrote:
> 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 ?

Yes, but I also want to avoid new ue cases :-) V4L2 should be an
implementation detail that applications shouldn't care about. There are
some transitional use cases that we have to support, and I'd like them
to be exceptions, not a norm.

> > 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 ?

Hotplug is already supported by libcamera, through a signal that
indicates when a camera is plugged in. You can then get the list of
dev_t from the camera. If you want to expose that information in a
different way, you will need a separate hotplug notification to tell
when new dev_t are added or removed.

-- 
Regards,

Laurent Pinchart