[vdr] [ANNOUNCE] VDR developer version 1.5.14

Manu Abraham abraham.manu at gmail.com
Mon Jan 28 19:44:35 CET 2008


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



More information about the vdr mailing list