[PATCH] Re: [linux-dvb] [PATCH] Multi protocol support (stage #1)
abraham.manu at gmail.com
Mon May 22 16:05:25 CEST 2006
Johannes Stezenbach wrote:
> On Mon, May 22, 2006, Klaus Schmidinger wrote:
>> Johannes Stezenbach wrote:
>>> I also say it again: I am deeply dissatisfied that none
>>> of the people you mentioned at the bottom of
>>> seem to care enough to participate in the discussion.
>>> (Not to mention that app developers also don't
>>> seem to care -- after all these are the ones who'll have
>>> to deal with the new API.)
>>> Maybe we should just put the API change off for now. :-(
>> Well, as an application developer (VDR) I'd like to be able to
>> support DVB-S2, but I guess my knowledge about all this is too
>> limited to understand what this heated debate is all about.
>> I always thought that DVB-S2 is just "DVB-S with a new modulation",
> IMHO the current use of DVB-S2 is just that, i.e. basically
> the difference between the satellite_delivery_descriptor
> as defined in EN 300 468 version 1.5.1 vs. 1.7.1.
But you seem to go against EN 300 468 as well. Looking at EN 300 468
Thare are others as well.
> (So it's actually not just a new modulation but also
> the new roll-off factor.)
Argh ! Rolloff is queried back from the Physical layer
> Current use of DVB-S2 to my knowledge is Premiere HD on Astra 19.2E.
Eutelsat W3A (7.0E) - 10880.00 V - DVB-S2 - 17360 3/4 - Txp: A10
<http://en.kingofsat.net/tp.php?tp=1296> - Beam: Europe B
> If someone know other *current* uses of DVB-S2 please speak up.
>> so I would expect a new driver version that supports DVB-S2 to
>> just implement that new modulation and still call it "DVB-S".
>> This "...2" thing is IMHO just to make things clear to customers,
>> so they know that their old boxes can't handle it. From an application's
>> point of view it's still DVB-S, just with another modulation.
> For the immediate needs of DVB-S2 it might be sufficient to
> just treat it as DVB-S, i.e. you tune to the right frequency
> with the right symbol rate and the demod hw will do the
> rest automatically (since the other parameters are part
> of physical layer or baseband signalling). But I could be
> wrong in my interpretation of the standard here...
Well, if i were to say that if i were to be wrong at any point on some
argument, i wouldn't go about NACK'ing it altogether.
There can be many things that can run with , "i think" "it might" etc.
But that is not a solution.
> It would also be possible to just add "modulation" and "rolloff"
> fields to struct dvb_qpsk_parameters, and use bit 31 of
> the symbol rate to indicate their validity (for backwards
> binary compatibility). (Ugly, but little hassle.)
> However, the goal is also to:
> - support dual-mode frontends (e.g. DVB-T/DVB-C combos)
What about Tri mode and Quad mode devices ? DVB-T/Dvb-C is not the
> - support DVB-H (it seems there is no way to squeeze all
> DVB-H parameters into struct dvb_frontend_parameters,
> but I know next to nothing about DVB-H so I could be wrong)
> - be extensible for:
> - maybe support advanced DVB-S2 use (DSNG etc.) once we
> figured out how it works in practise
> - be able to query DVB-S2 (and others) modulation parameters
> etc. from the demod (e.g. also DVB-T/DVB-H cell ids)
Well i tried for it. Well many tried, you seemed to NACK all of them
down, but you say on one hand that you don't know much about DVB-S2 , on
the other hand you NACK any changes.
> - maye other stuff like ARIB / ISDB-T
Well we should implement the useful ones first rather than implementing
the ones that aren't used at all
More information about the linux-dvb