From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: pali.rohar@gmail.com, sre@kernel.org,
kernel list <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-omap@vger.kernel.org, tony@atomide.com, khilman@kernel.org,
aaro.koskinen@iki.fi, ivo.g.dimitrov.75@gmail.com,
patrikbachan@gmail.com, serge@hallyn.com, abcloriens@gmail.com,
Sakari Ailus <sakari.ailus@iki.fi>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
linux-media@vger.kernel.org
Subject: Re: support autofocus / autogain in libv4l2
Date: Mon, 24 Apr 2017 22:47:31 -0300 [thread overview]
Message-ID: <20170424224724.5bb52382@vento.lan> (raw)
In-Reply-To: <20170424212914.GA20780@amd>
Em Mon, 24 Apr 2017 23:29:14 +0200
Pavel Machek <pavel@ucw.cz> escreveu:
> Hi!
>
> > > For focus to be useful, we need autofocus implmented
> > > somewhere. Unfortunately, v4l framework does not seem to provide good
> > > place where to put autofocus. I believe, long-term, we'll need some
> > > kind of "video server" providing this kind of services.
> > >
> > > Anyway, we probably don't want autofocus in kernel (even through some
> > > cameras do it in hardware), and we probably don't want autofocus in
> > > each and every user application.
> > >
> > > So what remains is libv4l2.
> >
> > IMO, the best place for autofocus is at libv4l2. Putting it on a
> > separate "video server" application looks really weird for me.
>
> Well... let me see. libraries are quite limited -- it is hard to open
> files, or use threads/have custom main loop. It may be useful to
> switch resolutions -- do autofocus/autogain at lower resolution, then
> switch to high one for taking picture. It would be good to have that
> in "system" code, but I'm not at all sure libv4l2 design will allow
> that.
I don't see why it would be hard to open files or have threads inside
a library. There are several libraries that do that already, specially
the ones designed to be used on multimidia apps.
Resolution switch can indeed be a problem on devices that use MC
and subdev API, as a plugin would be required to teach the library
about N9 specifics (or the Kernel API should be improved to let
a generic application to better detect the hardware capabilities).
> It would be good if application could say "render live camera into
> this window" and only care about user interface, then say "give me a
> high resolution jpeg". But that would require main loop in the
> library...
Nothing prevents writing an upper layer on the top of libv4l in
order to provide such kind of functions.
> It would be nice if more than one application could be accessing the
> camera at the same time... (I.e. something graphical running preview
> then using command line tool to grab a picture.) This one is
> definitely not solveable inside a library...
Someone once suggested to have something like pulseaudio for V4L.
For such usage, a server would be interesting. Yet, I would code it
in a way that applications using libv4l will talk with such daemon
in a transparent way.
> > The above looks really odd. Why do you want to make libv4l2 dependent
> > on sdl?
>
> I don't, but I had some nasty problems with linker; this should really
> go into application but it refused to link. Scary libtool.
That's weird.
> > If you're adding a SDL-specific application, you'll need to add the
> > needed autoconf bits to detect if SDL devel package is installed,
> > auto-disabling it if not.
> >
> > Yet, I don't think that SDL should be part of the library, but,
> > instead, part of some application.
>
> Agreed. libtool prevented me from doing the right thing.
if you add libSDL detection at configure.ac, you likely won't need to
deal with libtool.
On a quick look at web, it seems that there's a m4 module that does
the right thing, according with:
https://wiki.libsdl.org/FAQLinux
Thanks,
Mauro
next prev parent reply other threads:[~2017-04-25 1:47 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1487074823-28274-1-git-send-email-sakari.ailus@linux.intel.com>
[not found] ` <1487074823-28274-2-git-send-email-sakari.ailus@linux.intel.com>
[not found] ` <20170414232332.63850d7b@vento.lan>
[not found] ` <20170416091209.GB7456@valkosipuli.retiisi.org.uk>
[not found] ` <20170419105118.72b8e284@vento.lan>
2017-04-24 9:30 ` support autofocus / autogain in libv4l2 Pavel Machek
2017-04-24 13:38 ` Mauro Carvalho Chehab
2017-04-24 21:29 ` Pavel Machek
2017-04-25 1:47 ` Mauro Carvalho Chehab [this message]
2017-04-25 8:05 ` Pavel Machek
2017-04-25 8:08 ` Pali Rohár
2017-04-25 11:23 ` Pavel Machek
2017-04-25 11:30 ` Pali Rohár
2017-04-25 12:28 ` Pavel Machek
2017-04-25 12:51 ` Pali Rohár
2017-04-25 16:55 ` Nicolas Dufresne
2017-04-25 16:51 ` Nicolas Dufresne
2017-04-25 16:53 ` Nicolas Dufresne
2017-04-26 10:53 ` Pavel Machek
2017-04-26 10:53 ` [patch] propagating controls in libv4l2 was " Pavel Machek
2017-04-26 11:13 ` Mauro Carvalho Chehab
2017-04-26 13:23 ` [patch] autogain support for bayer10 format (was Re: [patch] propagating controls in libv4l2) Pavel Machek
2017-04-26 15:43 ` Ivaylo Dimitrov
2017-04-26 22:51 ` Pavel Machek
2017-04-27 5:52 ` Ivaylo Dimitrov
2017-07-13 7:57 ` Pavel Machek
2017-05-03 19:05 ` Russell King - ARM Linux
2017-05-03 19:58 ` Pavel Machek
2017-04-30 22:48 ` Pavel Machek
2017-07-13 9:49 ` [patch] propagating controls in libv4l2 was Re: support autofocus / autogain in libv4l2 Pavel Machek
2017-04-26 11:26 ` Mauro Carvalho Chehab
2017-04-29 9:19 ` Pavel Machek
2017-10-21 22:00 ` Camera support, Prague next week, sdlcam Pavel Machek
2017-10-22 7:36 ` Hans Verkuil
2017-10-22 8:31 ` Pavel Machek
2017-10-23 18:54 ` Pavel Machek
2017-10-23 19:24 ` Hans Verkuil
2017-10-23 20:15 ` Sakari Ailus
2017-10-23 21:02 ` Mauro Carvalho Chehab
2017-10-31 21:28 ` Nokia N9: fun with camera Pavel Machek
2017-11-01 6:36 ` Pavel Machek
2017-11-01 15:32 ` Pavel Machek
2017-04-24 22:07 ` support autofocus / autogain in libv4l2 Pavel Machek
2017-04-25 1:57 ` Mauro Carvalho Chehab
2017-04-25 8:20 ` Pavel Machek
2017-04-25 11:23 ` Pavel Machek
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=20170424224724.5bb52382@vento.lan \
--to=mchehab@s-opensource.com \
--cc=aaro.koskinen@iki.fi \
--cc=abcloriens@gmail.com \
--cc=ivo.g.dimitrov.75@gmail.com \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=pali.rohar@gmail.com \
--cc=patrikbachan@gmail.com \
--cc=pavel@ucw.cz \
--cc=sakari.ailus@iki.fi \
--cc=sakari.ailus@linux.intel.com \
--cc=serge@hallyn.com \
--cc=sre@kernel.org \
--cc=tony@atomide.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).