lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 24 Apr 2017 22:47:31 -0300 From: Mauro Carvalho Chehab <mchehab@...pensource.com> To: Pavel Machek <pavel@....cz> Cc: pali.rohar@...il.com, sre@...nel.org, kernel list <linux-kernel@...r.kernel.org>, linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>, linux-omap@...r.kernel.org, tony@...mide.com, khilman@...nel.org, aaro.koskinen@....fi, ivo.g.dimitrov.75@...il.com, patrikbachan@...il.com, serge@...lyn.com, abcloriens@...il.com, Sakari Ailus <sakari.ailus@....fi>, Sakari Ailus <sakari.ailus@...ux.intel.com>, linux-media@...r.kernel.org Subject: Re: support autofocus / autogain in libv4l2 Em Mon, 24 Apr 2017 23:29:14 +0200 Pavel Machek <pavel@....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
Powered by blists - more mailing lists