Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: V4L issues with linux dvb driver



  Hey Michael,

> I admit that all other v4l2 drivers mostly only support the
> "old/inofficial" v4l2 api (before it went to the 2.5.x kernel), so
> this will take some time until 2.6.x finally comes out...

  Quite.  Still, I can only test with what I have, and I currently only
use the bttv drivers from the kernel, so, only V4L1 here. ;-)

> > One annoyance for me right now is that while V4L2 supports ALTERNATE
> > mode, the bttv V4L2 driver currently fills both buffers at frame
> > rate, making this very important feature very useless. 
> 
> I don't want to annoy you, but: does v4l1 support this?

  I'm not annoyed. :)  I appreciate this discussion alot.

  No, V4L1 does not support alternate mode, but I really wanted to move
to V4L2 and only support drivers that support ALTERNATE mode, since then
I can rip out all my nasty /dev/rtc code.  Sleeping for exactly 16.6ms
for NTSC sources really sucks.  Oh well.

> There are several reasons: the user basis for my analog saa7146
> drivers is very small and nobody apparently has asked for this or has
> been using tvtime. The user basis for the DVB basis is much larger,
> but not many are using the new "dvb-kernel" driver. Additionally, more
> and more users switch from full-featured DVB-cards to el-cheapo
> budget-cards without mpeg-decoding and video-functionality, so they
> don't need a tv application any more.

  I have a question.  For my support pages, what cards does your driver
work with, and where is a link to a webpage describing your driver?

> You could borrow ideas from "xawtv", which supports v4l1, pre-2.5.x
> v4l2 and v4l2 at once. It should be fairly easy to detect the presence
> of v4l2 on a user's system and then compile different modules for
> v4l1/2 support, no?

  Yes this will likely be some of the basis for my code, however I do
not intend to support random drivers that use the pre-2.5.x API.

> I'll have a look at how complicated adding field capturing to
> alternating buffers is.
> 
> You basically want to queue twice as many buffers with half the size,
> getting one field every 20ms, right?

  Yes, I want a 20ms wakeup for PAL sources, 16.6ms for NTSC, since this
is our output framerate.

-- 
Billy Biggs
vektor@dumbterm.net


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index