On Tuesday 11 April 2006 10:33, Johannes Stezenbach wrote: > On Mon, Apr 10, 2006, Andrew de Quincey wrote: > > Currently there is a slightly weird behaviour with DVB CA devices. Say > > you have an adapter with three CI slots. You would expect to see: > > > > /dev/adapter0/ca0 > > /dev/adapter0/ca1 > > /dev/adapter0/ca2 > > > > However, what you actually see is > > /dev/adapter0/ca0 > > > > Then each message sent to and from that ca0 (using read()/write()) has a > > two byte header prepended: > > byte0: slot_id > > byte1: transport_connection_id. > > > > Where slot_id will vary from 0->2. This complicates writing CA related > > things.. Its not possible to just check a specific slot for data. And > > when you start to support multiple adapters each with multiple slots, you > > have to have a sort of virtual device layer. It also complicates the > > kernel dvb_ca_en50221.c generic link level CA device driver. > > Can you explain what the problem actually is? > > > I would like to change this so that: > > 1) We create a caX device per slot on the adapters. > > 2) We'll keep the two byte header for back compatability (the > > transport_connection_id is useful still). However, the slot_id will > > always be set to 0. > > I vaguely remember the discussions when designing the V4 ci.h API, > maybe you can find it in the archives somewhere. > > Basically this slot thing models the hardware, which is just one > CI controller, el cheapo extended to support two slots. In the end, I realised we can't break the existing model since that would break apps. I looked in the VDR source for example, and it only supports a single ca0 device just now. However, as Manu says, that doesn't stop us extending it to multiple caX devices in the future if we find we need to do routing etc. Apps would have to change then, but at least we wouldn't be breaking existing functionality. _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
