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

[Mike Isely]

On Sun, 9 Mar 2008, Mark Goldberg wrote:

> On Sun, Mar 9, 2008 at 12:46 PM, Mike Isely <isely at isely.net> wrote:
> >  Then it sounds like you have some bug chasing to do.  Good luck :-)
> >
> >  Note: I'm not the maintainer of that module and I'm hardly an expert on
> >  it.  But at least one other person on this list knows quite a bit about
> >  its internals.  If you find something and he doesn't speak up first,
> >  I'll do what I can to help you get any fixes applied...
> 
> It is pretty strange. I brought both up and started a capture, then
> compared the dmesg messages from that
> module. The only differences were
> 
> diff -C 5  old_pvrusb2_module_short new_pvrusb2_module_short
> *** old_pvrusb2_module_short    2008-03-09 16:52:38.000000000 -0700
> --- new_pvrusb2_module_short    2008-03-09 16:52:03.000000000 -0700
> ***************
> *** 1,10 ****
>   cx25840 X-0044: Video signal:              not present
>   cx25840 X-0044: Detected format:           NTSC-M
> ! cx25840 X-0044: Specified standard:        NTSC-M
>   cx25840 X-0044: Specified video input:     Composite 7
> ! cx25840 X-0044: Specified audioclock freq: 48000 Hz
>   cx25840 X-0044: Detected audio mode:       mono
>   cx25840 X-0044: Detected audio standard:   no detected audio standard
>   cx25840 X-0044: Audio muted:               yes
>   cx25840 X-0044: Audio microcontroller:     running
>   cx25840 X-0044: Configured audio standard: automatic detection
> --- 1,11 ----
>   cx25840 X-0044: Video signal:              not present
>   cx25840 X-0044: Detected format:           NTSC-M
> ! cx25840 X-0044: Specified standard:        automatic detection
>   cx25840 X-0044: Specified video input:     Composite 7
> ! cx25840 X-0044: Specified audioclock freq: 44100 Hz
> ! cx25840 X-0044: decoder set video input 7, audio input 8
>   cx25840 X-0044: Detected audio mode:       mono
>   cx25840 X-0044: Detected audio standard:   no detected audio standard
>   cx25840 X-0044: Audio muted:               yes
>   cx25840 X-0044: Audio microcontroller:     running
>   cx25840 X-0044: Configured audio standard: automatic detection
> 
> in the initialization.
> The settings
> 
> hblank 122, hactive 720, vblank 26 , vactive 487, vblank656 26,
> src_dec 543,burst 0x5b, luma_lpf 1, uv_lpf 1, comb 0x66, sc 0x087c1f
> 
> are the same as are the clocks, etc.
> 
> What is different is the  X-0044: in the dmesg messages. For the old
> module, the X is a 2
> For the new module, the X is a 3. Does that mean it finds it at a
> different address?

I believe the "X" is just an instance number to help differentiate 
multiple instances of the module running in the kernel (if for example 
you had two capture devices with a cx25840).  A different value for the 
X would be consistent with the fact that the drivers are coming up in a 
different order now.

I really find it hard to believe that one instance of cx25840 might 
possibly interact with another instance, but I guess it should probably 
be ruled out.  (I know FOR A FACT that multiple instances of the pvrusb2 
can't interact - it's just basic to the driver architecture, but for 
cx25840 I can't make the same statement since I'm not the expert there.)

You could rule out "instance issues" by temporarily removing the other 
capture card or (more easily) just temporarily renaming its driver 
module so that it won't get loaded.  Obviously this would not be a 
solution but it could yield another clue.


> 
> It is not obvious how what I see above would shift the vertical
> interval, but the problem is really there.
> 
> Is there any chance it could be the mpeg encoder? I put debug=1 for it
> in modprobe.conf but don't see
> any messages from it at all anywhere.

No, I do not believe it's possible for the mpeg encoder to do this.  The 
data ia already in a framebuffer format by the time the encoder stage is 
reached.  You're describing what amounts to a framing problem so I 
wouldn't expect the encoder to be an influence here.

The encoder's module is different than the others.  While the other 
modules are all I2C client modules, the encoder doesn't talk to use 
through I2C.  So the API there is entirely different and the structure 
of the cx2341x module is completely different than the others.  It's 
also a fairly simple module which hasn't changed in a while so I 
wouldn't expect this to be a factor.  There have been some changes here 
on the pvrusb2 side, but the changes happened roughly last October, 
several versions back before you said you started seeing this issue.


> 
> I always get these kind of problems.

You're not alone in hitting bizarre problems.  I've had my share :-)  Go 
back to December 2005 and witness a wild goose chase I undertook with 
a B&W video problems - which ended up being due to bad hardware.  Stupid 
me; if I had just tried it once under Windows I would have know right 
away rather than wasting weeks looking for a pvrusb2 driver bug!

  -Mike

-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8