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