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

[Michael Hunold <hunold-ml@web.de>]

Hello Billy,

>   Not exactly the end of the world, and bt878 already has this problem,
> the chip supports separate saturation/hue but the API sucks.  We're
> currently kinda holding off on our auto-calibration stuff until we go to
> V4L2.
Ok.

>   Thanks, I appreciate your interest.  We're definitely in a bad
> situation with V4L2 right now, even more so that many V4L2 drivers are
> in various stages of development when drivers exist for V4L1 that work.
I consider bttv/saa7134/saa7146 the most important video devices, and at 
least Gerd Knorr is trying very hard to get his stuff into good shape.

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

> However, you're not the first person to have been presented a bug or
> problem in their V4L1 code and then be uninterested in fixing it, saying
> that we should move to the V4L2 interface :)
8-) Some more explanations: about 2,5 years ago, the video part of the 
DVB driver was created on the current (at that time) version of my v4l1 
driver, ie. the development was forked. I changed to v4l2 later and 
developed my "analog" drivers further. Because of that the DVB "head" 
driver is still v4l1, while I've been working on v4l2 only. I haven't 
touched the v4l1 code for years now. So I simply cannot fix it, because 
I would have to start almost from 0.

But I ported the video subsystem of the DVB driver to my "new" saa7146 
subsystem lately, this is "dvb-kernel" in CVS.

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

> Does your driver
> support ALTERNATE mode?  Can I get woken up every field?  I don't like
> the idea of moving to V4L2 when a major driver like this lies about
> their support of ALTERNATE mode...
The "dvb-kernel" v4l2 driver is not "alternate" aware. Currently it does 
*not support* capturing fields to different buffers, althought the 
hardware can do this.

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.

>   Finally, it is essential to me that users be able to use the kernel
> packages from their distribution and not compile their own.  So, this
> means I must support V4L1.  Your patch is a nice start to V4L2 support,
> but unfortunately the end result is going to look a little different as
> I try to support both at once in a clean way.
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?

>   Comments?  I'd almost rather see some more effort put into the V4L1
> compatibility code until 2.6 is released, although I understand that
> even when 2.6 comes out, we'll still have to go through a phase of
> supporting both APIs.
I wouldn't count on the compatibility layer, but instead natively 
support both apis. Concentrate on bttv for the v4l1 driver, all other 
drivers (saa7134/saa7146) should work through v4l2 (except the alternate 
capture of course)

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?

CU
Michael.





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