[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RFC: Improve VIDIOC_S_HW_FREQ_SEEK



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


[Linux Input]     [Video for Linux]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Photos]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Devices]     [Yosemite Backpacking]

Add to Google Powered by Linux