Hi!
> > > > I don't think that kind of legacy apps is in use any more. I'd prefer
> > > > not to deal with them.
> > >
> > > In another thread ("[ANN v2] Complex Camera Workshop - Tokyo - Jun,
> > > 19"), Mauro has mentioned a number of those:
> > >
> > > "open source ones (Camorama, Cheese, Xawtv, Firefox, Chromium, ...) and closed
> > > source ones (Skype, Chrome, ...)"
> >
> > Yep, ok. Still would prefer not to deal with them.
>
> I guess we'll end by needing to handle them. Anyway, now that PCs are
> starting to come with complex cameras[1], we'll need to address this
> with a focus on adding support for existing apps.
>
> [1] we had a report from one specific model but I heard from a reliable
> source that there are already other devices with similar issues.
Well, now that the issue hit PCs, we'll get help from Linux distributors.
> > (Opening additional fds behind application's back is quite nasty,
> > those apps should really switch to v4l2_ variants).
>
> Only closed source apps use the LD_PRELOAD hack. All the others
> use v4l2_ variants, but, as Nicolas mentioned at the other
> thread, there are a number of problems with the current approach.
>
> Perhaps is time for us to not be limited to the current ABI, writing
> a new API from scratch, and then adding a compatibility layer to be
> used by apps that rely on v4l2_ variants, in order to avoid breaking
> the ABI and keep providing LD_PRELOAD. We can then convert the apps
> we use/care most to use the new ABI.
I believe we can support current features using existing libv4l2 abi
-- complex cameras should work as well as dumb ones do.
...something like that is certainly needed for testing.
But yes, long-term better interface is needed -- and code should not
be in library but in separate process.
> > Application ready to deal with additional fds being
> > opened. contrib/test/sdlcam will be the first one.
> >
> > We may do some magic to do v4l2_open_complex() in v4l2_open(), but I
> > believe that should be separate step.
>
> In order to avoid breaking the ABI for existing apps, v4l2_open() should
> internally call v4l2_open_complex() (or whatever we call it at the new
> API design).
Ok... everyone wants that. I can do that.
> > Ok, so... statistics support would be nice, but that is really
> > separate problem.
> >
> > v4l2 already contains auto-exposure and auto-white-balance. I have
> > patches for auto-focus. But hardware statistics are not used.
>
> Feel free to submit the auto-focus patches anytime. With all 3A
> algos there (even on a non-optimal way using hw stats), it will
> make easier for us when designing a solution that would work for
> both IMAP3 and ISP (and likely be generic enough for other hardware).
Let me finish the control propagation, first. My test hardware
supporting autofocus is N900, so I need control propagation to be able
to test autofocus.
> > Secondary use case is taking .jpg photos using sdlcam.
>
> If a v4l2_complex_open() will, for now, be something that we don't
> export publicly, using it only for the tools already at libv4l2,
> I don't see much troubles on adding it, but I would hate to have to
> stick with this ABI. Otherwise, we should analyze it after having
> a bigger picture. So, better to wait for the Complex Camera
> Workshop before adding this.
>
> Btw, would you be able to join us there (either locally or
> remotely via Google Hangouts)?
I don't plan going to Japan. Hangouts... I'm not big fan of Google,
but I'll try. I'm in GMT+2.
> > Test apps such as qv4l2 would be nice to have, and maybe I'll
> > experiment with capturing video somehow one day. I'm pretty sure it
> > will not be easy.
>
> Capture video is a must have for PCs. The final solution should
> take it into account.
N900 is quite slow for JPEG compression (and I don't really want
solution depending on hardware extras like DSP)... so that will be
fun.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
