[pvrusb2] New driver snapshot: pvrusb2-mci-20051126

[Mike Isely]

On Mon, 28 Nov 2005, xavier.gnata at free.fr wrote:

> Quoting Mike Isely <isely at isely.net>:
>
>> On Sun, 27 Nov 2005, xavier.gnata at free.fr wrote:
>>
>>> Hi,
>>>
>>> As usual, I going to test this snapshot asap.
>>> Could you tell us a little bit more about "additional functionalities".
>>> For sure, I could wait your next email but "other video formats" sounds so
>>> interresting...
>>>
>>> xavier
>>
>> There are a couple of controls (like "interlace") which are not really
>> correct.  I need to straighten that out.
>>
>> New potential goodies include better control of video filtering (which I'm
>> hoping will significantly help with snowy channels) along with support of
>> different video formats.
>>
>> No promises yet, but from what I've read it may be possible to get this
>> device to emit uncompressed video data, which _in theory_ could allow this
>> driver to work with devices that don't deal with mpeg2 data very well.
>> But that will take a lot of work and there are many pitfalls along the way
>> (like perhaps having to get isochronous streaming to work or that the
>> encoder chip's logic for this might have a bug) which might prevent it
>> from working...  The upside however is tremendous.
>
> Whaou! I would have said that is was simply not possible to "switch off" the
> internal mpeg2 encoder ;). For sure it will take a lot of work to get it working
> but it would be so great because linux tv applications dealing this mpeg2 are
> not so common...

Well as I said "no promises" :-)  It's just an inkling of an idea right 
now.

>
>> Other driver work still to be done includes (1) segregating out the
>> debugging stuff so that it can be selectively compiled / activated, and
>> (2) more work to separate out parts which don't belong in v4l.
>
> Is there still a change to get the driver into 2.6.16 mainline?
> If not, it does not sounds like a problem for me ;)
>

Here's where we stand with the driver in v4l right now:

There is a snapshot of the driver checked into the v4l CVS repository 
right now.  It is in an 'experimental' area set up by Mauro.  The code 
that is there (as of today) is functionally equivalent to the normal 
snapshot I released last night.  Anybody who wants to check out a CVS 
snapshot of "v4l-dvb" can find the pvrusb2 driver in it under 
"v4l_experimental/pvrusb2".  By the way, it appears that the dvb and v4l 
projects are merging; the source repositories were brought together 
yesterday so there's been a lot of activity among the developers.

Now, the code that is in v4l is not exactly identical to the normal 
snapshot.  There are things in the 'normal' snapshot which make no sense 
in v4l, like for example handling of the ivtv-specific saa7115 module 
(which has been replaced by something alien in v4l).  The normal snapshots 
I've been releasing still make a strong effort to stay backwards 
compatible, through various bits of detection and adaptation.  What is in 
v4l needs none of that, but unfortunately I think it is a burden right now 
to force everyone right now to move over to v4l's CVS repository if they 
want ongoing pvrusb2 updates.

You might have noticed (or maybe you haven't) that building the pvrusb2 
driver is pretty straight forward and that it "just works" in a variety of 
environments with little additional coaxing.  Building inside of the CVS 
repository is not as easy, and the resulting modules are a lot more 
difficult to install in a running kernel.  (This is unavoidable because 
essentially you're replacing all of V4L not just this one driver.)  When 
built as part of V4L, the pvrusb2 driver ties into things specific to the 
CVS resident version of V4L not the kernel version, that environment is in 
flux, and it's a lot bigger of a beast to manage.  In addition, you have 
to go to extra steps just to build pvrusb2 there (it's in "experimental" 
after all and not built as part of the normal tree), and the build process 
is, well, sloppy.  I don't think it's fair to require this extra burden 
right now for everyone (myself included) to have to go through all that 
hassle to keep using the driver right now.  I in particular find myself 
moving a lot faster working with local changes in my own area rather than 
having to work through V4L.

With that said, these sorts of things I think will work themselves out 
over time.  For example, I am probably going to try to advocate a cleanup 
of the V4L build system - not sure if I'll succeed but what the heck. 
The mechanism for building V4L really should map very closely to the 
kernel build system but because of historical reasons, it diverges. 
Another thing is that once the driver moves from experimental to the 
normal part of V4L then it will get easier.  And of course once the driver 
does make it into the kernel then all this extra hassle should go away.

So I'm not trying to stay out of V4L here, but rather make the transition 
work smoothly.  To that end, I've been combing through the code and 
reworking things to make it easier to separate what should ultimately be 
in the kernel versus what's present now because of our current out-of-tree 
situation.  I plan at this moment to keep releasing local snapshots of the 
driver until it no longer makes sense to continue.  A lot of this is 
"experiment"; while I intend to not let the driver sources fork, I might 
have problems with that.  We shall see.

Anybody still awake?  :-)

   -Mike


-- 
                         |         Mike Isely          |     PGP fingerprint
      Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                         |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                         |                             |