mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-11-30 07:56:45 +07:00
55d4423a2d
The new code that detects undocumented ioctls hits some false positives: This one is not documented, nor it should, as this is there just to reserve namespace: Warning: can't find reference for VIDIOC_RESERVED ioctl But those are already documented together with other ioctls: Warning: can't find reference for VIDIOC_UNSUBSCRIBE_EVENT ioctl Warning: can't find reference for FE_GET_PROPERTY ioctl Warning: can't find reference for VIDIOC_SUBDEV_G_EDID ioctl Warning: can't find reference for VIDIOC_SUBDEV_S_EDID ioctl Warning: can't find reference for VIDIOC_SUBDEV_S_DV_TIMINGS ioctl Warning: can't find reference for VIDIOC_SUBDEV_G_DV_TIMINGS ioctl Warning: can't find reference for VIDIOC_SUBDEV_QUERY_DV_TIMINGS ioctl So, we need to just be sure to point to the right documentation. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
172 lines
7.0 KiB
XML
172 lines
7.0 KiB
XML
<refentry id="vidioc-g-edid">
|
|
<refmeta>
|
|
<refentrytitle>ioctl VIDIOC_G_EDID, VIDIOC_S_EDID</refentrytitle>
|
|
&manvol;
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>VIDIOC_G_EDID</refname>
|
|
<refname>VIDIOC_S_EDID</refname>
|
|
<refname>VIDIOC_SUBDEV_G_EDID</refname>
|
|
<refname>VIDIOC_SUBDEV_S_EDID</refname>
|
|
<refpurpose>Get or set the EDID of a video receiver/transmitter</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_edid *<parameter>argp</parameter></paramdef>
|
|
</funcprototype>
|
|
</funcsynopsis>
|
|
<funcsynopsis>
|
|
<funcprototype>
|
|
<funcdef>int <function>ioctl</function></funcdef>
|
|
<paramdef>int <parameter>fd</parameter></paramdef>
|
|
<paramdef>int <parameter>request</parameter></paramdef>
|
|
<paramdef>struct v4l2_edid *<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_G_EDID, VIDIOC_S_EDID, VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><parameter>argp</parameter></term>
|
|
<listitem>
|
|
<para></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
<para>These ioctls can be used to get or set an EDID associated with an input
|
|
from a receiver or an output of a transmitter device. They can be
|
|
used with subdevice nodes (/dev/v4l-subdevX) or with video nodes (/dev/videoX).</para>
|
|
|
|
<para>When used with video nodes the <structfield>pad</structfield> field represents the
|
|
input (for video capture devices) or output (for video output devices) index as
|
|
is returned by &VIDIOC-ENUMINPUT; and &VIDIOC-ENUMOUTPUT; respectively. When used
|
|
with subdevice nodes the <structfield>pad</structfield> field represents the
|
|
input or output pad of the subdevice. If there is no EDID support for the given
|
|
<structfield>pad</structfield> value, then the &EINVAL; will be returned.</para>
|
|
|
|
<para>To get the EDID data the application has to fill in the <structfield>pad</structfield>,
|
|
<structfield>start_block</structfield>, <structfield>blocks</structfield> and <structfield>edid</structfield>
|
|
fields and call <constant>VIDIOC_G_EDID</constant>. The current EDID from block
|
|
<structfield>start_block</structfield> and of size <structfield>blocks</structfield>
|
|
will be placed in the memory <structfield>edid</structfield> points to. The <structfield>edid</structfield>
|
|
pointer must point to memory at least <structfield>blocks</structfield> * 128 bytes
|
|
large (the size of one block is 128 bytes).</para>
|
|
|
|
<para>If there are fewer blocks than specified, then the driver will set <structfield>blocks</structfield>
|
|
to the actual number of blocks. If there are no EDID blocks available at all, then the error code
|
|
ENODATA is set.</para>
|
|
|
|
<para>If blocks have to be retrieved from the sink, then this call will block until they
|
|
have been read.</para>
|
|
|
|
<para>If <structfield>start_block</structfield> and <structfield>blocks</structfield> are
|
|
both set to 0 when <constant>VIDIOC_G_EDID</constant> is called, then the driver will
|
|
set <structfield>blocks</structfield> to the total number of available EDID blocks
|
|
and it will return 0 without copying any data. This is an easy way to discover how many
|
|
EDID blocks there are. Note that if there are no EDID blocks available at all, then
|
|
the driver will set <structfield>blocks</structfield> to 0 and it returns 0.</para>
|
|
|
|
<para>To set the EDID blocks of a receiver the application has to fill in the <structfield>pad</structfield>,
|
|
<structfield>blocks</structfield> and <structfield>edid</structfield> fields and set
|
|
<structfield>start_block</structfield> to 0. It is not possible to set part of an EDID,
|
|
it is always all or nothing. Setting the EDID data is only valid for receivers as it makes
|
|
no sense for a transmitter.</para>
|
|
|
|
<para>The driver assumes that the full EDID is passed in. If there are more EDID blocks than
|
|
the hardware can handle then the EDID is not written, but instead the error code E2BIG is set
|
|
and <structfield>blocks</structfield> is set to the maximum that the hardware supports.
|
|
If <structfield>start_block</structfield> is any
|
|
value other than 0 then the error code EINVAL is set.</para>
|
|
|
|
<para>To disable an EDID you set <structfield>blocks</structfield> to 0. Depending on the
|
|
hardware this will drive the hotplug pin low and/or block the source from reading the EDID
|
|
data in some way. In any case, the end result is the same: the EDID is no longer available.
|
|
</para>
|
|
|
|
<table pgwide="1" frame="none" id="v4l2-edid">
|
|
<title>struct <structname>v4l2_edid</structname></title>
|
|
<tgroup cols="3">
|
|
&cs-str;
|
|
<tbody valign="top">
|
|
<row>
|
|
<entry>__u32</entry>
|
|
<entry><structfield>pad</structfield></entry>
|
|
<entry>Pad for which to get/set the EDID blocks. When used with a video device
|
|
node the pad represents the input or output index as returned by
|
|
&VIDIOC-ENUMINPUT; and &VIDIOC-ENUMOUTPUT; respectively.</entry>
|
|
</row>
|
|
<row>
|
|
<entry>__u32</entry>
|
|
<entry><structfield>start_block</structfield></entry>
|
|
<entry>Read the EDID from starting with this block. Must be 0 when setting
|
|
the EDID.</entry>
|
|
</row>
|
|
<row>
|
|
<entry>__u32</entry>
|
|
<entry><structfield>blocks</structfield></entry>
|
|
<entry>The number of blocks to get or set. Must be less or equal to 256 (the
|
|
maximum number of blocks as defined by the standard). When you set the EDID and
|
|
<structfield>blocks</structfield> is 0, then the EDID is disabled or erased.</entry>
|
|
</row>
|
|
<row>
|
|
<entry>__u32</entry>
|
|
<entry><structfield>reserved</structfield>[5]</entry>
|
|
<entry>Reserved for future extensions. Applications and drivers must
|
|
set the array to zero.</entry>
|
|
</row>
|
|
<row>
|
|
<entry>__u8 *</entry>
|
|
<entry><structfield>edid</structfield></entry>
|
|
<entry>Pointer to memory that contains the EDID. The minimum size is
|
|
<structfield>blocks</structfield> * 128.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
&return-value;
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><errorcode>ENODATA</errorcode></term>
|
|
<listitem>
|
|
<para>The EDID data is not available.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><errorcode>E2BIG</errorcode></term>
|
|
<listitem>
|
|
<para>The EDID data you provided is more than the hardware can handle.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect1>
|
|
</refentry>
|