Johannes Stezenbach wrote:
On Mon, May 08, 2006, Manu Abraham wrote:
Updated Patch.
I hope it addresses a lot of small things here and there .. I will
attach the STB0899's interface to the API in another mail.
Hope i haven't missed out anything that was mentioned.
I worked my way though your patch and changed coding style
the way *I* like it; maybe it'll upset you, but I think
it is more Linuxy this way.
Well i am not too happy about the Linuxy way .. According to Linus, well
Linux is not supposed to follow any standards and or specifications, but
yet we are all looking at specifications and datasheets .. ;-)
Relevant changes:
- consistent dvb_ naming for all new enums; looks better and avoids
name clashes with the old types (e.g. fe_bandwidth vs. fe_bandwidths)
Ok
- removed useless _RESERVEDs from the enums
but it is now _RESERVED changed to _UNKNOWN. Just a name change. It is
not removed.
- make sure all new enums have a (1 << 31) value so they are
32bit sized even on strange ARM architecturs
Looks nice.
- 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 !
- shrunk comments
- 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
Interactive data services may take advantage of the possibility offered
by DVB-S2 to change the modulation format and error protection level, by
using the ACM functionality, thus allowing to differentiate service
levels (priority in the delivery queues, minimum bit rate etc)
6.1.1 Single generic Stream and ACM command
According to this system configuration, the DVB-S2 ACM modulator
receives 2 input signals. The first is the data stream continuous or
packetized. The second is the ACM command, carring the MODCOD
information used by the modulator for encoding and mapping each specific
portion of the input data stream.
..
From a different perspective, the data for filling a specific frame
need to be selected taking into account the physical layer mode
requested by the Satellite terminals to whom they are addressed. This is
the reason why the MODCOD information is generated at the same time of
the user data selection and sent as an input to the DVB-S2 ACM modulator.
6.2.1 Independant framing issues (MPEG - TS)
In ACM or VCM applications, MODCOD may change on a frame by frame basis,
therefore some PL frames may use MODCOD configurations that some
receivers cannot demodulate.
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.
- removed coderate_LP and modcod from dvbs2_params -- not needed
- added flags field to dvbs2_params (future use, e.g. to add
ISI stream filter)
- deprecate FE_GET_EVENT and add FE_ACK_EVENTS
TODO:
- DVB-S2 has physical layer signalling, which I think is
similar to DVB-T TPS. I.e. the demod can figure out
modulation and fec all by itself. Similarly, roll-off
is part fo base-band signalling. So maybe we don't
need to set these for tuning and just need the fields
for FE_GET_PARAMS (for informational purposes).
The demod uses pilot tones to detect the PL signalling.
- 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.
- 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.
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 .. :-(
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 ?
Thanks,
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
