[pvrusb2] New driver snapshot: pvrusb2-mci-20051206
isely at isely.net
Wed Dec 7 17:24:41 CST 2005
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.
> Great job once again. I can't see a bug with xawtv and/or with the sysfs
> 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
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
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 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