[EMAIL PROTECTED] wrote: > > > > What about leaving the demux device alone and allowing it to choose say > > > front_end x = C/A module input. Then we > > > need a C/A device that can set it's source to say external demod #1. In > > > this case, h/w that does have the ability to route an input TS from say an > > > external demod to a C/A module and then into the logical demux device is > > > covered. Also, h/w that does not have a C/A or C/I router will still > > > function the same i.e. demux selects the required front_end. > > > That would be one possible way. > > Btw., I have a question regarding the new CI devices and how to differentiate > > several CI adapters (not that I know receivers with more than one). > > If you have one CI device for each slot, you might want to call > > them ci0_0, ci0_1, ci1_1 etc. where the first number is the CI adapter > > unit and the second the slot. Your source setting calls to ciN_0 would > > be valid for all ciN_X and so on. > > I have no problems with the adapter/slot method. Any more > comments/suggestions folks?
The one device per slot thing is IMHO nicer to use, provided that you have a static assignment between frontend, CI and demux. If you can dynamically configure your stream routing there's a difference between 1 CI controller with 2 slots and 2 CI controllers with 1 slot each, because in the first case both slots can only decode the same stream. Tell me if you think it is necessary to reintroduce the slot-number into ci.h and map a two-slot CI controller to a single device with two slots. I don't care much, I just thought the current ci.h is simpler than the old ca.h, and thus better ;-) Regards, Johannes -- "Make everything as simple as possible, but not simpler." Albert Einstein -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
