On Tuesday 01 May 2012 18:19:39 halli manjunatha wrote:
> On Tue, May 1, 2012 at 4:46 AM, Hans Verkuil <[email protected]> wrote:
> > Hi all!
> >
> > While working on a test function for the hardware seek functionality in
> > v4l2-compliance I realized that the specification is rather vague and
> > incomplete, making it hard to write a decent test for it.
> >
> > There are a number of issues with this API:
> >
> > 1) There is no way for the application to know whether the hardware supports
> > wrap around scanning or not (or both). It is only reported because the
> > ioctl will return EINVAL if it doesn't support it, which is rather
> > awkward.
> > It's important for applications to know what to do here.
> >
> > The solution would be to add two new capability flags to struct
> > v4l2_tuner:
> > V4L2_TUNER_CAP_SEEK_BOUNDED and V4L2_TUNER_CAP_SEEK_WRAP.
> >
> > 2) What happens when the seek didn't find anything? It's not a timeout, it
> > has
> > to return some decent error code. I propose ENODATA for this.
> >
> > 3) What should the frequency be if the seek returns an error? I think the
> > original
> > frequency should be restored in that case.
> Isn't this the way how it is now? means driver won't change the
> G_FREQUENCY value till it gets the new valid station during seek.
That's how it is done today, but that behavior is not specified in the v4l2
spec.
>
> >
> > 4) What should happen if you try to set the frequency while a seek is in
> > operation?
> > In that case -EBUSY should be returned by VIDIOC_S_FREQUENCY.
> >
> > 5) What should happen if you try to get the frequency while a seek is in
> > operation?
> > It would be nice if you could get the frequency that is currently being
> > scanned.
> >
> > There are two options to implement this:
> >
> > a) Add a new 'scan_frequency' field to struct v4l2_frequency. So the
> > frequency
> > field would always contain the frequency that was set when the seek
> > started,
> > and the scan_frequency is either 0 (no seek is in progress), a special
> > value
> > V4L2_SCAN_IN_PROGRESS (seek is in progress, but the hardware can't
> > tell what
> > the current seek frequency is) or it contains the frequency that is
> > currently
> > being scanned.
> >
> > b) Add a new V4L2_TUNER_CAP_HAS_SEEK_FREQ capability to struct
> > v4l2_tuner. If
> > set, then VIDIOC_G_FREQUENCY will return the scan frequency when
> > scanning,
> > otherwise it will return the normal frequency.
> >
> > I think I like option a) better. It gives you all the information you
> > need.
> Even I prefer option A here.
> >
> > 6) What does it mean when you get a time out? The spec just says 'Try
> > again'. But
> > try what? If it times out due to hardware issues, then a proper error
> > should be
> > returned. That leaves a time out due to the scan not finding any
> > channels, but not
> > reaching the end of the scan either (because that would be a ENODATA
> > return code).
> >
> > What should be the frequency in this case? The original frequency or the
> > last
> > scanned frequency? And on older hardware you may not be able to get that
> > last scanned
> > frequency.
> >
> > I suggest one of two options:
> >
> > a) Abolish the time out altogether. The driver author has to set the
> > internal
> > timeout to such a large value that if you time out, then you can just
> > return
> > -ENODATA.
> >
> > b) Hardware that cannot detect the current scan frequency behaves as a).
> > Hardware
> > that can detect the scan frequency will return -EAGAIN, but sets the
> > frequency
> > at the last scanned frequency.
Do you have any opinion/insights into this?
Regards,
Hans
> >
> > 7) It would be nice if the ioctl was RW instead of just a write ioctl. That
> > way the
> > driver could report the proper spacing value that it used. I'm not
> > entirely sure
> > it is worth the effort at this moment though.
> >
> > Comments? Questions?
> >
> > Regards,
> >
> > Hans
> > --
> > 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
> --
> 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
>
--
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
