[linux-dvb] [PATCH] Multi protocol support (stage #1)

Manu Abraham abraham.manu at gmail.com
Tue Jun 13 18:05:37 CEST 2006

Alan Nisota wrote:
> On 6/12/06, Johannes Stezenbach wrote:
>> On Sun, Jun 11, 2006, Alan Nisota wrote:
>>> Well, as it didn't seem that S2 was going anywhere, I had lost track
>>> of this conversation a month or so ago, but now that I had to do some
>>> mythtv work, I am trying to catch up.  I've looked over Manu's patch,
>>> and associated sample app, and I don't think I really understand how
>>> this method is supposed to work.
> While I was looking at the ver7 patch when I wrote that mail, I have
> since looked at the rev7a version as well, and I dhave questions.  I
> understand how to use the new API, but am unsure what is expected from
> an application perspective.
> Specifically, if the API is version 3.2, does that mean that all cards
> can be accessed with the new DVBFE ioctls (which would make things
> relatively nice, as an app needs to support only one or the other as
> defined at compile-time), or does each driver need to be ported to use
> the new API, in which case there needs to be some way to designate
> which cards support the new drivers?

There are a couple of cases due to backwards compatibility etc.

(1) make the API respond only to the new ioctl's

The problem with this is that there are apps out there, that which need 
some period of time to change over, asking them to switchover to new 
IOCTL's would be rather very rude.

(2) leave the old ioctl's and callbacks as it is

In this case all existing apps that are working now will work exactly 
the same way as it used to do earlier, the reason being nothing changed 
as regards to the old convention.

With regards to the new IOCTL's and calls there are now 2 different ways.

(a) Port all existing drivers to the new scheme

This is not something that is very easy and cause drivers to break down. 
We need some time to port the drivers
moreover some of the existing drivers can get a facelift as well while 
we are at it. So it is not a fast transition.

(b) We add in the new callbacks as regards to the new drivers. The old 
drivers can follow at a slower pace. this has the advantage that all the 
features will be available for the new devices, but the older ones have 
just the same old features only.

IMHO, 2 (b) is something that can go ahead without breaking all 
drivers/apps. The disadvantage of this scheme is that in any way, if 
applications have to migrate to the newer calls, the drivers have to be 
completed too.. but looking at another angle, the application guys get 
another advantage from this that, they can implement this interface once 
when one or two drivers are ready since they need to test it as well. 
The advantage here is that the applications also do get sufficient time 
to settle down. ie, it can go in a stable manner without any breakages, 
hopefully. ie applications that have completed the transition as well as 
the drivers that are written to the case of the updated API will 
function, while the old ones can still work as was running earlier itself.

> On 6/12/06, Manu Abraham  wrote:
>> Johannes Stezenbach wrote:
>> > My understanding is that dish network and thus the genpix
>> > card have nothing to do with DVB-S2, but are just a
>> > proprietary extension which adds 8PSK modulation to DVB-S.
>> >
>> >
>> Yes, you are right i think.
>> As i heard most Dish network people have this device. All it depends is
>> on 8PSK modulation, looking at the the Broadcom specs
>> (http://www.broadcom.com/collateral/pb/4500-PB06-R.pdf) It doesn't say
>> anywhere that it is a DVB-S2 supported device, in fact, but just says
>> that it supports DVB/DIRECTV/Digicipher II and that it supports
>> BPSK/QPSK/8PSK/16QAM modulations. The many parts of the DVB-S2
>> demodulator seem to be missing out in that Block Diagram, for example
>> the PL descrambling etc which DVB-S2 makes use of.
> All this is correct (I don't think we ever got the DSS stuff working
> with the board yet, though when we do, it'll make things much more
> interesting).  However, the need for modulation means that the board
> cannot be treated as a DVB-S board, and so I plan to implement it as a
> (mostly incapable) DVB-S2 board so that we don't need customized
> software to support it.  So my desire is simply that an API is defined
> such that I have something to implement against.

The most important aspect that went into the multiproto patch is that 
you can have multistandard devices. This will help you out in a much 
better way, since you don't have to do a work around.

If you do a workaround, then that will really cause more headaches for 
you, since DVB-S2 != 8PSK != DVB-S. I mean to say here that, DVB-S2 has 
more parameters, than just a change in modulation. You might be getting 
into a lot of headaches by assuming DVB-S2 == 8PSK modulation.

The easiest to do is that, you can combine modulations within one 
delivery system itself, ie you can bitwise OR the supported modulations 
as in that example snippet that i sent alongwith. This way it will have 
just the behaviour of DVB-S, but will give you 8PSK modulation on DVB-S 
as well. So you are very much safe in that aspect, and it exactly 
reflects the very same hardware nature, a DVB-S device with QPSK + 8PSK 
modulations. What i will do is, i will update the stb0899 tree such that 
you can see how it will look at the driver side to make it easier for you.


More information about the linux-dvb mailing list