[linux-dvb] Re: Twinhan CA

[Manu Abraham <manu@kromtek.com>]

On Thu December 2 2004 7:18 pm, Ralph Metzler wrote:
> Manu Abraham writes:
>  > On Thu December 2 2004 4:47 pm, Ralph Metzler wrote:
>  > > Manu Abraham writes:
>  > >  > In the Twinhan implementation,  the session number is hard-coded to
>  > >  > 3, as per my correspondence with them,
>  > >  > ca_pmt_list_management == 3 ie, the _only_ CA PMT object as per
>  > >  > EN50221, which is true for the hardware, since they told me that
>  > >  > there is currently a hardware limitation of a single CA PMT object
>  > >  > on the current CI boards, which would be changed in the MCU and or
>  > >  > firmware very soon itself.
>  > >  >
>  > >  > And therefore change in session numbers is immaterial.
>  > >
>  > > OK, good, we can forget about session numbers then.
>  >
>  > Not all together, The new card is going to get it back...
>  > One thing i would like to know is why a session number ? Even if you
>  > send multiple CA PMT objects, generally why would one require multiple
>  > sessions ? One thing that i did never understood going through the
>  > documents.
>
> For normal usage 1 should be enough.
>
>  > > Of course the CA_PMT message starts with the same byte anyway,
>  > > why is it repeated in the header?
>  >
>  > It is a map that i plan to put it in the header.. That might not be
>  > required at all ? But what about CAM reset and other things like that ?
>  >
>  > The ASIC requires more magic, not just EN50221. That can be done in the
>  > driver. Some more things are appended to the message before sending to
>  > the ASIC. The message position is shifted to the right by n, where n is
>  > the number of magic words. Before sending in the EN50221 structure to
>  > the cam, it is wrapped around with additional ASIC magic words.
>  >
>  > Would you like me to work it out and post it ? It might take a little
>  > bit time... I've been working too long on this one..
>
> I thought it is just:
>
> length 0x40 session_low session_hi command_type length_message message[]
>
> plus the usual checksum byte at the end of course.
>
> As you already explained, session might sometimes mean something else,
> e.g. the list management mode.
> That's basically what I have been told and what everybody can see from
> the public sources. Or is there anything else?
>
> Almost all commands have a corresponding En50221 message. Reset is
> already available as extra ioctl.
>
Fine...

>  > > This explains why nothing changed when I only changed it in the
>  > > message ...
>  >
>  > I have a working model, with just one ioctl set_pmt. I thought i will
>  > clean up and post, i didn't want people to comment about my code, after
>  > all that coding philosophies... going around.
>
> Yes, one PMT should be enough in most cases.
At least with current hardware that i have.

> Some people had interest to decode several services at the same time
> though. But you also need special CAMs which support this.
Right, moreover card hardware also does not support..

>
>  > An application that i created does change stuff, works okay, but it is
>  > crude since you have to pass the PMT to it. Just enough to test the
>  > driver.
>
> I finished an szap hack which works if you have the correct PNR in the
> channel config.
>
>  > >  > > Either we add this as an exra hint to the type field or we leave
>  > >  > > it to the driver to use the correct session number for each
>  > >  > > command?
>  > >  >
>  > >  > The type field really attracted me to the fact that it would be
>  > >  > easier to have new features in the driver, as and when the
>  > >  > manufacturer makes changes to their ASIC/firmware, without having
>  > >  > the need for any new IOCTL's at all.
>  > >
>  > > Yes, we can basically use all application level messages without
>  > > needing special ioctls. The driver just needs to tell us if it
>  > > thinks the card can or cannot handle it.
>  >
>  > Just return an error message if not ? (ioctl error ?)
>
> Yes.
Done.

>
>  > >  > What i would think is that, if we follow the same steps of having
>  > >  > individual IOCTL's the driver in the end after a period, would be
>  > >  > nothing more than a collection of messy IOCTL code.
>  > >  >
>  > >  > Shouldn't we also consider how application authors would like this
>  > >  > to proceed ?
>  > >
>  > > For them there should be a library which handles all the different
>  > > cards transparently. We'll have to come up with an API.
>  >
>  > Is there any move as it is for such a library ?
>
> One could start with our cam_set stuff which builds on top of the VDR CI
> stack. Maybe rewrite that in C and go on from there.
Too bad with cpp. :-( .I have not used the CAM much... haven't tried VDR 
either...

>
>  > >  > Another question that i would like to ask is this,
>  > >  >
>  > >  > What about obsolete cards, as classified by the manufacturer ?
>  > >  > Obsolete by the terms they mean is cards with hardware bugs ??
>  > >
>  > > Good question.
>  > > Things like not supporting CA_PMT lists are of course harder to
>  > > intercept because the message will have to be at least partially
>  > > parsed to decide if one card can handle it or not. In this case it is
>  > > just one byte in the CA_PMT message to check but in other cases it
>  > > might be more complicated. Let's hope it will not get too messy ...
>  >
>  > Not just CA cards, The manufacturer sent me a mail today that some of
>  > the FTA cards are also obsolete. They gave me a new list..
>
> I think they no longer supported the old cards without EEPROM (und thus
> without subsystem/vendor ids) under Windows for some time now.
couple of them even with EEPROM's..

> Any newer ones on the list?
Waiting to hear from them..

>
>  > Another question that is off the topic is the ATSC cards are also on the
>  > same line, is it that we just detect the card and put out a message that
>  > it is an ATSC card ?
>
> Sure, I think the ATSC frontend type also is defined already and the
> rest of the DVB stack should work without changes with ATSC
>
Ok, in that case i will add ATSC card detection also to the list..

> Are these cards already available? It would be good if we would have
> somebody with ATSC reception ability to work on this.
Yes. I will get some info down..

Manu
>
>
> Ralph