[linux-dvb] DVBFE_SET_PARAMS / delsys from fe_info ioctl ?

Florian Lohoff flo at rfc822.org
Mon Mar 3 00:36:53 CET 2008


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

1406 static int stb0899_get_info(struct dvb_frontend *fe, struct dvbfe_info *fe_info)
1407 {
1408         struct stb0899_state *state = fe->demodulator_priv;
1410         dprintk(verbose, FE_DEBUG, 1, "Get Info");
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.

Florian Lohoff                  flo at rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.linuxtv.org/pipermail/linux-dvb/attachments/20080303/3c38dda7/attachment.pgp 

More information about the linux-dvb mailing list