Re: [libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass acpi_enforce_resources=lax on the Surface Go (version1))

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Kieran,

On Fri, Nov 12, 2021 at 05:51:57PM +0000, Kieran Bingham wrote:
> Quoting Laurent Pinchart (2021-11-12 10:46:56)
> > On Fri, Nov 12, 2021 at 10:32:31AM +0000, Dave Stevenson wrote:
> > > On Thu, 11 Nov 2021 at 22:04, Laurent Pinchart wrote:
> > > > On Thu, Nov 11, 2021 at 07:30:39PM +0000, Dave Stevenson wrote:
> 
> <big snip>
> 
> > > Refcount the users. Opening the subdev counts as one, and streaming
> > > counts as one. You can now hold the power on if you wish to do so.
> > > 
> > > It's the "let userspace worry about it" that worries me. The same
> > > approach was taken with MC, and it was a pain in the neck for users
> > > until libcamera comes along a decade later.
> > > IMHO V4L2 as an API should be fit for purpose and usable with or
> > > without libcamera.
> > 
> > It really depends on the type of device I'm afraid :-) If you want to
> > capture processed image with a raw bayer sensor on RPi, you need to
> > control the ISP, and the 3A algorithms need to run in userspace. For
> > other types of devices, going straight to the kernel API is easier (and
> > can sometimes be preferred).
> > 
> > At the end of the day, I don't think it makes much of a difference
> > though. Once the libcamera API stabilizes, the library gets packaged by
> > distributions and applications start using it (or possibly even through
> > pipewire), nobody will complain about MC anymore :-) The important part,
> 
> I don't really want to pull this thread further away from $SUBJECT .. but:
> 
> Unfortunately, I don't think that's true.
> 
> We've still got a long way to go!
> 
> libcamera isn't enough to cover all MC use cases. The RPi for instance
> has the ability to capture HDMI in through the CSI2 receiver with a
> TC358743 or such. This won't need an IPA or 3a, but might want to go
> through the ISP for scaling or format conversions...

I was indeed mostly thinking about the camera use cases, as we were
discussing lens control. There's certainly more than that, with a need
to at least configure the unicam MC pipeline to capture from, for
instance, an HDMI-to-CSI-2 converter. This isn't something that
libcamera was designed for, and I don't know whether the use case could
be retrofitted, or if a different userspace framework would be better.

> Some time ago, I started to explore how we could handle 'easily'
> capturing non-camera devices. But it was not in scope for libcamera.
> 
> > in my opinion, is to handle the complexity somewhere in a framework so
> > that applications don't have to do so manually.
> 
> Yes, the complexity needs to be handled somewhere. Applications
> should be able to work with a generic interface and get their video
> frames. But right now - I don't think applications have this, and key
> areas needed for supporting that are not under development or even
> consideration yet as far as I can tell.

-- 
Regards,

Laurent Pinchart