[linux-dvb] Re: CA

[Ralph Metzler <rjkm@metzlerbros.de>]

Manu Abraham writes:
 > > "index" is the slot index in case of CI interfaces with several CI slots.
 > > I think "type" is not really used right now and could be used for
 > > those 2 bytes you mentioned in the other mail.
 > >
 > 
 > 
 > Wow, partial solution for the problem.... In that case i can use type for the 
 > type of CI function, rather than have multiple vendor specific IOCTL's that 
 > upset Johannes.
 > 
 > After some thinking, i think it should be possible with just one byte also...
 > 
 > Another question is that would it be advisable to show device internals to be 
 > seen in userspace ? Those 2 bytes would be the ASIC commands something in the 
 > lines of
 > 
 > get copyright
 > get cam state
 > get cam application info
 > set ca pmt
 > get slot info
 > enter slot menu
 > slot get mmi
 > slot answer
 > slot menu answer
 > slot close mmi
 > reset mcu
 > 
 > These ASIC functions could be hidden in those 2 bytes... But i'am thinking, 
 > what about applications using them ? What i mean is that if i have it like 
 > that the user application also would have to know the the commands, which 
 > would mean, would only be supported by new apps ?

We would need a library which either uses a stack based on link layer
protocol (like the one from VDR) or directly uses the application
level commands, depending on what kind of CAM it detected.
 
 > Or what i'am thinking is that would it be possible to reverse engineer, the 
 > existing CAM communication protocol, inside the Twinhan driver, provide a 
 > wrapper to those commands ? in this case, i would need the exact syntax of 
 > what the current CA driver gets/passes on using the struct ca_msg.. Would 
 > that be feasible ?


I am not exactly sure what you mean. 
As I see it, almost all of the ASIC functions are standard EN50221 
application commands. E.g. "get cam application info", which is the
ASIC command "07 40 00 00 01 00 00" + checksum byte is probably 
just translated into "9f 80 20" + length field and sent to the CAM.
The same is done for the other commands.

So, to conform to the standards, it would make sense to use those 
standard tags either as header for the message or in the type field.
The driver just needs to look at this tag and either translates it into 
card specific commands or returns ENOTSUPP.

Since on this level there really is no way for the application to 
know what session numbers are being used it would also be the
responsibility of the driver to use the correct one for each command.
If the CI interface is on a lower level the application of course has
to take care of this.


Ralph