linux/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml

185 lines
6.4 KiB
XML
Raw Normal View History

<refentry id="vidioc-s-hw-freq-seek">
<refmeta>
<refentrytitle>ioctl VIDIOC_S_HW_FREQ_SEEK</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_S_HW_FREQ_SEEK</refname>
<refpurpose>Perform a hardware frequency seek</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>struct v4l2_hw_freq_seek
*<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_S_HW_FREQ_SEEK</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>Start a hardware frequency seek from the current frequency.
To do this applications initialize the <structfield>tuner</structfield>,
<structfield>type</structfield>, <structfield>seek_upward</structfield>,
<structfield>wrap_around</structfield>, <structfield>spacing</structfield>,
<structfield>rangelow</structfield> and <structfield>rangehigh</structfield>
fields, and zero out the <structfield>reserved</structfield> array of a
&v4l2-hw-freq-seek; and call the <constant>VIDIOC_S_HW_FREQ_SEEK</constant>
ioctl with a pointer to this structure.</para>
<para>The <structfield>rangelow</structfield> and
<structfield>rangehigh</structfield> fields can be set to a non-zero value to
tell the driver to search a specific band. If the &v4l2-tuner;
<structfield>capability</structfield> field has the
<constant>V4L2_TUNER_CAP_HWSEEK_PROG_LIM</constant> flag set, these values
must fall within one of the bands returned by &VIDIOC-ENUM-FREQ-BANDS;. If
the <constant>V4L2_TUNER_CAP_HWSEEK_PROG_LIM</constant> flag is not set,
then these values must exactly match those of one of the bands returned by
&VIDIOC-ENUM-FREQ-BANDS;. If the current frequency of the tuner does not fall
within the selected band it will be clamped to fit in the band before the
seek is started.</para>
<para>If an error is returned, then the original frequency will
be restored.</para>
<para>This ioctl is supported if the <constant>V4L2_CAP_HW_FREQ_SEEK</constant> capability is set.</para>
<para>If this ioctl is called from a non-blocking filehandle, then &EAGAIN; is
returned and no seek takes place.</para>
<table pgwide="1" frame="none" id="v4l2-hw-freq-seek">
<title>struct <structname>v4l2_hw_freq_seek</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>tuner</structfield></entry>
<entry>The tuner index number. This is the
same value as in the &v4l2-input; <structfield>tuner</structfield>
field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
</row>
<row>
[media] v4l2: use __u32 rather than enums in ioctl() structs V4L2 uses the enum type in IOCTL arguments in IOCTLs that were defined until the use of enum was considered less than ideal. Recently Rémi Denis-Courmont brought up the issue by proposing a patch to convert the enums to unsigned: <URL:http://www.spinics.net/lists/linux-media/msg46167.html> This sparked a long discussion where another solution to the issue was proposed: two sets of IOCTL structures, one with __u32 and the other with enums, and conversion code between the two: <URL:http://www.spinics.net/lists/linux-media/msg47168.html> Both approaches implement a complete solution that resolves the problem. The first one is simple but requires assuming enums and __u32 are the same in size (so we won't break the ABI) while the second one is more complex and less clean but does not require making that assumption. The issue boils down to whether enums are fundamentally different from __u32 or not, and can the former be substituted by the latter. During the discussion it was concluded that the __u32 has the same size as enums on all archs Linux is supported: it has not been shown that replacing those enums in IOCTL arguments would break neither source or binary compatibility. If no such reason is found, just replacing the enums with __u32s is the way to go. This is what this patch does. This patch is slightly different from Remi's first RFC (link above): it uses __u32 instead of unsigned and also changes the arguments of VIDIOC_G_PRIORITY and VIDIOC_S_PRIORITY. Signed-off-by: Rémi Denis-Courmont <remi@remlab.net> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-05-10 13:02:07 +08:00
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry>The tuner type. This is the same value as in the
[media] v4l2: use __u32 rather than enums in ioctl() structs V4L2 uses the enum type in IOCTL arguments in IOCTLs that were defined until the use of enum was considered less than ideal. Recently Rémi Denis-Courmont brought up the issue by proposing a patch to convert the enums to unsigned: <URL:http://www.spinics.net/lists/linux-media/msg46167.html> This sparked a long discussion where another solution to the issue was proposed: two sets of IOCTL structures, one with __u32 and the other with enums, and conversion code between the two: <URL:http://www.spinics.net/lists/linux-media/msg47168.html> Both approaches implement a complete solution that resolves the problem. The first one is simple but requires assuming enums and __u32 are the same in size (so we won't break the ABI) while the second one is more complex and less clean but does not require making that assumption. The issue boils down to whether enums are fundamentally different from __u32 or not, and can the former be substituted by the latter. During the discussion it was concluded that the __u32 has the same size as enums on all archs Linux is supported: it has not been shown that replacing those enums in IOCTL arguments would break neither source or binary compatibility. If no such reason is found, just replacing the enums with __u32s is the way to go. This is what this patch does. This patch is slightly different from Remi's first RFC (link above): it uses __u32 instead of unsigned and also changes the arguments of VIDIOC_G_PRIORITY and VIDIOC_S_PRIORITY. Signed-off-by: Rémi Denis-Courmont <remi@remlab.net> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-05-10 13:02:07 +08:00
&v4l2-tuner; <structfield>type</structfield> field. See <xref
linkend="v4l2-tuner-type" /></entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>seek_upward</structfield></entry>
<entry>If non-zero, seek upward from the current frequency, else seek downward.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>wrap_around</structfield></entry>
<entry>If non-zero, wrap around when at the end of the frequency range, else stop seeking.
The &v4l2-tuner; <structfield>capability</structfield> field will tell you what the
hardware supports.
</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>spacing</structfield></entry>
<entry>If non-zero, defines the hardware seek resolution in Hz. The driver selects the nearest value that is supported by the device. If spacing is zero a reasonable default value is used.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>rangelow</structfield></entry>
<entry>If non-zero, the lowest tunable frequency of the band to
search in units of 62.5 kHz, or if the &v4l2-tuner;
<structfield>capability</structfield> field has the
<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz.
If <structfield>rangelow</structfield> is zero a reasonable default value
is used.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>rangehigh</structfield></entry>
<entry>If non-zero, the highest tunable frequency of the band to
search in units of 62.5 kHz, or if the &v4l2-tuner;
<structfield>capability</structfield> field has the
<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz.
If <structfield>rangehigh</structfield> is zero a reasonable default value
is used.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[5]</entry>
<entry>Reserved for future extensions. Applications
must set the array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The <structfield>tuner</structfield> index is out of
bounds, the <structfield>wrap_around</structfield> value is not supported or
one of the values in the <structfield>type</structfield>,
<structfield>rangelow</structfield> or <structfield>rangehigh</structfield>
fields is wrong.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EAGAIN</errorcode></term>
<listitem>
<para>Attempted to call <constant>VIDIOC_S_HW_FREQ_SEEK</constant>
with the filehandle in non-blocking mode.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENODATA</errorcode></term>
<listitem>
<para>The hardware seek found no channels.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>Another hardware seek is already in progress.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>