In message <1a297b360703180629v27effabej8948d02634f91c3a@xxxxxxxxxxxxxx>, "Manu Abraham" wrote:
>On 3/18/07, Darron Broad <darron@xxxxxxxx> wrote:
>> In message <1a297b360703180613p51a82364we3fcc6e8efb9f161@xxxxxxxxxxxxxx>, "Manu Abraham" wrote:
>> >On 3/18/07, Darron Broad <darron@xxxxxxxx> wrote:
lo
>> lo
>>
>> >
>> >> I can't even see why you would need to even set the delivery
>> >> type to query the delivery parameters.
>> >
>> >
>> >If the delivery parameters are the same, i don't see why you need an
>> >API update and all the hell, if it had just the same delivery
>> >parameters. ;-)
>>
>> i didn't say you should not specify the delivery type when
>> querying, just not set it.
>>
>> the cx24116 driver as it stands may return one of two static
>> structures when get_info is called.
>>
>> it makes no point to me to query for this detail prior to
>> every set_params, hence, setting internal state on get_info
>> is asking for problems, however, setting the delivery path
>> on set_params does makes sense.
>>
>
>
>I think you still didn't understand. Don't see any easy way in which i
>can explain better. :-(
I don't understand the naming conventions or interface.
I assume you expect an application to perform the following
when tuning:
1. get_info
2. validate parms based on info
3. set_params
Where we seem to disagree is that get_info may set internal state
which I think is wrong, however, i see your point if it's an
absolute requirement to always call get_info prior to set_params.
this is purely a naming convention based on wisdom, GET should
not SET, and we already have two examples where misunderstanding
or this can cause trouble. Firstly with Steve's demod driver
where it doesn't set the delivery on get_info and with me
not expecting the delivery to be set on get_info.
Basically, if it stays the way it is, I can only see more
misunderstandings.
>> >For multistandard devices, capabilities are different due to the
>> >different demodulator cores on the relevant chip (for
>> >dvb-s/dvb-s2/dss), whether it be vendor X or Y, it is indeed
>> >implemented that way only. And the basics specs just talks the same.
>> >
>> >This is due to the fact that the DVB-S2 DSP core is different from the
>> >DVB-S/DSS DSP core, as mentioned in the DVB-S2 specs
>> >
>> >Usually, the Viterbi decoder will be on another separate core from the
>> >demodulator
>>
>> yes, but one question, why doesn't the multiproto driver aggregate
>> demods?
>
>
>Multiproto is not a driver, but an API update. The demods are not
>aggregated just for backward compatibility as mentioned by the DVB
>specs.
yes, it is not a driver, my mistake.
i see, so the reason is that although you may have easily aggregated
them for the multiproto API, it's hard work to also allow seperate
interfaces for the older API.
this suggests a whole new API is required without backward
compatibility.
>> I can see it handling multiple protocol on one physical device,
>
>
>Multiproto was done in a way such as to incorporate current existing
>devices as well as new multistandard devices.
>
>
>> but this doesn't extend to cards that contain multiple physical demods
>> yet with only the one bus path, such as the hvr4000?
>
>
>Multiproto is just for handling multistandard devices, not multiple demods.
ok. thx
darron
--
// /
{:)==={ Darron Broad <darron@xxxxxxxx>
\\ \
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
