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

[Hans Verkuil]

On Monday 10 March 2008 22:41:00 Mike Isely wrote:
> On Mon, 10 Mar 2008, Mark Goldberg wrote:
> > On Sun, Mar 9, 2008 at 10:32 PM, Mark Goldberg 
<marklgoldberg at gmail.com> wrote:
> > > On Sun, Mar 9, 2008 at 8:01 PM, Mark Goldberg 
<marklgoldberg at gmail.com> 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.

Mike, you might want to take a look at ivtv-driver.c: for ivtv I've made 
module options that allow you to do things like 'ntsc=m' and 'pal=bg', 
that's generally easier than figuring out the bit mask.

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

The general rule is that for special cases the exact standard has to be 
set (e.g. for NTSC-JP only that standard must be set), otherwise the 
more general standard is chosen. So setting NTSC-J|NTSC-M will 
generally pick NTSC-M, unless the hardware is smart enough to detect 
which standard is actually received.

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

Yeah, that code should really be moved from out of cx25840-vbi.c, it's 
something that really needs to be cleaned up. Hysterical reasons :-)

I've tested ivtv/cx25840 last Sunday with all sorts of different 
standards and it was all working perfectly (except for a minor issue 
with PAL-M).

Regards,

	Hans