On Mon, 10 Mar 2008, Mark Goldberg wrote: > On Sun, Mar 9, 2008 at 10:32 PM, Mark Goldberg <[EMAIL PROTECTED]> wrote: > > On Sun, Mar 9, 2008 at 8:01 PM, Mark Goldberg <[EMAIL PROTECTED]> wrote: > > > It seems then the cx25840 is being initialized differently, for a > > > different video standard > > > and syncing to capure starting somewhere different in the vertical > > > interval. I don't know offhand > > > what the differences in the vertical sync are for different standards. > > > It does not seem to get that > > > it should be NTSC in the initialization. When I first started using > > > the driver, mythtv was setting > > > it to PAL and it would not capture smoothly. The symptoms are > > > different, but maybe explicity setting > > > the standards will help. Can I help this by putting video_std=X in > > modprobe.conf > > > for the pvrusb2 module? What do I put for NTSC-M? It does seem to get > > > to 48 kHz audio sampling > > > eventually. I dont see a module parm to set that. > > I tried this and it changes things in some places, but the results are > the same. It seems that the /sys interface, the v4lctl interface and > the dmesg messages from the drive do not all agree on what the > standard is. I can set things using the interfaces and video_std=X > in modprobe.conf, but nothing changed the vertical offset. It always > showed a bigger black bar with the vertical interval signal when the > new snapshot was used. With the same commands and settings, the > problem is only present with the new snapshot.
Mark: Sorry I'm not ignoring you; just working on other things (like my actual job)... Yes you can force a different standard as a module option. The value you specify is a decimal number that will be interpreted as a bit mask. The meanings of the bits are that which is defined in the v4l2_std bit mask, IIRC. (The pvrusb2 usage page where module options are described should provide more accurate detail.) Another strategy you can do is let the driver load with the defaults then use the sysfs interface to then force the standard to whatever you want. In that case you can then use symbolic values. I suggest you explore this now, but I may likely have to provide more information there. But I won't really get a chance to help at that level until Tuesday night at the earliest. > > > > > I downloaded the data sheet. It should discover the correct standard, > > except I think it can't tell NTSC-M from > > NTSC-J. How is the AFD_NTSC_SEL set? Do you set that explicitly, or is > > it done in the CX25840 > > driver? > > > > It would be a cheezy workaround, but if it were available to change > > VBLANK_CNT_LO and VBLANK_CNT_HI using the > > /sys interface, that would probably work. > > > > If that is fairly easy to try, give me a hint where to look in your > > driver and I'll try. In V4L there is a large bit mask which enumerates all the possible standards. An internal API is used where the main driver (i.e. pvrusb2) can tell all the various modules what standard(s) to apply. Being that this is a bit mask, multiple bits can be set at a time, though obviously it usually only makes sense to set a single bit. (In some PAL setups it actually makes sense to set 2 bits.) And unfortunately there seems to be use-cases in V4L where if the main driver isn't sure (e.g. NTSC-M vs NTSC-Mj) then it just sets both bits and hopes the module can deal with it. The pvrusb2 driver can control these standard bit combinations, and you can control the pvrusb2 driver's control of these through sysfs, the V4L API (of course), and/or module options. How the individual modules (e.g. cx25840) react to the declared standard(s) is up to those modules and can't be controlled by the pvrusb2 driver. So if setting a particular standard then has the effect of changing VBI settings in the module, the driver can't directly change those settings, only the overall standard. > > I can see that it appears that none of this is actually in your > driver. I'm not sure what more i can do at this point, I don't > understand the > kernel drivers nearly enough to even know where to look for something to > change. There's no way the driver can support this because there's no internal API from the cx25840 module that allows for that level of control. All we can do is tell it to use standard "XYZ" and then it's up to the module what to do after that point. For what it's worth, I've seen problems in the past where if the cx25840 module isn't initialized in a particular magic manner that it produces subtlely wrong results. This was also the root cause for why over a year ago I couldn't get 24xxx devices to do anything but 480 lines of resolution for a while. Turns out then I had to call a VBI initialization API entry point in the cx25840 module - even though VBI isn't at all being used in the pvrusb2 driver. The cx25840 module seems somewhat fragile in how it is controlled. Recent changes in the pvrusb2 driver should not have changed what we tell that module, though as you have seen there are changes which affect the relative timing of things that take place during initialization. Such timing changes should not cause any ill effects, but it's something to consider here. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
