Hi,
On Mon, Mar 03, 2008 at 02:43:33AM +0400, Manu Abraham wrote:
> Florian Lohoff wrote:
> >Hi,
> >i was wondering why i have a problem in my application that i need to
> >run scan once after loading the module, otherwise my DVBFE_SET_PARAMS
> >fails - I couldnt explain it until i looked into the kernel code - In
> >the dvb_frontend.c i see this code:
> >
> >1738 case DVBFE_SET_PARAMS: {
> >1739 struct dvb_frontend_tune_settings fetunesettings;
> >1740 enum dvbfe_delsys delsys = fepriv->fe_info.delivery;
> >...
> >1783 } else {
> >1784 /* default values */
> >1785 switch (fepriv->fe_info.delivery) {
> >...
> >1817 default:
> >1818 up(&fepriv->sem);
> >1819 return -EINVAL;
> >1820 }
> >
> >Should the code use fepriv->feparam.delivery instead of
> >fepriv->fe_info.delivery to sense the right delivery system ?
>
> Which demodulator driver are you using to test your application ?
STB0899 on a SkyStar HD - Using DVB-S2 on Astra
> Though a bug, but that won't make any difference to what you are looking at,
> since the delay and others are used in the case of swzigzag, which
> doesn't exist
> at least for the existing demods using the track() callback at all.
The problem i see and some people off list already acknowledged is that
the DVBFE_GET_INFO actually _SETS_ informations in the kernel about the
delivery system which gets even cached across frontend opens. This is
why my application, which did not issue a GET_INFO but rather set the
delivery system in the dvbfeparam, failed. The delivery in the
dvbfeparam in the DVBFE_SET_PARAM ioctl gets ignored. When running scan
once after loading the module the delivery system gets set and suddenly
my little app works, but only for the frontend/delivery type i pressed
ctrl-c on running scan, and until i reload the module.
I changed the kernel dvb_frontend.c to actually use the dvbfeparam
delivery system type but then the demod driver stb0899 pukes into my
kernel log that it finds an unknown delivery system because it makes the very
same assumption that it should use the delivery from GET_INFO and not
SET_PARAM ...
stb0899_drv.c:
1406 static int stb0899_get_info(struct dvb_frontend *fe, struct dvbfe_info *fe_info)
1407 {
1408 struct stb0899_state *state = fe->demodulator_priv;
1409
1410 dprintk(verbose, FE_DEBUG, 1, "Get Info");
1411
1412 state->delsys = fe_info->delivery;
1413 switch (state->delsys) {
Line 1412 caches informations in the frontend demod without purpose - Get info is just
that and not some state altering ioctl ...
> This would be a fix for any demod drivers using the set_params() callback.
Yep - something should be fixed - currently its a little inconsistent:
- A GET or READ call should never ever alter state - otherwise it should be named
different. Its the same with read/write, peek/poke, load/store set/get.
Just because i ask about informations concerning the DVB-S frontend does
not mean that i will not start DVB-S2 or DSS.
- If DVBFE_SET_PARAM passes a struct which contains a delivery system it
should either be honored or not even be there. On a SET call with a struct
every application writers assumption is that the values in the struct passed
actually get honored.
And this MUST be coherent for all demods.
Flo
--
Florian Lohoff flo@xxxxxxxxxx +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
