[PATCH] Re: [linux-dvb] [PATCH] Multi protocol support (stage #1)
js at linuxtv.org
Mon May 22 15:21:34 CEST 2006
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.
(So it's actually not just a new modulation but also
the new roll-off factor.)
Current use of DVB-S2 to my knowledge is Premiere HD on Astra 19.2E.
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...
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)
- 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)
- maye other stuff like ARIB / ISDB-T
> I wouldn't even mind if the old and new driver weren't binary
> compatible. I'd just write into the release notes of VDR that
> as of version soandso VDR requires driver version XXX.
I predict you'd get a load of "my vdr doesn't work with my kernel"
type of bug reports. Maybe for VDR breaking compatibility is
not such a huge problem, but for something with many build
dependencies like mplayer or xine it would be unacceptable.
One mplayer or xine binary must work on any kernel.
More information about the linux-dvb