Klaus Schmidinger wrote: > On 01/28/08 03:01, Manu Abraham wrote: >> Klaus Schmidinger wrote: >>> On 01/27/08 17:46, Thomas Schmidt wrote: >>>> I really hope that either vdr 1.5.x gets a compile-time-switch to >>>> build and run with the vanilla kernel-sources or even better that the >>>> multiproto-drivers will be merged into the mainline kernel soon. >>> The latter would be the reasonable step to take, IMHO. >>> Having these different DVB driver branches is something that >>> should end as soon as possible. >> The drivers can be merged in to the kernel after quite some tests. >> >> With regards to both the S2 capable drivers there are enough bug >> reports open. I am not of the opinion of merging drivers while open >> bug reports still do exist. (You can look at the linux-dvb ML for the >> same) For both the drivers, many people can say it works for me, but >> not for everyone. >> >> That said, currently the tree is up to v4l-dvb head and the current >> kernel merge window is open for 2.6.25, which will be open for some >> few days more. With the current state, it cannot be merged in for >> 2.6.25. >> >> Most probably we might be able to make it for 2.6.26 if all goes well. >> This requires lot more testing and fixing etc. >> >> The current state of different branches (distributed repositories) was >> the option chosen when Johannes merged the trees and was his >> decision. Most probably, that will remain the same for quite a long time >> to come. > > Just so I understand this correctly: the driver that is currently in > the kernel is *not* able to do DVB-S2, while the driver at > http://jusst.de/hg/multiproto *is* able to do it. And these are the only > two driver versions we're talking about here, right? Umm.. Let me put it this way. Currently in kernel, everything is defined in terms of modulation. This won't hold good with newer stuff coming up. Newer stuff (devices) can have a single modulation type or multiple modulation types (when looking at a single device itself) For example: In kernel as of now, DVB-S is represented by QPSK (This is in fact slightly wrong. DVB-S can use QPSK or BPSK) Next: for DVB-S2 there is no representation as it is for it in kernel (atm), since DVB-S2 can be 32APSK, 16APSK, 8PSK or QPSK Also there is another satellite delivery system called DSS which can use BPSK and or QPSK Another very important aspect is that you can't define DVB-S2 as 8PSK modulation, since there is yet another broadcast system (In the US) which uses DVB-S framing and 8PSK modulation. The important part is that, as you see this has no DVB-S2 framing, but also that instead of the BCH/LDPC for FEC, it uses Turbo Codes. So, as you see in the 3 cases, having a FE_HAS_QPSK is not enough to define a delivery system, whereas you a need a tag for a collective set of modulations, similar to DVB-T (OFDM) where you have different modulations again. So eventually: as you see, you can't access a delivery system by a modulation type. As of now, there are 2 Linux DVB drivers which are DVB-S2 capable * STB0899 (Supports: BPSK, QPSK, 8PSK, 16APSK, 32APSK) * CX24116 (Supports: BPSK, QPSK, 8PSK) (You might remember the old modulation discussions we had a long time back) Two more newer DVB-S2 devices that are expected to be supported under Linux are the STV0900 and the STV0903. Currently, the multiproto tree has the delivery system definitions, such as DVB-S, DVB-S2, .. .. The drivers which make use of these delivery systems, makes use of the API changes held in there. > So, if the kernel driver can't do DVB-S2, it will probably become obsolete > pretty soon, at least for those who want to receive DVB-S2 channels. True. Not only for DVB-S2, There are other stuff coming out, which will need the multiproto API changes, such as for the newer parameters, which are required for DVB-H. Also additionally we have reserved space for more newer delivery systems such as DVB-C2, DVB-T2 (which will be coming out in a few years) also the existing DMB-T/H delivery system can be added in as well, with much ease, without having the old issues that were visited during the API discussion period. Other than this, there are some quirks with the current in kernel API such as with regards to DVB-T, that you can't select a Low priority stream. Also for DVB-H, you will need additional parameters. So eventually, it is high time that the in kernel API needs a face lift. > Maybe making VDR require the "multiproto" driver actually gives this > driver the necessary boost to be sufficiently tested so that it can > be merged into the kernel in the not so far future... ;-) :) Definitely: Lot of testing is required and user complaints to get things moving in the right direction. Regards, Manu _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
