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
>> 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
good with newer stuff coming up. Newer stuff (devices) can have a single
type or multiple modulation types (when looking at a single device itself)
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
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
since there is yet another broadcast system (In the US) which uses DVB-S
and 8PSK modulation. The important part is that, as you see this has no
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
delivery system, whereas you a need a tag for a collective set of
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
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
the STV0900 and the STV0903.
Currently, the multiproto tree has the delivery system definitions, such
DVB-S2, .. ..
The drivers which make use of these delivery systems, makes use of the
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
multiproto API changes, such as for the newer parameters, which are
DVB-H. Also additionally we have reserved space for more newer delivery
such as DVB-C2, DVB-T2 (which will be coming out in a few years) also
DMB-T/H delivery system can be added in as well, with much ease, without
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
in the right direction.
vdr mailing list