[EMAIL PROTECTED] wrote: > > One CI device per slot would be fine for our requirements. I guess if you > had 2 slots and only one physical CI device you could always create another > logical CI device to handle the extra slot. Was this your thinking as > well?
You're confusing me. What extra slot? I talked about either having two independent slots or two slots which can operate on the sae TS only. > Having a fixed routing from front-end to C/I device through to the CAM and > back through to the demux is not a problem as long as there is an ioctl to > set the TS source of the C/I device. The demux can then choose the source > from either a normal front-end(s) or the output from the CAM using the > DVB_DMX_SET_SOURCE ioctl. Is this OK, can we add this ioctl to ci.h? I think so. > BTW, I guess it's no use to have an API between a smart-card and a host as > this will be confidential info. Right? The T=0 and T=1 protocols (and others) for smartcards are described in public documentation, so I don't think there's anything confidential here. IMHO the reason for not having a standard Linux SC reader *driver* API yet is that in the PC world these things hang on a serial or USB interface, and the protocols are then implemented in userspace. See e.g. PC/SC http://www.linuxnet.com/ or SCEZ. We currently use a simple character device exactly what we need without much overhead due to abstraction/generalization. Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
