[pvrusb2] Grabster AV400 and TS support..

[Mike Isely]

On Wed, 2 Oct 2013, Andrea Venturi wrote:

> hello everybody,
> 
> it's quite a long time since i've been trying to hack my Grabster AV400 on
> linux..
> 
> http://www.isely.net/pipermail/pvrusb2/2007-March/001468.html
> 
> still i see it's marked experimental on mainline kernel but anyway it works
> out of the box quite smoothly.

One reason why is because I don't have one of these devices so I can't 
regression test it.  And (aside from you) I really don't have a lot of 
3rd party feedback to tell me that the driver is working well with it.

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


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


> 
> 
> i've tried this 2.4.211 firmware and the stock 2.6.39
> 
>  $ strings /lib/firmware/v4l-cx2341x-enc-v2.06.039.fw | grep Version
>  Version 2.06.039
>  $ md5sum /lib/firmware/v4l-cx2341x-enc-v2.06.039.fw
>  9b39b3d3bba1ce2da40f82ef0c50ef48 /lib/firmware/v4l-cx2341x-enc-v2.06.039.fw
> 
> but i fail to see the transport stream item in the sysfs menu:
> 
>  root at nb3-andrea:/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-2/pvrusb2/unit-a#
> cat ctl_stream_type/enum_val
>  MPEG-2 Program Stream
>  MPEG-1 System Stream
>  MPEG-2 DVD-compatible Stream
>  MPEG-1 VCD-compatible Stream
>  MPEG-2 SVCD-compatible Stream
> 
> i don't really understand if the "capability"  CX2341X_CAP_HAS_TS is
> autosensed by the driver or has to be forced (via c code like i tried or via
> sysfs if it's at least present in the enum_val list).

Well the issue here is that the pvrusb2 driver does not in any way 
attempt to discriminate between firmware blob "versions".  It treats 
them all the same.  So it can't report different capabilities based on 
the firmware loaded.

In addition the actual control of the mpeg encoder these days (actually 
for many years) has been through a module in the v4l core.  Likely it's 
in that spot where any kind of version-specific behavior would have to 
be coded (and then propagated through the pvrusb2 driver).


> 
> ===========
> int pvr2_encoder_configure(struct pvr2_hdw *hdw)
> {
>         int ret;
>         int val;
>         pvr2_trace(PVR2_TRACE_ENCODER,"pvr2_encoder_configure"
>                    " (cx2341x module)");
>         hdw->enc_ctl_state.port = CX2341X_PORT_STREAMING;
>         hdw->enc_ctl_state.width = hdw->res_hor_val;
>         /* 20131002 aventuri: forcing TS support for testing old 2.4.211 fw */
>         hdw->enc_ctl_state.capabilities = CX2341X_CAP_HAS_TS;
>         ....
> ===========
> 
> i've some difficult to follow the logic between pvrusb2-encoder.c and
> cx2341x.c, BTW sometime it seems to me they do have overlapped functions and
> it's not clear which is the one called in this case (i suppose the driver push
> for its own implementation "pvrusb-*".

Yes, that's part of what I was alluding to above.  The module cx2341x.c 
is part of the v4l core and is used by all v4l drivers that have to 
operate this mpeg encoder chip.  What you see in pvrusb2-encoder.c is 
basically the interface to drive that module - code to tell the module 
to issue commands, and glue logic that allows the module in return to 
cause the pvrusb2 driver to flip the appropriate bits at the far end of 
the USB cable that communicate those commands into the hardware.  The 
module understands the commands and their formats, while the pvrusb2 
driver knows when it wants to trigger specific commands and can 
communicate the formatted command data from that module into the 
hardware.

The "standalone" pvrusb2 driver (not the one in the kernel tree) has 
additional logic that allows it to operate without the use of the 
cx2341x.c module.  This is because pvrusb2-encoder.c existed long before 
cx2341x.c appeared in v4l, and the standalone driver is constructed in a 
way that allows it to substitute its own functionality if the kernel 
build environment is too old to have the needed v4l functionality.  It's 
all stuff for backwards compatibility.

However I suspect that since I haven't issued an updated standalone 
driver in a very long time that it likely doesn't even compile any more 
with recent kernels.  But that's not a fatal problem since the 
standalone driver really makes more sense for very old kernels and the 
in-kernel supplied driver already has all of the same functionality 
anyway.


> 
> after this first stab at the task, i though it would be more effective to ask
> proficient folks (Mike, are you still there? this list seems a bit frozen)
> here for hints/comment.

Yeah, I'm here.  It's just been quiet.


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


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


> - is the TS support to be manually enabled in the pvrusb2 driver or there's
> some kind of autosensing,

See above.


> 
> finaly what it the problem for the Grabster to still stay in experimental
> mode? jsut missing QA?

Also see above.  Short answer: yes, I have no way to regression test it 
and I haven't gotten a whole lot of feedback either from others (until 
your post here).


> 
> maybe i can help here consolidate the code and finally take away that message
> on "dmesg" that talks about "helping developers clean the rug!"

Yup :-)

  -Mike

-- 

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