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

[Mike Isely]

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.


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