[linux-dvb] Re: Linux DVB API 4 Q's

[Johannes Stezenbach <js@convergence.de>]

Rob.McConnell@Zarlink.Com 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 ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.