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

[Mike Isely]

This pvrusb2 driver snapshot has quite a few changes.  You can see the 
full list here:

   http://www.isely.net/pvrusb2-history.html#pvrusb2-mci-20060417

Some highlights:

1. The internal controls logic has been completely reworked since the last 
snapshot.  Long story.  Suffice to say that since it is all new code, 
there might be some new bugs here.  I've beat on it for the better part of 
a day and it looks good here - but having said that now there's probably 
some horrible thing that I might have missed :-)  Read the sysfs interface 
description on the pvrusb2 web page - enhancements have been added.

2. Video standard handling has been completely reworked.  The outward 
behavioral difference that you're going to see now is that the list of 
available standards in your V4L app should correspond closely with the 
hardware model you have.  Also, the list of standards you can choose from 
is very explicitly laid out, i.e. instead of PAL-B/G now there's PAL-B and 
PAL-G.  Support for some more obscure standard variants should be present 
now - so if you're in, say, Argentina, give this a try.  If the standard 
you want is not in the list, there are ways you can override the list now 
too.  If anyone sees a need for that, post here and I'll reply to the list 
with instructions.  Honestly I don't know how well these changes are going 
to work, because I live in NTSC territory so it's very hard to test the 
other possibilities.  So please let me know how this works.

3. Model 24xxx support is _considerably_ improved now.  You should no 
longer have to do the "force=-1,27" module option for wm8775, AND the 
obscure FWSEND fixup/patch in the cx25840 is not strictly needed anymore. 
Also, the bad failure scenario I had previously described where msp3400 
can come in and seriously screw up the system should be prevented now. 
It's still possible that the cx25843 chip can wedge itself, however now 
nothing "bad" should happen to the kernel anymore.  Those of you with 
model 24xxx devices, please let me know how well this works.  I strongly 
recommend using at least the 2.6.16 kernel for this.  It is theoretically 
possible that that 2.6.15 kernel will also work, but cx25840.ko is 
different there and I haven't gotten around to testing for it yet.

4. The fix to allow xawtv to work again for old hardware and to work at 
all for new hardware has been implemented.  The xawtv maintainer by the 
way never replied to my query related to this.

5. Compilation under amd64 should work better now.

Overall, this driver has a lot of new code.  It's possible that there are 
some regressions.  Hopefully not.  Please let me know how this works out. 
So far for me this new code is working great.

BTW, the thing I had to do to patch around the FWSEND issue definitely 
falls into the category of "deviant hack".  Clearly just lowering the 
maximum transfer size in cx25840.ko is the preferred way to go, but in an 
attempt to make it easier for people running 2.6.16 (for which this fix is 
not implemented), I created this workaround.  I do not expect this hack to 
find its way into the V4L resident version of the driver, since there it 
should never be needed.

Yes, I know the web page documentation is seriously lacking in content 
related to the new hardware.  That update is in the pipe.  I started 
writing new documentation a week ago; it just isn't ready yet.

Enjoy.

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