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

Mike Isely isely at isely.net
Tue Sep 5 17:01:31 CDT 2006


On Tue, 5 Sep 2006, xavier.gnata at free.fr wrote:

> Quoting Mike Isely <isely at isely.net>:
> 
> >
> > There's a new driver snapshot available.  Nothing really significant this
> > time, just an accumulation of bug fixes and a change for how vertical /
> > horizontal resolution limits are calculated and enforced (it is a lot more
> > relaxed now).
> >
> >   http://www.isely.net/pvrusb2/pvrusb2.html
> 
> Hi,
> 
> I just want to say that I'm running a 2.6.18-rc6 with pvrusb2 kernel mainline
> code  and that everthing works like a charm (using the lastest xawtv snapshot).
> 
> I have one question :
> I can use diff (of course ;)) but I would like to know what is the pvrusb2
> mainline policy.
> Is lastest pvrusb2 version the 2.6.18-rc6 once or the lastest one available on
> your website? How long do you plan to maintain these two trees?
> As pvrusb2 is now in the kernel, I will be much harder to introduce test purpose
> patches. Do you plan to release patches against in-kernel code?
> Stop me if I'm fully wrong please :)
> 

The standalone driver you can download from isely.net is almost always 
going to be the "bleeding edge".

The driver you can get from v4l-dvb is tracked with the standalone 
version; in fact I currently use a script to move changes from standalone 
into v4l-dvb (and I also pull stuff from v4l-dvb back into the standalone 
driver where appropriate - that's the "almost" in the previous paragraph).

The driver in the kernel tree is pulled from what is in v4l-dvb, and stuff 
there only moves across as per policy with respect to kernel source tree 
changes.
 
Being that the pvrusb2 driver is currently a part of the v4l-dvb tree, I'm 
not directly submitting patches into the kernel tree.  Rather what happens 
right now is something like this:

1. I make a bunch of changes to the standalone driver.

2. Those changes are moved by me to the v4l-dvb resident driver.

3. At some point Mauro pushes those (or some subset of those) changes over 
to the kernel (as part of a larger block of changes for v4l-dvb code).

Sometimes there are changes from other developers that go straight into 
v4l-dvb, but I always pull those back into the standalone driver (with 
some latency).

Of the three "instances", the largest and most complex is the standalone 
driver.  This is because it has to compile and run correctly against 
multiple kernel versions and various incarnations of v4l.  So that driver 
has a lot of logic to retain backwards compatibility.  (Look at version.h 
there in the standalone sources and you'll see what I mean.)  The next 
largest is the driver in the v4l-dvb tree, because while the v4l 
surroundings are "constant" relative to the driver, it still has to be 
insertable into different kernels.  The most compact version of the driver 
is the one in the kernel - in that case the driver is stripped down to be 
specific to that kernel version and the corresponding v4l-dvb tree that is 
a part of that kernel.

All development work that I do at this point is mainly in the standalone 
driver and occassionally in the resident v4l-dvb version.  I can also do 
development in the standalone version yet still compile it directly 
against the v4l-dvb tree (which has proven handy a few times).  I don't 
intend on trying to publish or maintain any patches against the kernel - I 
don't really see a need for it and because of the indirect hop through the 
v4l-dvb tree I think such a thing will probably not be worth the effort 
anyway.

I imagine that anyone who just wants to get their PVR USB2 simply working 
and cares not for the extra effort to compile it out-of-tree would just 
use the in-kernel version.  If however you like playing or may need some 
feature / fix not yet in the kernel then you have the choice of using the 
standalone driver directly or simply replacing the whole v4l-dvb subsystem 
in your kernel with whatever is in the v4l-dvb tree.  There are pros / 
cons to these choices.  The fact is that right now I see no reason to drop 
the standalone driver.  Certainly I would expect it to keep up with 
everything else.  It's your choice what to use.

The existing pvrusb2 documentation on the isely.net site covers all three 
instances of the driver and points out anything specific to one or another 
version.

Of course having said that, now somebody will find some reason to cause me 
to take that all back :-)  But right now this is my intention.

Clear as mud?

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


More information about the pvrusb2 mailing list