Johannes Stezenbach wrote:
On Mon, May 22, 2006, Manu Abraham wrote:
Johannes Stezenbach wrote:
For binary compatibility it isn't sufficient to just add new
fields to struct dvbs2_params. There must also be an indicator
which the kernel can use to see if struct dvb_frontend_params
was prepared by old or new userspace, i.e. if the new fields
are valid or contain uninitialized data.
That's why I propsed a "flags" field for struct dvbs2_params
in my version of the patch.
+/*
+ * DVB-S2 parameters
+ * ETSI EN 302 307, TR 102 376, EN 301 210
+ */
+struct dvbs2_params {
+ __u32 symbol_rate;
+ __u32 flags; /* for future use, must be 0 for now */
+
+ enum dvb_fe_modulation modulation;
+ enum dvb_fe_fec fec;
+ enum dvb_fe_rolloff rolloff;
+ enum dvb_fe_stream_priority priority;
+};
And , what do these flags do ? I hope it is not a secret.
Currently nothing, as the comment says.
Well, i did not understand what it does . So either it is wrong or the
Comment is wrong.
I don't know which, after reading the specs and having device specs, i
don't know how to write code according to your changes.
Well, this implementation is perfectly broken. I don't want to argue on
this damn thing. i don't know why you are arguing for a damn broken thing.
Can you please explain how you will be using this godamn thing ? I don't
know how to use this.
e.g. a future version could look like this:
struct dvbs2_params {
__u32 symbol_rate;
__u32 flags; /* for future use, must be 0 for now */
#define DVBS2_SET_STREAM_ID (1 << 0)
enum dvb_fe_modulation modulation;
enum dvb_fe_fec fec;
enum dvb_fe_rolloff rolloff;
enum dvb_fe_stream_priority priority;
__u8 stream_id;
};
...if it turns out that we really need it.
Why the Hell ?
1) From 300 468, 6.2.13.3, S2 Satellite delivery system descriptor
if sis/mis(1 bit) flag then input stream identifier (8 bits)
2) From 302 307 Table 3 (MATYPE-1 field mapping) SIS/MIS
3) From the STB0899 datasheet, p 44, 9.3 Stream Filter Mechanism
SIS/MIS (1 bit): describes whether there is a single input stream or
multiple input streams. If SIS/
MIS = multiple input stream, then the second byte is the input stream
identifier (ISI), otherwise
the second byte is reserved.
Now, quoting yourself, "...if it turns out that we really need it ". In
such case, you mean to say that these documents are wrong as also the
device datasheet ?
Maybe we need to create our own specs for DVB-S2 ? ;-) Well, probably
that explains why even though there is enough information, drivers don't
work good enough (there is bad hardware though, not talking about that).
I hear people crying to open up nVidia driver source. why ? Well, nVidia
does a great job of getting the driver moving. Well if the source and
info were to be given to the guys, well it would've been another sad
story. No wonder they don't want to open up. I highly appreciate the
fact that they don't open up, even though personally i would like to see
it Open sourced.
I haven't been in DVB development as long as you, but i certainly am
sane enough as to include that which belongs to the spec and to the
driver into the API/driver. I really don't understand how you can call
it wrong and certainly "add them as flags (u32)". Well __u32. Sorry,
"The world is coloured, rather than Black or White", Insane !
This discussion certainly reminds me of the discussion on the SAS
discussions on LKML, where "Linus finally said specs are wrong." Well,
if specs and device vendors are wrong .. well i wonder who is right ..
FYI, Regarding the Physical layer scrambling it _is_ wrong to assume
that the device does not do scrambling. EN 300 468 explicitly states
that scrambling sequence selector: A value of 0 specifies that the
default DVB-S2 physical layer scrambling sequence of index n=0 is used.
A value of 1 means that the default scrambling sequence is not used and
that the sequence index n will be conveyed by the scrambling sequence
index field.
I see that the device is set to the zeroth Gold code sequence, ie index
n=0. So that is the default scrambling scheme. I don't know how it can
support anything other than the default.
So in this regard i chose not to add in the scrambling sequence index,
as that can be added later on, as you said.
In any case, we do plan to mark it "EXPERIMENTAL" Right ?
I still don't understand where the discussions are going. hence i am
repeatedly asking how you are looking at it, for this to be integrated,
since you seem to have a different plan altogether.
And here we are talking future compatibility for a broken API.. Great ..
Thanks,
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
