[pvrusb2] New driver snapshot: pvrusb2-mci-20051126
isely at isely.net
Sun Nov 27 18:36:50 CST 2005
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:
>>> 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
>> 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
>> 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 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
More information about the pvrusb2