Re: [PATCH] Minimal libv4l2 support for complex cameras

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Mauro,

On Mon, Mar 23, 2020 at 01:59:33PM +0100, Mauro Carvalho Chehab wrote:
> Em Mon, 23 Mar 2020 14:24:42 +0200 Laurent Pinchart escreveu:
> > 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.
> 
> Well, not really... I guess lots of userspace apps rely on it
> (qv4l2, xawtv, tvtime, camorama, zbar, ...).
>
> In order to be able to deprecate it, we need to add some code there
> to let them bind via libcamera and test them with different hardware,
> including the non-UVC ones.

qv4l2 is out of scope, as that's a V4L2 test application, so it really
needs to stay as close as possible to V4L2 :-) TV applications are also
not candidates for porting to libcamera, as libcamera doesn't support TV
capture. Sure, they can use non-TV capture devices, but it's really a
completely different world. I don't mind if someone wants to try and
integrate libcamera support in the above applications, but I'd also be
happy to let them as they are and move on.

I'm not calling for libv4l2 to be removed, but new developments
shouldn't use it. We've been telling developers to go for the V4L2 API
directly instead unless some libv4l2 features are mandatory for their
use case (such as support for the custom compression formats of those
ancient webcams). It makes no sense, from a community point of view, to
invest in that project to support complex cameras.

> > > > 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.
> 
> I created some time ago a fork of v4l-utils in order to be able to
> merge the N900 work from Pavel. We can add the N900 work there - or 
> on a separate branch at the main v4l-utils tree.

It's open source, forks are encouraged. I believe it would be a waste of
time, but it's not my time, so I don't mind :-)

-- 
Regards,

Laurent Pinchart



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux