All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>,
	sean@mess.org, hverkuil-cisco@xs4all.nl,
	mchehab+samsung@kernel.org, sakari.ailus@linux.intel.com,
	linux-media@vger.kernel.org
Subject: Re: [PATCH] Minimal libv4l2 support for complex cameras
Date: Mon, 23 Mar 2020 15:43:41 +0200	[thread overview]
Message-ID: <20200323134341.GH4768@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20200323135933.6ddbe4c3@coco.lan>

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

  reply	other threads:[~2020-03-23 13:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-23 11:47 [PATCH] Minimal libv4l2 support for complex cameras Pavel Machek
2020-03-23 11:57 ` Laurent Pinchart
2020-03-23 12:22   ` Pavel Machek
2020-03-23 12:24     ` Laurent Pinchart
2020-03-23 12:59       ` Mauro Carvalho Chehab
2020-03-23 13:43         ` Laurent Pinchart [this message]
2020-03-23 13:19       ` Pavel Machek
2020-03-23 13:52         ` Laurent Pinchart
2020-04-14  9:11           ` Hans Verkuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200323134341.GH4768@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab+samsung@kernel.org \
    --cc=mchehab@kernel.org \
    --cc=pavel@ucw.cz \
    --cc=sakari.ailus@linux.intel.com \
    --cc=sean@mess.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.