Hi Russ,
I tried what you suggested on my PVR-500 rev. D492 using ivtv 0.3.4t,
at the same time I ran modprobe saa7127,cx25840,msp3400,ivtv in that
order as someone else suggested and I actually get video/audio now! Although the video comes through completely messed up. Its like the key frame comes in almost perfectly clear, then from that frame on you can barely make out the image until another key frame comes through good. Its not a static/tuning issue, it looks more like a codec issue. The audio seems fine though. One step further at least! On Sun, 2005-05-15 at 12:47 -0400, Russ Cox wrote: > > As Josh said, it all revolves around this parameter. Get the kernel to > > accept > > it, and you'll be good. Josh's mention of moving from 2.6.8 to 2.6.11 makes > > me > > think it may have something to do with the module changes that happened > > between > > the 2 versions. Just for reference, I have the exact same card (2 of them > > actually), and they work great. > > Thanks to both of you. I finally gave up trying to get the kernel > to take the parameter (somehow the options for cx25840 in my > /etc/modules.conf are not being passed by "modprobe ivtv") > and just changed the driver code to comment out the WI2C line. > Then I rebooted and it works fine (0.3.4p and 0.3.4q). > > For the archives, I'd like to point out that once you've loaded > a module without no_black_magic=1 and the WI2C line has > executed (meaning you've enabled the tuner by trying to use > /dev/video), the card is now broken until you cold reboot the > machine -- unloading the module and reloading it with the > right module parameter doesn't undo the damage. So you can't > try different things without rebooting between them -- if you do > you're not really trying different things. I think this was a big > source of my confusion. > > Two suggestions: > > - The cx25840 driver should figure out or be told by one > of the other modules that this is a PVR-150 Tuner 47 and set > no_black_magic appropriately, automatically. > > - The kernel message about ignoring module parameters > happened because linux/i2c.h defined some parameters > with MODULE_PARM but the modules were defining them with > module_param. Given a module with both, Linux only pays > attention to the MODULE_PARMs. So the modules need to > use module_param not just whenever it is available but only > when it is consistent with linux/i2c.h. 2.6.8's linux/i2c.h still > used MODULE_PARM. 2.6.10's linux/i2c.h uses module_param. > So I think the code that is deciding which to use should test > for 2.6.10+ (or 2.6.9+, maybe) instead of 2.6.0+. > > Thanks again. > Russ > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_ids93&alloc_id281&op=click > _______________________________________________ > ivtv-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- Mike Benoit <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
