[libcamera-devel] [PATCH] android: camera_hal_manager: Fail on no cameras

[Jacopo Mondi]

Hi Tomasz,

On Wed, Jul 22, 2020 at 08:10:03PM +0200, Tomasz Figa wrote:
> On Wed, Jul 22, 2020 at 7:56 PM Laurent Pinchart
> <laurent.pinchart at ideasonboard.com> wrote:
> >
> > Hi Tomasz,
> >

snip

> > > >>>>> I was going to ask how does it register camera's it doesn't know will
> > > >>>>> exist, but I think I saw that the UVC HAL just pre-allocates some
> > > >>>>> cameras or such, so that explains how that one works.
> > > >>>>>
> > > >>>>
> > > >>>> I see three cases:
> > > >>>> 1) No uvc support
> > > >>>>    Defer until a pipeline handler is matched and has registered
> > > >>>>    cameras
> > > >>>>
> > > >>>> 2) UVC only
> > > >>>>    Need to pre-register cameras and activate on hot-plug. Knowing when
> > > >>>>    this has to happen is tricky, as the HAL needs to know it should
> > > >>>>    not wait for built-in cameras and can proceed to register
> > > >>>>    non-active USB cameras
> > > >>>>
> > > >>>> 3) built-in + UVC
> > > >>>>    Simmilarly, knowing we have to wait for built-in to appear, we
> > > >>>>    defer until cameras are available, then pre-register UVC cameras.
> > > >>>>
> > > >>>> The hard part I think it is to define how to instruct the HAL it has
> > > >>>> to wait for built-in to appear or not before registering UVC
> > > >>>> non-active cameras.
> > > >>>
> > > >>> My suggestion is (not blocking this patch, but on top) to do so by
> > > >>> treating static cameras and hotpluggable cameras in the same way.
> > > >>>
> > > >>> It's just that static cameras will never 'unplug' (unless someone
> > > >>> unbinds them? but we all know how bad that mess would get with V4L2 anyway)
> > > >>
> > > >> As explained above, this is unfortunately not an option. To make this
> > > >> matter more complicated, we need to wait for *all* built-in cameras to
> > > >> be available before initializing, as otherwise the system will be
> > > >> permanently stuck with only part of the cameras available.
> > > >>
> > > >> I think this isn't something we should solve, the system should ensure
> > > >> that device nodes have been created before starting the camera service.
> > > >
> > > > Yes, given what you've clarified, then I agree - the service should be
> > > > dependent upon the devices being brought up. I think systemd can do
> > > > that, but CrOS uses upstart, so I don't know what that might support.
> > >
> > > As ugly as it sounds, we have an udev rule which restarts the camera
> > > service when devices matching the internal cameras show up. I believe
> > > we match them by the "video4linux" class and particular hardware
> > > subsystems, e.g. PCI or I2C.
> >
> > Has it always worked like that, or is it fairly recent ? If the service
> > is restarted when new devices appear, everything should be fine even if
> > the HAL initializes successfully with zero cameras, shouldn't it ?
> >
>
> Yes, it's a recent change for a new platform where we ended up with
> dynamic detection of components. Actually it hasn't landed yet. The CL
> for reference is
> https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2239080.
>

Do you happen to know why I see this issue being triggered only for
CTS which goes through the android services ? It goes through the
cros_camera_service if I got the architecture right, but even without
this patch, the camera service is always able to identify both
cameras...

It is still not clear to me if the android camera service (is this ARC++?)
interacts with the cros_camera_service through the same mojo interface
as stock ChromeOS camera application (and cros_camera_test?) use or
there's a different interface for it..

Thanks
  j