[linux-dvb] Re: Twinhan CA

[Ralph Metzler <rjkm@metzlerbros.de>]

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.

 
 > > 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.
Some people had interest to decode several services at the same time
though. But you also need special CAMs which support this.


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


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

 
 > >  > 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.
Any newer ones on the list?


 > 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

Are these cards already available? It would be good if we would have
somebody with ATSC reception ability to work on this.


Ralph