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 
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 
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 
define a
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 
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 
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 
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.


vdr mailing list

Reply via email to