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

[Tomasz Figa]

On Mon, Jul 27, 2020 at 12:52 PM Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
>
> Hi Tomasz,
>
> On Mon, Jul 27, 2020 at 11:30:16AM +0200, Tomasz Figa wrote:
> > On Thu, Jul 23, 2020 at 11:43 AM Jacopo Mondi wrote:
> > > On Wed, Jul 22, 2020 at 08:10:03PM +0200, Tomasz Figa wrote:
> > >> On Wed, Jul 22, 2020 at 7:56 PM Laurent Pinchart wrote:
> > >
> > > 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..
> >
> > Yes, Android interacts with the cros_camera service using the same
> > interface. I think it's just that Android camera frameworks cache the
> > camera metadata when they query it the first time and would ignore any
> > later changes. On the contrary, Chrome probably just queries the
> > metadata every time some camera use case is executed.
>
> IS there a service that could be restarted to reset the Android camera
> framework state instead of rebooting the device ?

I'm not sure unfortunately. I think logging out and in again in Chrome
OS should restart the Android container, but not sure if that improves
anything. Also given that inside the container is just plain Android,
maybe there is some generic Android way to reload the camera HAL?