[pvrusb2] Grabster AV400 and TS support..

[Mike Isely]

Comments interspersed below...


On Thu, 3 Oct 2013, Andrea Venturi wrote:

> Il 03/10/2013 07:23, Mike Isely ha scritto:
> > On Wed, 2 Oct 2013, Andrea Venturi wrote:
> > 
> > ...However with that said, it's been quite a while and there certainly
> > haven't been any complaints so I guess I should get off my *ss and get the
> > "experimental" designation removed... 
> 
> maybe let me do some more tests in the next few days to refresh Terratec
> status and we'll see if the experiment mark is ready to go..

OK.

> 
> are you willing to bring forward some janitorial patches, eventually?

Of course.


> 
> 
> > 
> > > i'm writing here because i'd like to finally test the Transport Stream
> > > internal generation.
> > > 
> > > i've read here and there on the web and it says it's a feature available
> > > only
> > > on "old" encoder firmware.
> > > 
> > > BTW i've seen that you can get an idea of a firmware version if you give a
> > > look at string Version inside encoder firmware, as in:
> > > 
> > >   $ strings /lib/firmware/v4l-cx2341x-enc.fw | grep Version
> > >   Version 2.04.211
> > >   $ md5sum /lib/firmware/v4l-cx2341x-enc.fw
> > >   ab75947ef1b086e26f9b08e628baa02e  /lib/firmware/v4l-cx2341x-enc.fw
> > That's very interesting.  I was unaware that these opaque firmware blobs
> > had any means for being version controlled at all.
> 
> i saw in cx2341x.h, there's a API command called CX2341X_ENC_GET_VERSION and
> it matches with the string embedded.

That would be useful, were the driver to be modified to adjust its 
behavior based on what it gets - which is obviously where you're headed 
here.


> 
> 
> >    Since I have no
> > documentation on the machine language used by the encoder (all that
> > really exists in the community is a semi-complete ABI for communicating
> > with the part), I've never even tried to reverse-engineer the blob.  I
> > should update the fwextract program to annotate its output with the
> > embedded version information.
> 
> in my further attempts to gain some skill on driver modding and insight on
> capabilities, i've put this piece of code in a place where it should have been
> called: "pvr2_encoder_prep_config()" in pvrusb2-encoder.c
> 
> ===========
>         u32 retData;
>         if (!pvr2_encoder_cmd(hdw, CX2341X_ENC_GET_VERSION, 0, 1, &retData)) {
>                 pvr2_trace(
>                         PVR2_TRACE_ERROR_LEGS,
>                         "Firmware version: %x.%x.%x",
>                         retData>>24&0xff, retData>>16&0xff, retData&0xffff);
>         } else {
>                 pvr2_trace(
>                         PVR2_TRACE_ERROR_LEGS,
>                         "Firmware version not returned");
>         }
> ==========
> 
> and i get indeed a consistent output when i do a capture with "cat
> /dev/video0/ > /dev/null".
> 
> in dmesg i find (with debug=0x40001f in pvrusb2 module load):
> ...
> [10134.320514] pvrusb2: pvr2_encoder_configure (cx2341x module)
> [10134.333540] pvrusb2: Firmware version: 2.4.11
> ...
> 
> of course this informative call would need to be put after firmware upload
> into encoder, not when starting real encoding..

Also realize that the pvrusb2 driver can force a reload of the firmware 
if the encoder chip hangs (which unfortunately happens).  Not just when 
the driver comes up.  In fact on hybrid devices this might even happen 
when switching between analog and digital modes.  This reload happens 
pretty quickly but nonetheless we would need to reconfirm the firmware 
version and possibly adjust driver behavior to match, which may turn 
into a rabbit hole if we're not careful.


> 
> BTW ivtv driver has a special page related to "firmware versions":
> 
>   http://ivtvdriver.org/index.php/Firmware_versions
> 
> and here there's "trace" of this version 2.4.11 (11 is a typo, i suppose.. it
> should be 2.4.211):
> 
> ====
> PVR250/350
>    Encoder: 0x02040011, md5sum ab75947ef1b086e26f9b08e628baa02e
> ====

Yes, I see that page now.  But that's talking about ivtv versions and 
recommended firmware versions related to software and hardware versions.  
On the pvrusb2 side this really isn't an issue.


> 
> > 
> > 
> > > ...
> > 
> > > so the first questions:
> > > 
> > > - has TS support been scrapped from the pvrusb2 driver?
> > No, but it was never added either.  TS support is purely a question at
> > the encoder chip level; the pvrusb2 driver doesn't do anything to help
> > (or hinder) that.  It never has.
> 
> good.
> 
> > 
> > > - which is one firmware version known to be available for my tests
> > No idea.  The driver doesn't discriminate firmware versions at all - it
> > treats them all exactly the same.  This is sounding like we would need
> > to add new functionality to detect the version of the loaded cx2341x
> > firmware blob and then run-time adjust the behavior of cx2341x.c,
> > pvrusb2-encoder.c and very likely also pvrusb2-hdw.c (which defines all
> > knobs / switches visible in sysfs).  Nothing of that concept exists in
> > the driver - it never has been there.
> 
> i suppose that, for next test, if i force "pvrusb2-hdw." to show "MPEG-2
> Transport Stream" in sysfs ctl_stream_type control file, i can try to make the
> API firmware set TS and see if it returns an ERROR or OK ack..
> 
> in the cx2341x.c there's some code for switching between a "having TS" and
> "not having TS" but maybe it's just supported on the ivtv/pvr250 driver.

It's certainly not supported in the pvrusb2 driver, but that does not 
mean it can't be supported...

Once we have something we can key off of, then the driver can modify its 
behavior to match.  The driver does have other places where it modifies 
its behavior based on what it figures out about the hardware - notably 
with IR handling, since that changed incompatibly multiple times through 
the lifecycle of several Hauppauge models.

  -Mike


-- 

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