[linux-dvb] [PATCH] Add missing S2 caps flag to S2API
morgan.torvolt at gmail.com
Tue Nov 25 19:34:23 CET 2008
> I find it a completely unacceptable thing to have the user tell
> the application what type of DVB devices the hardware provides.
> This is pretty much the first and simplest thing the *DRIVER* has
> to do. If a driver (API) doesn't allow this in a clean way, it's
I think you are overreacting here. Worthless is a strong word. Yes, it
imo also a major flaw, but it does not make the driver worthless, just
more cumbersome to use. In all honesty, having this as a user setting,
it would only need to be set once, which hardly qualify as hard work.
Try being a bit more friendly. Calling something worthless because of
a relatively small feature-lack is not.
> I don't care if this is a specific or a general flag, as long as
> it allows the application to clearly find out the kind of hardware
> that's available. It leaves me dumbfounded that this is suddenly
> such a big problem...
This has not suddenly become a big problem. The problem has been there
the whole time, it's just you and others making this into a big
problem. Really it is not. Of course everyone this fixed. Having a
good discussion about it is the best way of achieving that.
> You are not alone in that boat my friend. Especially after reading
> the comments about how "thought out" the api is. How could you
> possibly miss such a fundamental element?!
Stuff gets left out sometimes. I bet you forgot something sometime as
well. This is done by humans.
>> Or is the S2API already "dead", and it's sole purpose was to
>> prevent "multiproto" to make its way into the kernel? And now that
>> this has been achieved, nodody really cares whether it can be used
>> in real life?
> Hey, stranger things have happened. Not much surprised me these days.
> Hopefully somebody will get this sorted out and fixed very soon as it
> shouldn't even be an issue at this point!!
This is just ridiculous and has no place on this mailing list. I hope
that if you think about it, you will agree.
> From my personal POV. I think S2API isn't missing something concerning
If someone is missing a feature that obviously should be supported,
then something is missing. If you do not need that feature I guess
that is good for you :-)
Regarding the actual problem, I have never been happy with the
"FE_QPSK" and "FE_OFDM" enum fe_types. This imho does not make much
sense. I would like to know what a card is supposed to receive. One
modulation type is not locked to a transmission medium, nor frequency
range, and QPSK can easily be used in a cable network if one wished to
do so. I second the proposed solution of Artem, but I would do it with
If possible, I would keep the old system for backwards compatibility,
and create a different command where this confusing QPSK/OFDM/QAM gets
removed altogether. I would have a enum frontend type that would
indicate what standard is being followed, if any. An additional
indication of all the different modulation types that is supported is
a must. In addition to what Artem proposed, I would like to be able to
read a supported frequency range ( i.e 950-2150 for satellite tuners
), and supported symbol rates. The last part there about symbol rate
could be different for different modulation types. Most people would
not need this, but some do. I don't think I have a good solution for
how one would solve that, but one way would be if you could do as with
the ca_types supported that is returned from different CAMs. One could
return a list of stucts with modulation types and their respective
limits and parameters. I don't know if this is really useful, but I
remember that on some of the satellite modems we used, the symbol rate
was limited by the center frequency of the carrier. If you got to
close to the max and min, the carrier bandwidth would have to be
reduced. There might be some equipment out there that has such
limitations, and it could be worth adding support for that I guess.
More information about the linux-dvb