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