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

Johannes Stezenbach js at linuxtv.org
Fri May 12 22:16:17 CEST 2006

On Fri, May 12, 2006, Manu Abraham wrote:
> Johannes Stezenbach wrote:
> >  
> >- removed useless _RESERVEDs from the enums
> but it is now _RESERVED changed to _UNKNOWN. Just a name change. It is 
> not removed.

No, I renamed _NONE to _UNKNOWN. For FE_SET_PARAMS one would
use _AUTO, _UNKNOWN should be an error. But FE_GET_PARAMS
may return _UNKNOWN if a parameter's value isn't known.

_RESERVEDs were removed.

> >- moved all legacy cruft at the bottom
> This will cause all drivers to be changed at the same time. will cause 
> broken drivers. We haven't completely recovered from the earlier 
> changes, still !


I just moved it to another position in the file, so that
if someone reads frontend.h they will know not to use it
for new apps.

But right, the "deprecated legacy types and ioctls, do not use in new
applications" comment is wrong because even new applicatons
should care about one-year-old kernels and must be prepared
to use both old and new calls.

> >- moved modcod to dvb_frontend.h -- I'm relatively convinced
> >  there's no use for this in the API
> >  (dvbs2_params takes mod + fec instead)
> TR 102 376 v 1.1.1 page 41 IP Unicast Services
> 6 Interactive applications

> Under the said opinions, i can think of 2 ways
> (Option #1)
> Move modcod to the dvb_frontend , since it is of no use in the API as 
> Johannes said. The bad sides of it are
> (a) we will need dvbs_modcod_encoder convenience function as well
> (b) apps still use a different strategy than what is specified in the specs
> (Option #2)
> Leave modcod as it is, and be happy. It is according to the standards 
> and no additional convenience functions are needed.
> I personally vote for Option #2.

ACM is not for broadcast use, but for two-way
communication, where the receiver can send commands back to
the transmitter to control the modulation.

The way I read the standard, the ACM return channel
could be a telephone line or DSL/internet to the playout center.
The demod hw would handle ACM receiption automatically, and an
application would monitor signal quality and send commands back
to the transmitter to change modulation and fec until it gets
max throughput at good quality.

Thus I believe even with ACM there is no need for modcod
in the API. Maybe decode_dvbs2_modcod() in dvb_frontend
isn't needed, either.

However, we should probably add a "__u16 matype" field so
we can query it with FE_GET_PARAMS for informational purposes.

> >- FE_GET_PARAMS semantics are still not clear:
> >  when calling it, the current delsys is unknow, thus
> >  it is not possible to set specific fields to *_IGNORE
> >  or != *_IGNORE; one could memset() the
> >  struct dvb_frontend_params to zero, then call FE_GET_PARAMS
> >  once to find out the current delsys, and then set the
> >  interesting fields to != *_IGNORE
> >  That's somehow ugly...
> Ok, i will try to add in some comments. I was under the belief that it 
> was pretty clear.

comments won't fix the broken semantics...

> >- I'm still unhappy witht he capabilites; IMHO it doesn't
> >  make sense to put full struct foo_params in there.
> >  E.g. a DVB-S frontend is usually 100% compliant (I don't know
> >  any which isn't), so why have capability flags for e.g. each
> >  FEC required by the DVB-S standard?
> Well, i did add it because of all those "if" conditions put forward. 
> IMHO it should be there, since it will at least pacify the people who 
> are saying otherwise.

I repeatedly asked how an application would use this info, and
got no replies :-(

IMHO any sane application will just not care if a particular
demod can do e.g. FEC_7_8. If FEC_7_8 is in the standard, and
the broadcaster uses it, but your demod hw can't do it, you
can't receive it. All the app could do with the capability
is to display a "sorry, your hw sucks" message.
However, the user will find out that his hw sucks anyway...

Is there *any* software which did this using the
existing fe_caps_t?

> We all spent too much time on this discussing this without any progress, 
> just discussing only the cosmetic stuff. I hope it can go ahead .. :-(

IMHO cosmetic stuff is important for an API.

Anyway, I was also trying to address semantic problems, IMHO
it *is* progress that the problems are being made visible
instead of just merging some half-baked API change.

> I hope incorporating the changes outlined here as you said and with the 
> issues that i meant it can go into v4l-dvb, being marked as EXPERIMENTAL ?

It should really live in it's own repo until it is implemented.

I.e. the new ioctls must be implemented to work for the
existing DVB-S/C/T frontends, so apps could start using them.
It doesn't make sense to merge an API header with no implementation.

I don't care if the DVB-S2 pieces are all correct, provided they
are marked as being EXPERIMENTAL. If someone wants to write a
DVB application and reads though frontend.h they should be made
aware that the DVB-S2 API is not proven stable yet.


PS: Given that there are a number of people reportedly working
on DVB-S2 stuff, I'm really surprised that not one of them is
willing to participate in this discussion and show some interest.
Quite disappointing :-(

More information about the linux-dvb mailing list