[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