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

[Mike Isely]

On Wed, 7 Dec 2005, xavier.gnata at free.fr wrote:

> Quoting Mike Isely <isely at isely.net>:
>
>>
>> I've released a new driver snapshot.  Everything as usual can be found
>> here:  http://www.isely.net/pvrusb2.html
>>
>> New stuff includes support for PAL-M video standard, and support for newer
>> PVR USB2 devices which contain a type 103 tuner (this requires another
>> support module to be operated, which is already in v4l).  See the change
>> history on the web page for more info.
>>
>>    -Mike
>
> Great job once again. I can't see a bug with xawtv and/or with the sysfs
> interface.
> By the way, do you have news on the devels topics? ;)

Integrating the driver into V4L has generated a few issues.  You can find 
a version of it checked into v4l-dvb's CVS repository now under 
v4l_experimental.  Issues include some disagreements over how the 
abstraction has been implemented (the V4L isolation in the driver core 
arguably should not really be needed anymore).  Another issue which I just 
became aware of is that there is a driver in the dvb side of the 
repository which overlaps some of what pvrusb2 does.  The obvious desire 
is to bring these pieces together, something I'm going to investigate 
next.

One issue which I am currently wrestling with has to do with the 
abstraction.  Until this driver makes it into the kernel tree, the only 
places you can find it are in the snapshots you all know and in the 
v4l-dvb CVS repository.  It is considerably harder to build and use the 
driver from within v4l-dvb for a number of reasons (not the least of which 
is that you basically have to build and install/update all of v4l-dvb in 
order to use the driver).  In addition, a lot of v4l-dvb is undergoing 
changes, and breakage there will potentially impact anyone trying to use 
the pvrusb2 driver, further making it hard to use.  I'd really like to 
stay out of those sorts of entanglements, but in the long run the driver 
really does have to end up there.  However in the mean time I don't want 
to abandon continued support of these snapshots while the alternative 
right now is still worse.  A middle road I've been trying to follow 
therefore is to keep the sources from forking - same sources in the 
snapshot as what is in v4l-dvb.  I've done some work to make this more 
doable, but unfortunately this sort of approach immediately opens up 
design questions which will have different answers depending on whether or 
not we're in the V4L tree.  For example, that abstraction in the driver is 
useful when standalone because it helps to isolate the driver from V4L 
turmoil.  But viewed from within V4L, the V4L abstraction is pointless and 
a source of contention with the overall integration.

The immediate thoughts I have on proceeding here involve several areas of 
work:

1. The cxusb driver on the DVB side is apparently very similar in concept 
to pvrusb2 but doesn't target exactly the same hardware.  It's also 
missing features that pvrusb2 has and has features that pvrusb2 lacks. 
I'm also told from several that have looked at both that pvrusb2 is the 
more mature of the two.  I plan on examining that driver closely to see if 
things can be merged together.

2. One reason I did much of the V4L abstraction was to make the driver 
more amenable to also work in DVB.  However DVB and V4L have been merged 
so that reasoning is kind of negated.  The abstraction layer is serving 
multiple purposes: V4L isolation, control of the device as a whole (e.g. 
starting / stopping subsystems), and safe operation with USB hotplugging. 
The big objection is the V4L side of this and I think I can do a lot to 
eliminate that issue without having to mess up the other 2 aspects.

3. There's a bunch of development still to be done, like VBI support, FM 
tuner support, control of digital filtering, support for other video 
formats.  I see clear ways to deal with all of that, but shortly after I 
gained enough knowledge to pursue this, items (1) and (2) surfaced above.

Right now, the first priority is item (1).  I will look at cxusb and see 
what might be possible.  Based on that I'll probably take a run at item 
(2).  After the dust has settled, then it's on to item (3).

There was also an "item zero", but I finished that last night - updating 
the driver to work with that type 103 tuner.  I have a second PVR USB2 
device now and tried it for the first time about 10 days ago - whereupon I 
hit this new tuner type and discovered that the driver didn't work with 
it.  That resulted in some discussion with a few others familiar with the 
situation involving the new tuner module.  Sunday night I studied what 
needed to be done and last night I implemented 27 new lines of code to 
support it.  I really wanted to get that done now because I suspect a lot 
of new PVR USB2 devices are going to be showing up that will need this fix 
(like the person who e-mailed me with exactly this problem less than 24 
hours after I first hit it) and I don't want those people to be stuck. 
This sort of thing is also a strong argument for why it's a good idea to 
continue maintaining the standalone driver until the V4L side of things 
stabilizes better and the driver at least gets into the kernel.

This is probably more than you wanted to know...

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