On 23/03/2020 14:52, Laurent Pinchart wrote: > 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. > It's not so much the reviewing/maintaining part that is a concern for me, it is the fact that this would create yet another way to support complex cameras, when we made the decision to use libcamera for that instead. I don't want two APIs, and vendors certainly don't want two APIs. I agree with Laurent that adding OMAP3 support to libcamera would be much more useful than adding a libv4l hack. Regards, Hans
