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

Manu Abraham abraham.manu at gmail.com
Mon May 22 13:07:42 CEST 2006


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




More information about the linux-dvb mailing list