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.
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.
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.
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
