Ville,
thank you for your answers!
Ville Syrjälä wrote:
> You don't have to check the libdirectfb binary because
> video/imageproviders, gfx/inputdrivers and system backends are all
> modules that are loaded at runtime. So just look under
> ${prefix}/lib/directfb-0.9.<something>.
>
> Oh wait, I just realized you were interested in v4l2. That one isn't so
> easy since it's in the same provider as v4l1. Run 'strings
> libidirectfbvideoprovider_v4l.so' and you'll see if v4l2 support was
> included.
>
now that you mention checking for module files, it seems very obvious :)
Running strings for v4l2 isn't too much bother either.
> The v4l1 code is likely to be as good as it can be. It at least used to
> work on my bt84x card.
>
> The v4l2 code isn't quite so good. I haven't really looked at it in
> detail but it seems to lack support for some pixelformats. Also AFAIK
> v4l2 allows grabbing to user provided buffers but that feature is not
> used by the provider. It would eliminate the extra copy when grabbing to
> system memory buffers and it might also work for video memory buffers
> thus making both operations use the same code path.
>
> It looks like very little code is actually shared between v4l1 and
> v4l2 so IMO it would make sense to split the provider...
>
Thank you for your insight. Maybe I'll do some more testing with V4L2
disabled in DFB and see if I get anything through the V4L compatibility
layer of my 2.6.17 kernel.
cheers,
Dom.
--
Dr Dominique Jacquel
DCoded Limited
www.dcoded.co.uk
[EMAIL PROTECTED]
_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
