[pvrusb2] pvrusb2 driver status for new hardware version

[Hans Verkuil]

On Monday 06 March 2006 14:42, Mike Isely wrote:
> On Mon, 6 Mar 2006, Hans Verkuil wrote:
> > On Monday 06 March 2006 05:13, Mike Isely wrote:
> >>    5. There is an as-yet unidentified new part on the board
> >> responding at I2C address 0x1b.
> >
> > This is almost certainly the wm8775 chip, the same that is also
> > used on PVR150/500 cards. That chip also uses I2C address 0x1b.
>
> Could somebody here with the new device please open it up and confirm
> the existence of this part?
>
> >>    o With the appearance of the cx25840, we now have another
> >> firmware image to deal with.  While the cx25840.ko module handles
> >> the loading of the firmware image, we still need to extract it
> >> from the Windows drivers (and this firmware image apparently is
> >> *different* than the one(s) used for ivtv, unfortunately - no idea
> >> yet if they're compatible).
> >
> > Are you sure they are different? Can you mail me the firmware you
> > extracted?
>
> Yes, I'm positive.  In fact after extracting it I compared it against
> the three other variants of this firmware floating around and it
> didn't match any of them.  The first 8 bytes or so are similar in all
> cases but that's about it.  And this firmware *does* work.  I'll
> e-mail it to you.

Thanks. I wonder if this isn't a somewhat older firmware than the 
ivtv-recommended fw. I know of two firmwares: an older one (13883 bytes 
long) that should be avoided at least for PAL/SECAM and a newer version 
(14264 bytes long) that seems to work well with all standards. This fw 
is even smaller than the old one that is known to have problems. It's 
hard to tell as there is no version string embedded in the firmware.

But in any case you should be aware that the audio autodetection (which 
is handled by this firmware) is more difficult when dealing with 
PAL/SECAM standards compared to NTSC. So any problems with the firmware 
are unlikely to show up with NTSC. To my knowledge all firmware 
versions work fine with NTSC.

You can usually tell problems like that by sending the VIDIOC_LOG_STATUS 
i2c command to the cx25840 and checking the following:

   cx25840 5-0044: Video signal:              not present
   cx25840 5-0044: Detected format:           PAL-Nc
   cx25840 5-0044: Detected audio mode:       stereo
   cx25840 5-0044: Detected audio standard:   no detected audio standard
   cx25840 5-0044: Audio muted:               yes
   cx25840 5-0044: Audio microcontroller:     running
   cx25840 5-0044: Configured audio standard: automatic detection
   cx25840 5-0044: Configured audio system:   automatic standard and 
mode detection
   cx25840 5-0044: Specified standard:        PAL-BDGHI
   cx25840 5-0044: Specified video input:     Composite 7
   cx25840 5-0044: Specified audio input:     Tuner (In8)
   cx25840 5-0044: Specified audioclock freq: 48000 Hz
   cx25840 5-0044: Preferred audio mode:      stereo
   cx25840 5-0044: Selected 65 MHz format:    autodetect
   cx25840 5-0044: Selected 45 MHz format:    chroma

If there are problems then 'Detected audio standard' is completely wrong 
or simply not detecting an audio standard. 

Note that for external (i.e. non-tuner) inputs the audio microcontroller 
is stopped and no audio standard detection is used (it's tuner 
specific).

>
> >>    o We don't know yet what the correct input settings on the
> >> cx25840 should be for the composite or s-video inputs on the
> >> device.
> >
> > It's likely to be the same as the PVR150. This PVRUSB2 device seems
> > to be basically a PVR150 with an USB interface.
>
> Well possibly.  But since I don't have a PVR150 to compare with I
> can't be sure.  Also we're limited here by what the FX2 controller
> will perform on behalf of the host.  We had discussed before the
> possibility of getting VBI working and I had noted at the time that
> the FX2 firmware seemed to support operation of another USB endpoint
> for additional data, like perhaps VBI outside of the mpeg2 stream. 
> The firmware in the new device seems to have removed the commands for
> operation of that endpoint :-(

Ouch.

	Hans