Chipset change for CX88_BOARD_PINNACLE_PCTV_HD_800i

Chipset change for CX88_BOARD_PINNACLE_PCTV_HD_800i

[Mack Stanley]

Dear Mr. Pascoe,

I'm writing to you as the maintainer of the cx88-dvb kernel module.

I recently bought a pci tv card that the kernel identifies as supported:

05:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05)
Subsystem: Pinnacle Systems Inc. Device [11bd:0051]

My card appears to be the same card as this Pinnacle card
(http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_HD_Card_%28800i%29)
except that it has a Samsung S5H1411 chip in place of the S5H1409 on the
original Pinnacle card identified by the kernel. 

My card is branded "PCTV HD PCI Card 800i"
(http://www.pctvsystems.com/Products/ProductsNorthAmerica/HybridproductsUSA/PCTVHDCard/tabid/171/language/en-US/Default.aspx),
though I bought it as a Hauppauge card
(http://www.newegg.com/Product/Product.aspx?Item=15-116-043&SortField=0&SummaryType=0&Pagesize=10&PurchaseMark=&SelectedRating=-1&VideoOnlyMark=False&VendorMark=&IsFeedbackTab=true&Keywords=linux&Page=1#scrollFullInfo).

Because of the changed chip, "dvb_attach" returns NULL, so the cx88-dvb
module fails to insert, and no /dev/dvb nodes are created. 

I was able to get around this by copying s5h1411_config
dvico_fusionhdtv7_config to a new
"s5h1411_config pinnacle_pctv_hd_800i_config", then replacing
s5h1409_attach with s5h1411_attach in
case CX88_BOARD_PINNACLE_PCTV_HD_800i in the definition of dvb_register.

I built against headers for Fedora 16 kernel 3.3.8-1.fc16.x86_64.  The
result loads normally and creates /dev/dvb/adaper0 containing demux0, 
dvr0,  frontend0,  and net0. 

"w_scan -fa -A2 -c US -x " produces a long list of frequencies, all but
two of which are in us-Cable-IRC-center-frequencies-QAM256. However,
w_scan finds no "services" and I haven't been able to coax either
scandvb or scte65scan into finding any channels. I don't know whether
this is because my shot-in-the-dark modification to cx88-dvb doesn't
work, or because Comcast has some screwy way of sending signals to its
DTA's.

I'm of course more than happy to help in any way.

Thanks for your time,
Mack

Re: Chipset change for CX88_BOARD_PINNACLE_PCTV_HD_800i

[Devin Heitmueller]

On Wed, Jun 20, 2012 at 5:31 PM, Mack Stanley <mcs1937@gmail.com> wrote:
> Dear Mr. Pascoe,
>
> I'm writing to you as the maintainer of the cx88-dvb kernel module.
>
> I recently bought a pci tv card that the kernel identifies as supported:
>
> 05:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
> CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05)
> Subsystem: Pinnacle Systems Inc. Device [11bd:0051]
>
> My card appears to be the same card as this Pinnacle card
> (http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_HD_Card_%28800i%29)
> except that it has a Samsung S5H1411 chip in place of the S5H1409 on the
> original Pinnacle card identified by the kernel.
>
> My card is branded "PCTV HD PCI Card 800i"
> (http://www.pctvsystems.com/Products/ProductsNorthAmerica/HybridproductsUSA/PCTVHDCard/tabid/171/language/en-US/Default.aspx),
> though I bought it as a Hauppauge card
> (http://www.newegg.com/Product/Product.aspx?Item=15-116-043&SortField=0&SummaryType=0&Pagesize=10&PurchaseMark=&SelectedRating=-1&VideoOnlyMark=False&VendorMark=&IsFeedbackTab=true&Keywords=linux&Page=1#scrollFullInfo).
>
> Because of the changed chip, "dvb_attach" returns NULL, so the cx88-dvb
> module fails to insert, and no /dev/dvb nodes are created.
>
> I was able to get around this by copying s5h1411_config
> dvico_fusionhdtv7_config to a new
> "s5h1411_config pinnacle_pctv_hd_800i_config", then replacing
> s5h1409_attach with s5h1411_attach in
> case CX88_BOARD_PINNACLE_PCTV_HD_800i in the definition of dvb_register.
>
> I built against headers for Fedora 16 kernel 3.3.8-1.fc16.x86_64.  The
> result loads normally and creates /dev/dvb/adaper0 containing demux0,
> dvr0,  frontend0,  and net0.
>
> "w_scan -fa -A2 -c US -x " produces a long list of frequencies, all but
> two of which are in us-Cable-IRC-center-frequencies-QAM256. However,
> w_scan finds no "services" and I haven't been able to coax either
> scandvb or scte65scan into finding any channels. I don't know whether
> this is because my shot-in-the-dark modification to cx88-dvb doesn't
> work, or because Comcast has some screwy way of sending signals to its
> DTA's.
>
> I'm of course more than happy to help in any way.
>
> Thanks for your time,
> Mack

Hmmm, ok.  Let me talk to my contacts at PCTV and see what the deal is
there.  My guess is the 1409 reached end of life, so they had to
switch to the 1411.

I'm pretty surprised that they didn't bump the PCI ID though.  I'll
find out if they're relying on the eeprom to know which demod is
present.

The scan is probably failing due to something like a mismatched IF
output frequency.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Chipset change for CX88_BOARD_PINNACLE_PCTV_HD_800i

[Mack Stanley]

On 06/20/2012 03:14 PM, Devin Heitmueller wrote:
> On Wed, Jun 20, 2012 at 5:31 PM, Mack Stanley <mcs1937@gmail.com> wrote:
>> Dear Mr. Pascoe,
>>
>> I'm writing to you as the maintainer of the cx88-dvb kernel module.
>>
>> I recently bought a pci tv card that the kernel identifies as supported:
>>
>> 05:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
>> CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05)
>> Subsystem: Pinnacle Systems Inc. Device [11bd:0051]
>>
>> My card appears to be the same card as this Pinnacle card
>> (http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_HD_Card_%28800i%29)
>> except that it has a Samsung S5H1411 chip in place of the S5H1409 on the
>> original Pinnacle card identified by the kernel.
>>
>> My card is branded "PCTV HD PCI Card 800i"
>> (http://www.pctvsystems.com/Products/ProductsNorthAmerica/HybridproductsUSA/PCTVHDCard/tabid/171/language/en-US/Default.aspx),
>> though I bought it as a Hauppauge card
>> (http://www.newegg.com/Product/Product.aspx?Item=15-116-043&SortField=0&SummaryType=0&Pagesize=10&PurchaseMark=&SelectedRating=-1&VideoOnlyMark=False&VendorMark=&IsFeedbackTab=true&Keywords=linux&Page=1#scrollFullInfo).
>>
>> Because of the changed chip, "dvb_attach" returns NULL, so the cx88-dvb
>> module fails to insert, and no /dev/dvb nodes are created.
>>
>> I was able to get around this by copying s5h1411_config
>> dvico_fusionhdtv7_config to a new
>> "s5h1411_config pinnacle_pctv_hd_800i_config", then replacing
>> s5h1409_attach with s5h1411_attach in
>> case CX88_BOARD_PINNACLE_PCTV_HD_800i in the definition of dvb_register.
>>
>> I built against headers for Fedora 16 kernel 3.3.8-1.fc16.x86_64.  The
>> result loads normally and creates /dev/dvb/adaper0 containing demux0,
>> dvr0,  frontend0,  and net0.
>>
>> "w_scan -fa -A2 -c US -x " produces a long list of frequencies, all but
>> two of which are in us-Cable-IRC-center-frequencies-QAM256. However,
>> w_scan finds no "services" and I haven't been able to coax either
>> scandvb or scte65scan into finding any channels. I don't know whether
>> this is because my shot-in-the-dark modification to cx88-dvb doesn't
>> work, or because Comcast has some screwy way of sending signals to its
>> DTA's.
>>
>> I'm of course more than happy to help in any way.
>>
>> Thanks for your time,
>> Mack
> Hmmm, ok.  Let me talk to my contacts at PCTV and see what the deal is
> there.  My guess is the 1409 reached end of life, so they had to
> switch to the 1411.
>
> I'm pretty surprised that they didn't bump the PCI ID though.  I'll
> find out if they're relying on the eeprom to know which demod is
> present.
>
> The scan is probably failing due to something like a mismatched IF
> output frequency.
>
> Devin
>
Hi Devin,

Thanks very much for your help.

In fact, it seems I have the card working, following your suggestion
about the channel scan failing. But I suspect something is still missing
or worng.

I've been able to successfully scan for channels with scandvb and get a
usable channel.conf using scte65scan. But selecting channels is erratic.

mplayer [various options] dvb://6

tunes to different channels different times, sometimes to video from one
channel and sound from another, sometimes to video but no sound.

I just took some setting from the old 1409 configuration and used them
for the 1411 chip:

static const struct s5h1411_config pinnacle_pctv_hd_800i_config = {
  .output_mode   = S5H1411_PARALLEL_OUTPUT,
  .gpio          = S5H1411_GPIO_ON,
  .mpeg_timing   = S5H1411_MPEGTIMING_NONCONTINOUS_NONINVERTING_CLOCK,
  .qam_if        = S5H1411_IF_44000,
  .vsb_if        = S5H1411_IF_44000,
  .inversion     = S5H1411_INVERSION_OFF,
  .status_mode   = S5H1411_DEMODLOCKING
};

I'll be interested in what your contacts at pctv suggest.

Best, Mack

Re: Chipset change for CX88_BOARD_PINNACLE_PCTV_HD_800i

[Devin Heitmueller]

On Thu, Jun 21, 2012 at 6:43 PM, Mack Stanley <mcs1937@gmail.com> wrote:
> mplayer [various options] dvb://6
>
> tunes to different channels different times, sometimes to video from one
> channel and sound from another, sometimes to video but no sound.

I would try tuning to the same channel multiple times and see if it
behaves *consistently*.  In other words, does it always tune to the
same "wrong" channel or consistently show the same wrong audio/video
stream.  My guess is this has nothing to do with the card but rather
is a problem with the scanner putting the right values into the
channels.conf (wrong video/audio PIDs in the file).

> I'll be interested in what your contacts at pctv suggest.

I'm going back and forth with my PCTV contact.  He says the chip was
swapped out and there weren't any other changes to the PCB.  However
as you discovered, driver changes are required.  Should be pretty easy
to get working.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Chipset change for CX88_BOARD_PINNACLE_PCTV_HD_800i

[Mack Stanley]

On 06/22/2012 07:28 AM, Devin Heitmueller wrote:
> On Thu, Jun 21, 2012 at 6:43 PM, Mack Stanley <mcs1937@gmail.com> wrote:
>> mplayer [various options] dvb://6
>>
>> tunes to different channels different times, sometimes to video from one
>> channel and sound from another, sometimes to video but no sound.
> I would try tuning to the same channel multiple times and see if it
> behaves *consistently*.  In other words, does it always tune to the
> same "wrong" channel or consistently show the same wrong audio/video
> stream.  My guess is this has nothing to do with the card but rather
> is a problem with the scanner putting the right values into the
> channels.conf (wrong video/audio PIDs in the file).
>
>> I'll be interested in what your contacts at pctv suggest.
> I'm going back and forth with my PCTV contact.  He says the chip was
> swapped out and there weren't any other changes to the PCB.  However
> as you discovered, driver changes are required.  Should be pretty easy
> to get working.
>
> Devin
>
Hi Devin,

Your absolutely right about the tuning problem.  The VID's and AID's
were all wrong.  The card seems to have been choosing more at less at
random among the channels on the same frequency.  I copied the correct
VID's and AID's out of the DTA by hand and now everything is A-OK.

So, keeping all of the configuration settings exactly the same and
simply using s5h1411_attach instead of s5h1409_attach works perfectly. 
Maybe the easiest path is just to have the driver try one, if it fails,
try the other.

Thanks again, Mack

Re: Chipset change for CX88_BOARD_PINNACLE_PCTV_HD_800i

[Devin Heitmueller]

On Fri, Jun 22, 2012 at 11:55 AM, Mack Stanley <mcs1937@gmail.com> wrote:
> Your absolutely right about the tuning problem.  The VID's and AID's
> were all wrong.  The card seems to have been choosing more at less at
> random among the channels on the same frequency.  I copied the correct
> VID's and AID's out of the DTA by hand and now everything is A-OK.

That's not the card.  It's the scanning app that is screwed up.  The
card knows absolutely nothing about parsing PAT/PMT info and figuring
out which PIDs are tied to which streams.  If you've got another
capture card, you should see the exact same behavior.

> So, keeping all of the configuration settings exactly the same and
> simply using s5h1411_attach instead of s5h1409_attach works perfectly.
> Maybe the easiest path is just to have the driver try one, if it fails,
> try the other.

After discussion with my PCTV contact, I think that's probably the
correct approach (assuming the I2C addresses are different for the
1409 vs. the 1411).  Just do an attach against one, and if it fails
(returns NULL) then attempt to attach to the other.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Chipset change for CX88_BOARD_PINNACLE_PCTV_HD_800i

[Devin Heitmueller]

On Fri, Jun 22, 2012 at 11:55 AM, Mack Stanley <mcs1937@gmail.com> wrote:
> So, keeping all of the configuration settings exactly the same and
> simply using s5h1411_attach instead of s5h1409_attach works perfectly.
> Maybe the easiest path is just to have the driver try one, if it fails,
> try the other.

I actually don't have a sample of the new board, so if you wanted to
submit a patch upstream which does the following, that would be great:

1.  in cx88-dvb.c, do the dvb_attach() call against the s5h1409 just
as it was before
2.  If the dvb_attach() call returns NULL for the 1409, make the
attach call against the s5h1411.

Submit it to the linux-media mailing list to to solicit people willing
to test.  This is mostly to make sure that it doesn't break the 1409
based boards.  By doing the 1409 attach first, there is a high
likelihood that it won't cause a regression (if you did the 1411
attach first, there is greater risk that you will cause breakage for
the 1409 boards).

Be sure to include the "Signed-Off-By" line which is a requirement for
it to be accepted upstream.  I'll eyeball the patch and put a
"Reviewed-by" line on it.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Chipset change for CX88_BOARD_PINNACLE_PCTV_HD_800i

[Lucian]

Devin Heitmueller <dheitmueller <at> kernellabs.com> writes:

> 
> On Fri, Jun 22, 2012 at 11:55 AM, Mack Stanley <mcs1937 <at> gmail.com> wrote:
> > So, keeping all of the configuration settings exactly the same and
> > simply using s5h1411_attach instead of s5h1409_attach works perfectly.
> > Maybe the easiest path is just to have the driver try one, if it fails,
> > try the other.
> 
> I actually don't have a sample of the new board, so if you wanted to
> submit a patch upstream which does the following, that would be great:
> 
> 1.  in cx88-dvb.c, do the dvb_attach() call against the s5h1409 just
> as it was before
> 2.  If the dvb_attach() call returns NULL for the 1409, make the
> attach call against the s5h1411.
> 
> Submit it to the linux-media mailing list to to solicit people willing
> to test.  This is mostly to make sure that it doesn't break the 1409
> based boards.  By doing the 1409 attach first, there is a high
> likelihood that it won't cause a regression (if you did the 1411
> attach first, there is greater risk that you will cause breakage for
> the 1409 boards).
> 
> Be sure to include the "Signed-Off-By" line which is a requirement for
> it to be accepted upstream.  I'll eyeball the patch and put a
> "Reviewed-by" line on it.
> 
> Devin
> 

Hi,

Was there any progress on including the support for PCTV 800i S5H1411 based?

I have two such boards, both using S5H1411 and up until recently I was patching
the driver as instructed here:
http://forums.fedoraforum.org/showpost.php?s=3e6dd6214edd1145b5df6336d10ff941&p=1586999&postcount=9
A week ago, openSUSE 12.2 updated the kernel to 3.4.28-2.20 and now building the
v4l drivers from git results in kernel panic.(I had to restore the system from
an image backup).

Even before, there was always a problem with building from source; when doing
that the kernel reports /lib/modules/3.x.x-desktop is inconsistent and this
prevents other drivers from installing (i.e. nvidia). 
This happens on a few different systems when using the instructions from here:
http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers

Any suggestion appreciated.

Thank you,
Lucian