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

[Laurent Pinchart]

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 ?

-- 
Regards,

Laurent Pinchart