On Tuesday, May 03, 2011 17:03:13 Mauro Carvalho Chehab wrote:
> Em 03-05-2011 10:59, Hans Verkuil escreveu:
> > On Tuesday, May 03, 2011 14:49:43 Devin Heitmueller wrote:
>
> > What better non-embedded driver to implement vb2 in than one that doesn't
> > yet
> > do stream I/O? The risks of breaking anything are much smaller and it would
> > be
> > a good 'gentle introduction' to vb2.
>
> The risk is there even on this case: existing applications should work with
> vb2.
> Also, you're discussing about something that we don't have: there's no vb2
> patches
> for cx18 yet.
>
> > Also, it prevents the unnecessary
> > overhead of having to replace videobuf in the future in cx18.
>
> This overhead already exists, as a vb1 solution is there and there's no vb2
> solution
> yet.
>
> > The problem is no doubt different agendas. You want to have your code
> > upstreamed. I want to have code upstreamed that uses the latest frameworks.
>
> From my side, I'm more concerned if vb2 will really support all memory modes
> that
> vb1 already supports, on both kernelspace and userspace API's. I'm not
> confident
> about that yet, and before starting spreading a solution that we don't know
> for sure
> that it will work on non-embedded devices, with similar or better performance
> than vb1,
> we need to fully test it with one complete driver, before testing on vb
> subsets,
> in order to fix architectural design problems (if is there any). Before that,
> porting any non-embedded driver to vb2 is premature.
>
> > And the only way to prove that vb2 works is to use it. Saying "it's
> > unproven,
> > so let's not use it" is silly.
>
> Yes, and nobody said otherwise.
>
> > The right approach IMHO is to implement it in
> > new drivers, and ensure that the author(s) of the framework give high
> > priority
> > to fixing any issues that may surface.
>
> This is where we diverge: while a "pure api/application compliance" might work
> with a new driver, you can't compare performance if you don't have the very
> same
> driver using vb1 against the same driver using vb2. Even for de-facto API
> compliance
> tests, if you find something not working with some application and a new
> driver, it
> is harder to point the fingers if the issue is at VB2 or at the new driver,
> as a
> new driver is, per definition: NEW. So, it is untested.
>
> On the other hand, if you take an existing drivers, convert it to VB2, test
> it with
> some compliant tool and it works, and test with application X and it breaks,
> you
> know for sure that the error is at VB2.
It sounds great, but the problem is that there is little incentive to convert
existing
drivers to vb2. Take cx18: someone obviously wants to get this code in. So if
you
require vb2 then there is an incentive to do that work. If the current version
is
accepted, then the incentive to move to vb2 is gone. If you are lucky you can
find
developers like Andy who might look at it. Look at how long it took to get rid
of
V4L1. Or how long it takes to convert drivers to video_ioctl2? Or the control
framework?
It is much easier to put such requirements on incoming code. Once it is in it
can
take a very long time to convert code to a newer framework.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
