On 3/18/07, Darron Broad <darron@xxxxxxxx> wrote:
In message <1a297b360703180432v94b513bj441248b8a59a62c2@xxxxxxxxxxxxxx>, "Manu Abraham" wrote: lo >On 3/18/07, Darron Broad <darron@xxxxxxxx> wrote: >> In message <1a297b360703180407r63b1e98dj561ae0a0abc8188f@xxxxxxxxxxxxxx>, "Manu Abraham" wrote: >> >On 3/18/07, Darron Broad <darron@xxxxxxxx> 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.
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 what szap does (on each szap) -- * DVBFE_GET_INFO (set's up delivery system for querying the relevant info) * DVBFE_SET_PARAMS (set the "current" delivery system related parameters) Worked for me, both ways toggling between dvb-s and dvb-s2. For a couple of others as well, AFAICS. Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
