[pvrusb2] driver status update

[Mike Isely]

On Sun, 9 Oct 2005 xavier.gnata at free.fr wrote:
>
> Hi,
>
> Great job once again!
> Do you have any info on merging the driver into kernel mainline?
> Maintain backward compatibility could become a nightmare if the v4l changes at
> each main kernel release :(
> Dual pvr is working :) I would like to see that on my desk!
> Xavier

I've talked to the current v4l maintainer, and I've also been talking to a
person who has been pulling together and cleaning up the ivtv driver.
There's a new site, ivtvdriver.org which is collecting everything about
ivtv and I've been asked about merging the driver into it.  Concurrent
with that, I've also been asked by the v4l maintainer about migrating the
driver directly into the v4l experimental tree.  Both authors contacted me
almost at the same time, and though their goals are similar, I seem to
have a choice about how to go about this - either merge into ivtv (which
itself will merge into v4l) or merge directly into v4l.

Obviously the end game here is that this driver must find a home in v4l or
some other related site.  But there are some issues that need to be
addressed.  First of all there's still basic development I want to do with
this driver (e.g. get the radio working, get VBI working, implement a DVB
layer) and I'd like to get that done first.  So my immediate goal is to
get as much of that done as I can, though admittedly this is going slower
than I would have liked no thanks to outside issues which are impacting
this - my employer is systematically wrecking my software group so I need
to go job hunting - anyone know of any good job openings around Chicago?

The other issues are these:

1. The V4L maintainer would like to see the files restructured to more
closely match the other V4L drivers.  I don't completely agree with this
but I certainly see his point and there could be some reasonable clean-up
there anyway.  It's worth addressing this.  Much of the existing structure
is an outcome of the way the driver had been organized before I started
working on it.

2. The V4L maintainer also wants to have the code modified to match the
kernel coding style.  The driver actually isn't too far off from this now,
except that I used 4 space indentation with no tab characters ever while
the style requires yucky tab indentation for all levels.  This is
basically a big editing exercise, and with emacs it's pretty easy to
implement.  (But unfortunately with 8 column indentation I may hit another
coding style issue - exceeding 80 columns overall, so I may have to do
some code rearrangement as well.)  I don't like this at all, but the
maintainer has a valid point here - I certainly would not want to be
maintaining code that is a giant ball of mud written in 43 different
coding styles over time.  So I will make this change.

3. There is another apparent requirement which the maintainer hasn't
directly requested of me, but I'm going to have a real problem with if he
does.  He wants all V4L drivers to fully exclusively implement the V4L API
_and_ _no_ _other_.  I saw this in a post on the video4linux list.  The
obvious goal is to encourage use of a common API.  But I think such
exclusivity goes way too far.  I have learned over time in multiple fields
that any kind of arrangement requiring exclusivity always turns out badly.
This "rule" would mean the elimination of the sysfs interface which I have
found to be immensely valuable for debugging and for using the driver with
mplayer.  In addition, there are aspects of the V4L API which don't fit
well with a device that only generates mpeg2 stream data like this device
does - this is why right now the driver only implements 1 of the 3
possible V4L I/O methods; the other two methods are optimized for raw
frames.  (And that issue keeps this driver from working with many V4L
apps.)  Finally, I really do want this driver ultimately working as well
in DVB as it does in V4L because there are DVB-aware apps out there (e.g.
kdetv) that otherwise can't work with a V4L device that spits out only
mpeg2 streams.  One very big thing I did with the pvrusb2 driver when I
took it over was to thoroughly isolate the actual driver internals from
whatever interface is laid on top.  This allowed me to move all of the V4L
implementation into a single source file, and it allowed for a reasonably
clean sysfs implementation sitting logically alongside the V4L
implementation.  I expect a DVB implementation to work similarly, built on
top of the same "shearing layer" as the other two interfaces.

The isolation of interfaces by the way was also the basis for cleaning up
hot-plugging problems - I had to ensure that the USB parts were isolated
from the interfaces because the USB layer can irreversibly disappear at
_any_ time while the higher level interfaces like V4L have to stick around
until all references to it, like open device handles, are removed.  This
ability is something ivtv doesn't really have to deal with...

So yes this driver is going to have to be merged at some point, but these
issues above remain.  Especially #3 - if I don't get DVB in there first,
then I suspect it will never happen at all.  Right now I have a reasonably
productive way to work on this driver and make the results generally
available.  I've never said that "I" want to be the only one making fixes;
to that end this is why I want to get the Subversion repository for the
driver publically accessible.  But so far nobody has really stepped up to
seriously assist with enhancing this driver, so right now I'm OK with the
current arrangement.  In the long term I fully expect that I'm not going
to maintain this thing forever and ultimately the above issues will be
dealt with and the driver will somehow find its way into the kernel tree.

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