On Sat, 19 Nov 2011 00:40:30 +0200 Mika Laitio <lamikr@xxxxxxxxxx> wrote: > > I've received an email from Manu Abraham, informing > > me that he intends to change the driver in such a way that there > > will always > > be only *one* frontend, even if it can handle multiple delivery > > systems. So every frontend an adapter will provide will always be > > useable independent > > of all other frontends of that adapter. > > Personally, I like this method more than having separate frontends > > for each delivery system, and having to manage access between them. > > > > Just wanted to let you know that the official implementation in VDR > > (most likely after version 2.0) will go a different way than your > > patch. > > I am wondering what's the reason of breaking this current rule as it > sounded so clear...So if cards all delivery systems are mapped as an > adapters under same frontend, there must be a some method for querying > which of those adapters are tied together. Did Manu say whether that > info can be get via dev tree, via sysfs or by using some new ioctl? If Manu is successful in what he is trying (and existing driver following other rules will be ported) then that sounds fine to me. I dont care what solution , but i care for having one. > And if the patch wont go in, it means that hvr-4000 owners needs to > maintain in addition of the vdr-patch, also a patches for all plugins > that the patch breaks :-(. On the other hand, if the patch would be > accepted to vdr before 2.0, I am sure that all plugi-ns would be > adapter to work in couple of weeks to work with the new interfaces. Its not a drama if on the other hand above happens. If above happens than vdr needs only to adapt to shared ca devices (which are implemented as i.e. caio0 & ca0 and need some special handling from vdr side. _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
