[pvrusb2] Grabster AV400 and TS support..

[Andrea Venturi]

Il 05/10/2013 05:00, Mike Isely ha scritto:
> ....
>> 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.

i see what you mean..
let me tell you i'm not prepared to make a big earthshake on the pvrusb2 
linux driver (and/or on the ivtv/PVR250) because they are pretty stable 
as they are now and the feature(s) i'd like to exploit in the CX2341X 
firmware are really not described at all in any public document so we 
are really shotting in the dark here..

i'd like to make eventually thorough tests on private code branch (if 
it's fun and not takes too much time for each iteration..) but i suppose 
this stuff would not meet QA mainline kernel checks anytime soon.

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

i suppose this "FW reloading" is a bit of a "last resort" strategy with 
some corner cases not dealt with but anyway it's reassuring we do not 
bring down the system here! :-)

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

this is intriguing. please elaborate a bit because i've made some trials 
and i'm a bit puzzled.
do you think the encoder firmware from that "tree" are not 
inter-changeable with the ones in bundle with PVRUSB2 windows drivers?
they both are related to CX2341x chip that's pretty the same in both 
devices.

i supposed many were the same but i need to make a comparison (you 
didn't harvest all the firmware "strictly" related to 
PVRUSB2/Terratec/GotoView/other incarnation of FX2+CX2341X, do you?)

i took my time downloading and extracting and versioning all the FW from 
that list and this is the result:

andrea at nb3-andrea:~/fw$ md5sum v4l-cx2341x-enc-v*
732b0db829dc381e19f5a1be946c9650 v4l-cx2341x-enc-v1.10.113.fw
1ead5b06450181909d4dab694518dc36 v4l-cx2341x-enc-v1.13.000.fw
2c8e0c0ee34cf156e82d9a8964e8f221 v4l-cx2341x-enc-v1.13.200.fw
69334c99224165bde0d697c081e6398f v4l-cx2341x-enc-v2.01.666.fw
e49e505b06a07633a34baf78b53e8189 v4l-cx2341x-enc-v2.01.703.fw
b71cd3c599b53f1739fc9bfb933620b6 v4l-cx2341x-enc-v2.02.003.fw
72e4cb8506c7a4cd44c72373e63b11d0 v4l-cx2341x-enc-v2.02.021.fw
c8072002c9dd0d5b73797f2e36ed21d6 v4l-cx2341x-enc-v2.02.203.fw
e7d6d7f385b80d43f64108fcc7ea978c v4l-cx2341x-enc-v2.03.021.fw
839fb0b71324fa2ef3c7c43a17a41396 v4l-cx2341x-enc-v2.03.207.fw
6cbacdb83b60f40c04a5cc7ff354d7e8 v4l-cx2341x-enc-v2.04.002.fw
2c97465a4528807709301899630ba0e1 v4l-cx2341x-enc-v2.04.008.fw
6e2012d919fa48811c27e25e54a0a5dc v4l-cx2341x-enc-v2.04.024.fw
ab75947ef1b086e26f9b08e628baa02e v4l-cx2341x-enc-v2.04.211.fw
79c5daf4cde87036c834a314b4929fb1 v4l-cx2341x-enc-v2.05.028.fw
d85cb08382395390dc95ac6ebc2205f9 v4l-cx2341x-enc-v2.05.032.fw
9b39b3d3bba1ce2da40f82ef0c50ef48 v4l-cx2341x-enc-v2.06.039.fw

in the "CX2341X history", "TS generation" was told to be correlated with 
"very old firmware".. as here:

  http://ivtvdriver.org/pipermail/ivtv-devel/2007-April/004646.html

so i've been very thrilled to see that the first three firmware in my 
collection are of a 1.x.y branch, all the others are from a 2.z.k.

in my simple mind, that was pretty saying the TS feature was there, in 
the 1.x branch and then removed.

anyway now that you make me think about it, this TS generation "could" 
be eventually enabled not only by some proper firmware but also with 
some special purpose "HW wiring" in the device..

i've been indeed able to put the HAS_TS capability with a one liner in 
pvrusb2-hdw.c funct. pvr2_hdw_create():

         .......
         cx2341x_fill_defaults(&hdw->enc_ctl_state);

         /* 20131003 aventuri: set up HAS_TS */
         hdw->enc_ctl_state.capabilities |= CX2341X_CAP_HAS_TS;
         .......

so i've been able to make experiments both with a 2.x and 1.y firmwares.

in both i've been able to make the change in the sysfs control with:

   #echo -n "MPEG-2 Program Stream" > ctl_stream_type/cur_val

with no signs of error in dmesg.

but with 2.x branch firmware, capturing the stream (cat /dev/video0 > 
xxx.ts) for a while and exiting with ctrl-C has resolved in a empty file.

wth the 1.y branch firmware, i was unable to make any capture, both as 
MPEG PS or TS, because the "cat /dev/video0 > xxx.ts" badly hanged and 
ctrl-C was unable to stop that too.
i had to remove the dongle to end the cat process.. the pvrusb2 driver 
was a bit upset.

now you make me think the 1.x CX2341X FW could not be consistent with 
the PVRUSB2 device.

someone could eventually check this behavior swapping the firmware in 
their own setup for confirm.

bests

andrea