Re: [PATCH] Minimal libv4l2 support for complex cameras

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

Hi,

On Mon, Mar 23, 2020 at 02:19:23PM +0100, Pavel Machek wrote:
> > On Mon, Mar 23, 2020 at 01:22:17PM +0100, Pavel Machek wrote:
> > > > On Mon, Mar 23, 2020 at 12:47:27PM +0100, Pavel Machek wrote:
> > > >> Hi!
> > > >> 
> > > >> We now have easy-to-install support for complex camera in form of
> > > >> Maemo Leste on N900.... Unfortunately we don't have anything in
> > > >> userspace that can be used to work with the camera.
> > > >> 
> > > >> This attempts to be minimal solution to get libv4l2 to work.
> > > > 
> > > > libv4l2 is mostly deprecated. How about contributing an OMAP3 ISP
> > > > pipeline handler to libcamera instead ? :-)
> > > 
> > > Why should it be instead?
> > > 
> > > I need something for kernel testing, and there is ton of apps using
> > > it. Let me do this. libcamera might be future, but...
> > 
> > Sure, if it's useful for you, I won't prevent you from developing any
> > code you want :-) But there's very little chance of getting it merged,
> > and it would be useful to more people to have a support for that
> > platform in libcamera. It's really your decision, and I'm not blaming
> > you.
> 
> When you have libcamera ready, you'll still need some hardware and
> kernel to work with it. Do you have something more suitable than
> N9/N900? Droid 4 has separate CPU to run the camera, Librem 5 camera
> does not have autofocus (and I believe nor has PinePhone).

OMAP3 is great as a test bed for camera opinion. It's widely available,
has amazing documentation, and even though the hardware is aging a
little bit, it's still very decent and has a nice ISP. Even better,
there's good kernel support for it, so it's a really good platform in my
opinion. The only reason we don't support it yet in libcamera is lack of
spare time, I would really love to see that happening, and it would be
first-class citizen in the code base.

> My patch is not complex, and libv4l2 is full of similar hardware
> support code. What would be reason not to merge it?

It has to be reviewed and maintained. From a V4L2 community point of
view, I don't think it makes sense to invest time on a dying component
(I'm talking about libv4l2, not OMAP3). But from a personal point of
view, if you find libv4l2 useful to develop code for the OMAP3 and
experiment, I see no issue with that. If other reviewers and maintainers
of libv4l2 disagree and want to invest their time in this, I won't stop
them, but I wanted to warn that this is a dying project.

-- 
Regards,

Laurent Pinchart