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. Johannes _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
