> From: Andreas Oberritter [mailto:[email protected]]
> Sent: Wednesday, January 19, 2011 7:12 PM
> To: Thierry LELEGARD
> Cc: [email protected]; Devin Heitmueller
> Subject: Re: [linux-media] API V3 vs SAPI behavior difference in reading
> tuning
> parameters
>
> On 01/19/2011 06:03 PM, Thierry LELEGARD wrote:
> > OK, then what? Is the S2API behavior (returning cached - but incorrect -
> > tuning
> > parameter values) satisfactory for everyone or shall we adapt S2API to
> > mimic the
> > API V3 behavior (return the actual tuning parameter values as automatically
> > adjusted by the driver)?
>
> To quote myself:
>
> if that's still the case in Git (I didn't verify), then it should indeed
> be changed to behave like v3 does. Would you mind to submit a patch, please?
>
> I haven't heard any objections, so just go on if you want. Otherwise I
> might prepare a patch once time permits.
>
> Regards,
> Andreas
Sorry for the late follow-up due to busy projects.
Yes, the latest git suffers from the same problem. The values returned
by FE_GET_PROPERTY (S2API) are sometimes wrong while the values returned
by FE_GET_FRONTEND (API V3) are correct, or at least as correct as the
driver can say.
Looking at the code in dvb_frontend.c, the reasons are pretty obvious.
FE_GET_PROPERTY directly returns cached values (at S2API level) while
FE_GET_FRONTEND asks the driver to return values. When the application
sends "auto" values (xxx_AUTO) or even wrong values that the driver is
able to correct, FE_GET_PROPERTY returns the same auto or wrong values
while FE_GET_FRONTEND returns the values that the driver has discovered
or decided to apply.
FE_GET_PROPERTY returning only cached values:
static int dtv_property_process_get(struct dvb_frontend *fe,
struct dtv_property *tvp,
struct file *file)
{
int r = 0;
/* Allow the frontend to validate incoming properties */
if (fe->ops.get_property)
r = fe->ops.get_property(fe, tvp);
if (r < 0)
return r;
switch(tvp->cmd) {
case DTV_FREQUENCY:
tvp->u.data = fe->dtv_property_cache.frequency;
break;
case DTV_MODULATION:
tvp->u.data = fe->dtv_property_cache.modulation;
break;
case DTV_BANDWIDTH_HZ:
tvp->u.data = fe->dtv_property_cache.bandwidth_hz;
break;
...etc...
FE_GET_FRONTEND asking the driver to return its own values:
static int dvb_frontend_ioctl_legacy(struct file *file,
unsigned int cmd, void *parg)
{
...etc...
case FE_GET_FRONTEND:
if (fe->ops.get_frontend) {
memcpy (parg, &fepriv->parameters, sizeof (struct
dvb_frontend_parameters));
err = fe->ops.get_frontend(fe, (struct
dvb_frontend_parameters*) parg);
}
break;
...etc...
How to fix this?
For legacy drivers, it is still possible to invoke driver's get_frontend
to get the correct values in a struct dvb_frontend_parameters. But, for
new drivers and new protocols for which some properties cannot be emulated
in a struct dvb_frontend_parameters, I do not see any driver callback to
"ask for the value of a property". The callback get_property seems to be
here to "validate" the usage of a property in the driver's context. As you
can see, dtv_property_process_get simply checks the returned value but
ignore a possible update of the struct dtv_property. Moreover, I have
checked the code of a few drivers implementing get_property and the
general idea is usually simply "return 0".
I do think that this problem is a functional regression from API V3 for
most users. But I do not see an obvious and general way of fixing it.
Any idea ?
Best regards,
-Thierry
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
