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.
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
