[pvrusb2] Driver status as of 25-Mar-2006
Mike Isely
isely at isely.net
Sat Mar 25 14:28:14 CST 2006
To all:
Here's an update about what is going on with the pvrusb2 driver.
1. I have been steadily chipping away at getting the new model 24xxx
series hardware working with the driver. Last week's snapshot had
a number of changes for that, but not everything. In particular
there is a stability problem during initialization involving the
cx25840 decoder chip; I still don't have good traction on this.
I'm afraid I'm not going to figure this out for a while yet.
During this entire time I've had two separate sets of driver
sources. One is the "mainline" and the other has the changes for
the newer hardware. What I've been doing is merging changes back
to the main tree one at a time as I prove in each piece (at least
to the point where I know it doesn't harm anything). As of this
afternoon, I've fully merged it all back together. The last bit
was work to figure out how to get composite and s-video inputs
working - the branched driver had test code to support figuring
that out and I didn't want that code to get back into the mainline.
There are still some fixes to be done, but it can all be done in
the main area now.
2. There has been work going on to get the driver into the main V4L
source tree, and subsequently into the kernel source tree. The
plan right now is that the driver will show up in the 2.6.17
kernel. The driver sources were moved into the main V4L tree a few
weeks ago, but some coding / structural issues are holding it back
from being submitted to the kernel. When the 2.6.16 kernel was
finally released last week, a 2 week merge window opened for
getting new features into 2.6.17. It's during that time when I
have to do the remaining fixes here. I'm hoping to do that this
weekend; if not then the driver may not make it in time.
3. Hans Verkuil has been making changes to the way audio selection
routing (e.g. tuner vs RCA jacks) is handled in V4L. He reworked
msp3400 to do this 'right' and has since made changes to the
pvrusb2 driver (in V4L) to track these changes. He has a second
round of changes that do a similar job for saa7115. Since I'm also
maintaining pvrusb2 as a standalone driver, I need to pull these
changes back so that the standalone driver will continue to work
correctly going forward. Though these changes should not be gating
the work towards 2.6.17, the fact is that I really can't attack the
remaining changes needed for (2) until I have everything merged
back together, so I need to merge Hans' changes into the standalone
driver. I also plan on doing that this weekend.
4. The pvrusb2 web site, though not technically inaccurate, has a
growing list of improvements I need to do. In particular, I need
to add lots of info about making the newer hardware work correctly,
but rather than just do that I'd prefer to rework the entire site
so that it can be more easily understood. I haven't done anything
with that yet. Unfortunately that work is still probably at least
a week away.
The current situation with the new hardware is that it can be made to
work, and the driver has all the changes merged now needed to make it
work. However I still have an unsolved stability problem with
cx25840. I've been trying for the past week to nail down this problem
but so far I haven't been very successful. Worse still, I think I
might have found a way to produce a similar stability problem on *old*
hardware using msp3400. (But I don't think people haven't been
generally seeing a problem there because of a coincidental way in
which the pvrusb2 driver loads the modules, which seems to lower the
chance of failure.)
Regardless, the next snapshot of the driver should include all the
changes needed to operate the new hardware.
-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