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

[Mike Isely]

A new driver snapshot is available, pvrusb2-mci-20051126.  Nothing 
earth-shattering here:

I've successfully tested this under 2.6.15-rc2.

Starting with 2.6.15, there's a saa7115.ko available in the kernel tree. 
Unfortunately its API is completely alien to the saa7115.ko we've been 
using from ivtv.  A few weeks ago when I began reworking things for V4L I 
encountered this issue and wrote a new implementation of pvrusb2-video.c 
to use the new API.  However for the 20051113 snapshot of the driver one 
had to manually choose the right implementation (by default the snapshot 
was set up for the older ivtv specific API which is why nobody noticed any 
breakage).  That's a time bomb waiting to blow up for when the first 
person here tries 2.6.15 and assumes that the included saa7115.ko with 
that kernel should "just work".  So for this snapshot I've automated 
things so the choice can be made at run-time.  If you compile this 
snapshot under 2.6.15, then the new API will be used *if* the 
corresponding newer saa7115.ko has been detected as being loaded. 
Basically what this means for you all is that more stuff will magically 
work correctly :-)  (I hope)

I've further complicated pvrusb2-eeprom with another "direct" 
implementation that eliminates all the hackery (see diatribe in 
pvrusb2-eeprom.html).  This choice is not enabled by default; I 
implemented it with an eye towards it being used when the driver is 
compiled into V4L (where the ugly hack should never be needed).

There are some compile time switches defined in driver/compat.h now. 
These can be tweaked to adjust various aspects for how the driver is 
built.  You don't *need* to touch this, as it should all magically work by 
itself.  My real motive for this was not to give more ways to screw this 
up but rather to provide a means for compilation to adapt automatically 
depending on whether the driver is built standalone (like we've always 
done here) or as part of V4L.  When compiled inside of V4L, this header 
(compat.h) is replaced by something else entirely, in which case all those 
switches end up taking default values which just happens to be exactly 
what is needed in V4L.  Coincidence?  I think not :-)

There are some more interesting changes that should be coming soon in the 
driver.  In addition to further work towards V4L, the 0.5.0 snapshot of 
ivtv came with a document that fairly completely describes the programming 
API of the encoder chip.  I've already skimmed this document and realized 
some mistakes I've made and I see opportunity for additional functionality 
(like perhaps other video formats).  So barring other distractions I 
should have some more interesting stuff coming soon.

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