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

[xavier.gnata at free.fr]

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


> I have an understanding for how to make VBI work now (thanks to Hans
> Verkuil and his efforts in ivtv).  I think I see a way to get the radio
> side working as well.

Unfortunately, I have no time to look at that for now :( (I have to play with
the qemu usb layer (for my job)).

> BTW, as far as I know, VBI and uncompressed video are not supported at all
> by the Windows driver.  :-)

I have no clue for VBI but I'm sure that uncompressed video is *not* supported
by the windows driver :)

> 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 ;)

Xavier