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

[Kieran Bingham]

Quoting Laurent Pinchart (2021-11-12 10:46:56)
> Hi Dave,
> 
> CC'ing Sakari.
> 
> 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...

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.

--
Kieran

> -- 
> Regards,
> 
> Laurent Pinchart