From: Ralph Metzler <rjkm@xxxxxxxxxxxxxx> > Andreas Oberritter writes: > > > Unless you want to move the writing to/reading from the CI module into > > > ioctls of the ci device you need another node. > > > Even nicer would be having the control messages moved to ioctls and the > > > TS IO in read/write of ci, but this would break the old interface. > > > > It's possible to keep compatibility. Just add ioctls to get and set the > > interface version. Default to the current version, not supporting TS > > I/O. If the version is set to e.g. 1, switch from the current interface > > to the new one, using ioctls for control messages. > > A possibility, but also requires rewrites in existing software like libdvben50221. > Right now you can e.g. tune with /dev/dvb/adapter0/frontend0, point an unchanged > libdvben50221 to /dev/dvb/adapter1/ci0 (separate adapter since it can even > be on a different card) and pipe all PIDs of cam_pmt of the program > you are watching through /dev/dvb/adapter1/sec0(cam0) and it is decoded. This is KISS compliant by the way. Andreas, please explain what *really* bothers you with this architecture choice of having a new node, leaving the current API as is. You might find that adding a new node is lazy, but there are advantages: - current API isn't broken, namely, ca devices are still used for the control messages, nothing more; - for applications using the DVB API, it is also easier to debug while reading the code, in my opinion, because of the usage of two distinct devices (ca / cam) instead of one (ca / ioctls); -- Issa -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
