Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: CA



On Thu December 2 2004 1:52 pm, Ralph Metzler wrote:
> Manu Abraham writes:
>  > Hi,
>  > 		In ca.h, the structure
>  >
>  > struct ca_msg {
>  > 	unsigned int index;
>  > 	unsigned int type;
>  > 	unsigned int length;
>  > 	unsigned char msg[256];
>  > };
>  >
>  >
>  > Here what is the data that the user level application exchanges to the
>  > CAM in index and type ?
>
> "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 ?

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 ?


Manu
>
> Ralph




Home | Main Index | Thread Index