[linux-dvb] HVR4000 Support

Darron Broad darron at kewl.org
Sun Mar 18 13:27:36 CET 2007


In message <1a297b360703180519u37d74a21odef02832bd4e9717 at mail.gmail.com>, "Manu Abraham" wrote:

lo

>On 3/18/07, Darron Broad <darron at kewl.org> wrote:
>> In message <1a297b360703180500k6150309cm23f9e03650ff3586 at mail.gmail.com>, "Manu Abraham" wrote:
>>
>> lo
>>
>> >On 3/18/07, Darron Broad <darron at kewl.org> wrote:
>> >> In message <1a297b360703180432v94b513bj441248b8a59a62c2 at mail.gmail.com>, "Manu Abraham" wrote:
>> >>
>> >> lo
>> >>
>> >> >On 3/18/07, Darron Broad <darron at kewl.org> wrote:
>> >> >> In message <1a297b360703180407r63b1e98dj561ae0a0abc8188f at mail.gmail.com>, "Manu Abraham" wrote:
>> >> >> >On 3/18/07, Darron Broad <darron at kewl.org> wrote:
>> >> >>
>> >> >> lo
>> >> >>
>> >> >> >> >> 3. the delivery field has to be set
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >delivery system is set using DVBFE_SET_PARAMS, without which you
>> >> >> >> >wouldn't be able to tune to anything, because of the switch statement.
>> >> >> >>
>> >> >> >> the delivery type is indeed taken from the command line and used for
>> >> >> >> logic in the code, however, it's not passed to the driver.
>> >> >> >>
>> >> >> >
>> >> >> >It is. Take a look at the delsys switch in the stb0899 driver. The
>> >> >> >STB0899 depends on the delivery system and the Physical Layer
>> >> >> >parameters to decide which modulation to use.
>> >> >> >
>> >> >> >http://linuxtv.org/hg/~manu/stb0899-c5?f=d6f0bf7681d1;file=linux/drivers/media/dvb/frontends/stb0899_drv
>.c;
>> >sty
>> >> >le=
>> >> >> >gitweb
>> >> >> >The delivery system is sent to the driver, without which
>> >> >> >tuning/demodulation is impossible "on any multistandard demod"
>> >> >>
>> >> >> specifically Steve's driver needs to the delivery system type
>> >> >> to be set when calling set_params.
>> >> >>
>> >> >> it would appear from your code snippet that your driver is
>> >> >> setting internal state when peforming a query. surely this
>> >> >> is illogical behaviour.
>> >> >
>> >> >
>> >> >Sorry, nope. Since the IOCTL is RW not R
>> >>
>> >> >#define DVBFE_GET_INFO _IOWR('o', 85, struct dvbfe_info)
>> >>
>> >> please explain why you have chosen a function named GET
>> >> to SET internal state.
>> >>
>> >
>> >on a multistandard demod/tuner, what info do you want to get ? Rather
>> >than setting delivery system again which is redundant, it is used with
>> >the same IOCTL
>> >
>> >It doesn't matter whether one uses set_params (does a blind setup of
>> >the frontend) or search (uses a frontend dependant algorithm to do
>> >scan's /szap or say blindscan's)
>> >
>> >just that the delivery system type is cached in one IOCTL call, which
>> >anyway needs to be set to get the relevant delivery system type.
>>
>> i can see what is happening but it doesn't make sense for a
>> developer.
>>
>> GET ought to return current state as is, there is no point
>> making assumptions about what the application may or may
>> be doing next, because that's a total unknown. However, what
>> we do know is that application programmers won't be expecting
>> to change anything in a GET but will be in a SET.
>>
>> whether what the GET returns being useful or not is not
>> interesting to me.
>>
>> >> BTW, the unmodded szap only worked for you because it
>> >> queried the current state inadvertantly setting internal
>> >> state before calling set_params without actually specifying
>> >> the correct internal state.
>> >
>> >> if an application does a query and sets state to DVB-S2
>> >> then decides to tune to DVB-S the internal state will
>> >> be incorrect.
>> >
>> >Don't think so
>>
>> If you refer to the code Steve wrote you will see that he has
>> made the obvious assumptions about get_info and set_params
>
>
>In my case i need to set a delivery type to query the relevant
>delivery type parameter
>I don't think it is sane to use the same thing twice. It sounds quite
>illogical to me.

in that case there should be a SET_DELIVERY then GET_INFO, however,
I can't even see why you would need to even set the delivery
type to query the delivery parameters.

>For example i would tell the demod, that i need the info for the
>DELIVERY_SYSTEM_X in one shot, rather doing the same twice (doesn't
>make any sense to tell the demod twice)

but most apps will no doubt query the caps at the start in no
particular order and your driver will have state based on the last
query. why would anyone even bother performing this query more
than once?

>(just like some people don't like to be told twice the same thing .. ;-) )

exactly.

you would find the caps, then do stuff. when you do stuff you
will change the delivery method, you wouldn't query the caps
prior to every set_params, what's the point?

>> in the former it returns internal state, in the latter sets
>> intermal state. this is a widely understood interface concept.
>
>
>With one delivery system

I can't see this going much further. I suggest your either rename
this GET to GETSET or whatever, or do this properly.

bye

--

 // /
{:)==={ Darron Broad <darron at kewl.org>
 \\ \ 




More information about the linux-dvb mailing list