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

[xavier.gnata at free.fr]

Hi,

As usual, I going to test this snapshot asap.
Could you tell us a little bit more about "additional functionalities".
For sure, I could wait your next email but "other video formats" sounds so
interresting...

xavier


> 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
>                          |                             |
> _______________________________________________
> pvrusb2 mailing list
> pvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>