On Wed, Jul 05, 2006 at 04:19:26PM +0100, Dr Dominique Jacquel wrote:
> Marcio Moreno wrote:
> > Hi Dom,
> > 
> > On 7/5/06, Dr Dominique Jacquel <[EMAIL PROTECTED]> wrote:
> > 
> > 
> >> 1) Is there a way to determine the configure options (i.e. was
> >> video4linux2 enabled? and the like) used to generate a particular
> >> libdirectfb?
> > 
> > 
> > yes, there is (i.e. ./configure --enable-video4linux2). You could type
> > ./configure --help to see the others options.
> > 
> 
> Yes, maybe I did not phrase it well enough. Is it possible retreive the
> configure options from a binary libdirectfb? To check if this particular
> binary version has the correct features compiled in.

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.

> > I was not capable to put v4l provider working. I sent an e-mail here asking
> > for the cards that can directly work with directfb v4l provider, but I got
> > no answer (the guys here have much work to do and few people to help).
> > So, I
> > used v4l api of my card (setting colorkey and overlay info) to overlay
> > directfb graphics over the video content decoded by hardware. My card is
> > from National Geode family.
> >
> 
> mmm, sorry to hear this. Anybody with more positive feedback? Is the V4L
> video provider considered broken?

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...

-- 
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/

_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users

Reply via email to