Manu Abraham wrote: > Klaus Schmidinger wrote: >> On 01/28/08 02:49, Manu Abraham wrote: >>> Ludwig Nussel wrote: >>>> Klaus Schmidinger wrote: >>>>> On 01/27/08 16:25, Ludwig Nussel wrote: >>>>>> Klaus Schmidinger wrote: >>>>>>> - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and >>>>>>> Reinhald Nissl >>>>>>> for a patch that was used to implement this). VDR now requires >>>>>>> the "multiproto" >>>>>>> DVB driver, e.g. from http://jusst.de/hg/multiproto. >>>>>> Would it be possible to make that optional via compile time define? >>>>> I guess so, but I'm not going to ;-) >>>>> This new driver appears to be stable enough now - at least I've >>>>> been using it for a few days now without problems. >>>> *sigh* messing with kernel stuff sucks. Does a vdr built with the >>>> multiproto headers at least also work on vanilla kernels ie stable >>>> dvb drivers? That way one would only need to use different headers >>>> for building vdr but no extra kernel modules at run time. >>>> >>> AFAICT, the updated headers can be used along with the old drivers >>> without >>> any issues. If not there's an issue with regards to backward >>> compatibility. >>> Can you pleas point out the errors that which you see, when you are >>> using >>> the updated headers and the old drivers ? >> >> The new headers work fine with the old driver - if the application >> still uses the old API. I've tested that first thing before I switched >> to the new API. >> >> However, I don't see how an application actually using the new API >> could work with the old driver. > > In the idea that i had, it would look for the API version and issue the > ioctls > as necessary, similar to what i used in the szap hack. (It was just a > hack, for > some testing as well as demonstrating the API usage) > The hacked szap is here: http://abraham.manu.googlepages.com/szap.c Forgot one thing to mention, The application issues the new ioctls, the dvb-core takes those parameters and converts it into the old format and passes it to the old driver. This way, a driver written the old way will also work, just that it involves a thin layer of translation, also misses some of the newer features introduced. Another major change in the old -> new driver concept is that, the old drivers were all forced to do a stupid software zigzag, even for hardware that doesn't require it. With the new interface, you can define your custom algorithm in the driver itself, such that it performs really well, just similar to properly written drivers, rather than reverse engineered device drivers. If you think that your driver needs to be lean and mean, then the new interface is the way to go. In any case, to make the utmost use of all the features, still you need to know a lot about your hardware, to do that. In fact the more ideas you have, you can implement, unlike the case with the old interface, that even if you know what to do, there was no way to do it, without stripping away quite a lot of fat which will cause another flaming thread for some few years. Regards, Manu _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
