Mailing List archive

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

[linux-dvb] Re: AW: Re: [linuxtv-cvs] [CVS-LinuxTV] dvb-kernel



Hello Florian,

> No. We're using the official v4l2 implementation for the 2.4.x kernel.
> (ftp://ftp.thedirks.org/pub/v4l2/kernel2.4/videodevX/videodevX-20020330.tgz)
> . This implementation doesn't provide vide_copy().

Ah, now I understand where the confusion comes from.

Ok, some background: the v4l2 version from Bill Dirks is *not* an 
official version. It was a draft that was meant to be the official 
version, but [insert long story here] prevented it from going directly 
into the kernel.

When the 2.6.x feature freeze came nearer, Gerd Knorr, Michael Schimek
and many others on the video4linux-mailinglist decided to give this 
draft a freshup. Unnecessary things were thrown out, stuff was renamed, 
everything was cut down so that v4l2 was not a replacement for v4l1 
anymore, but an additional set of ioctls and structures. (This is the 
reason why there is only one videodev.c which handles both videodev.h 
and videodev2.h)

The offical v4l2 which is now in the 2.5.x kernel is not compatible to 
the v4l2 (or videodevX) package from Bill Dirks.

My driver is (just like bttv-0.9.x or the saa7134 driver) a "true" v4l2 
driver, and so it needs the 2.5.x kernel videodev2.h interface.

That's the reason why I backported the necessary modules to 2.4.x.

> IMHO the dvb-core should
> not depend on v4l2. This will leed to a tricky situation (if the videodev
> isn't enabled): Either you deny enabling the dvb subsystem at all or will
> end up in UR symbols. I can't see any reason for that.

I agree. dvb-core should not depend on videodev.o.

Additionally, saa7146.o should not depend on videodev.o directly either. 
  For example, the budget cards don't provide anything for v4l2, so it's 
unnecessary.

(/me adds this to the TODO list)

> I know it is bad to have duplicated code in the kernel. But in the past
> situations like this were resolved this way. If enough users (subsystems)
> used (copied) the code, someone made a library for it. (eg. CRC32, zlib).

> Conclusion: Keep the compat stuff but maybe rename it to dvb_copy or
> something else. IMHO. Comments?

Please copy the stuff to an appropriate dvb file and rename it to 
"dvb_copy()". Make a remark that this is basically "video_usercopy()" 
(or generic_usercopy()) and that somebody should make a patch like crc32 ...

Ok, but back to the beginning:

 > No. We're using the official v4l2 implementation for the 2.4.x kernel.
 >(ftp://ftp.thedirks.org/pub/v4l2/kernel2.4/videodevX/videodevX-20020330.tgz)
 > . This implementation doesn't provide vide_copy().

What do you mean with "we're using..."? Do you have any user 
applications using Bill Dirk's "v4l2"? I assume not, because the "old" 
driver only supported v4l1.

> Bye,
>    Florian

Again, please don't CC me.

CU
Michael.




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



Home | Main Index | Thread Index