Skip to content

L
linux
Commit c7169ad5 authored by Hans Verkuil's avatar Hans Verkuil Committed by Mauro Carvalho Chehab
Browse files
Options

[media] DocBook/media: add CEC documentation 

Add DocBook documentation for the CEC API.
Signed-off-by: default avatarHans Verkuil <hansverk@cisco.com>
[k.debski@samsung.com: add documentation for passthrough mode]
[k.debski@samsung.com: minor fixes and change of reserved field sizes]
Signed-off-by: default avatarKamil Debski <kamil@wypas.org>
Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
parent c51202d3
Expand all Show whitespace changes
Inline Side-by-side
Showing with 1732 additions and 1 deletion
Documentation/DocBook/device-drivers.tmpl
View file @ c7169ad5
...@@ -272,6 +272,9 @@ X!Isound/sound_firmware.c ...@@ -272,6 +272,9 @@ X!Isound/sound_firmware.c
!Iinclude/media/media-devnode.h !Iinclude/media/media-devnode.h
!Iinclude/media/media-entity.h !Iinclude/media/media-entity.h
</sect1> </sect1>
<sect1><title>Consumer Electronics Control devices</title>
!Iinclude/media/cec-edid.h
</sect1>
</chapter> </chapter>
......
Documentation/DocBook/media/Makefile
View file @ c7169ad5
...@@ -64,6 +64,7 @@ IOCTLS = \ ...@@ -64,6 +64,7 @@ IOCTLS = \
$(shell perl -ne 'print "$$1 " if /\#define\s+([A-Z][^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/net.h) \ $(shell perl -ne 'print "$$1 " if /\#define\s+([A-Z][^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/net.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/video.h) \ $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/video.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/media.h) \ $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/media.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/cec.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \ $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \
DEFINES = \ DEFINES = \
...@@ -100,6 +101,7 @@ STRUCTS = \ ...@@ -100,6 +101,7 @@ STRUCTS = \
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/ && !/_old/)' $(srctree)/include/uapi/linux/dvb/net.h) \ $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/ && !/_old/)' $(srctree)/include/uapi/linux/dvb/net.h) \
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/video.h) \ $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/video.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/media.h) \ $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/media.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/linux/cec.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \ $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-mediabus.h) $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-mediabus.h)
......
Documentation/DocBook/media/v4l/biblio.xml
View file @ c7169ad5
...@@ -342,6 +342,16 @@ in the frequency range from 87,5 to 108,0 MHz</title> ...@@ -342,6 +342,16 @@ in the frequency range from 87,5 to 108,0 MHz</title>
<subtitle>Specification Version 1.4a</subtitle> <subtitle>Specification Version 1.4a</subtitle>
</biblioentry> </biblioentry>
<biblioentry id="hdmi2">
<abbrev>HDMI2</abbrev>
<authorgroup>
<corpauthor>HDMI Licensing LLC
(<ulink url="http://www.hdmi.org">http://www.hdmi.org</ulink>)</corpauthor>
</authorgroup>
<title>High-Definition Multimedia Interface</title>
<subtitle>Specification Version 2.0</subtitle>
</biblioentry>
<biblioentry id="dp"> <biblioentry id="dp">
<abbrev>DP</abbrev> <abbrev>DP</abbrev>
<authorgroup> <authorgroup>
......
Documentation/DocBook/media/v4l/cec-api.xml 0 → 100644
View file @ c7169ad5
<partinfo>
<authorgroup>
<author>
<firstname>Hans</firstname>
<surname>Verkuil</surname>
<affiliation><address><email>hans.verkuil@cisco.com</email></address></affiliation>
<contrib>Initial version.</contrib>
</author>
</authorgroup>
<copyright>
<year>2016</year>
<holder>Hans Verkuil</holder>
</copyright>
<revhistory>
<!-- Put document revisions here, newest first. -->
<revision>
<revnumber>1.0.0</revnumber>
<date>2016-03-17</date>
<authorinitials>hv</authorinitials>
<revremark>Initial revision</revremark>
</revision>
</revhistory>
</partinfo>
<title>CEC API</title>
<chapter id="cec-api">
<title>CEC: Consumer Electronics Control</title>
<section id="cec-intro">
<title>Introduction</title>
<para>
Note: this documents the proposed CEC API. This API is not yet finalized and
is currently only available as a staging kernel module.
</para>
<para>HDMI connectors provide a single pin for use by the Consumer Electronics
Control protocol. This protocol allows different devices connected by an HDMI cable
to communicate. The protocol for CEC version 1.4 is defined in supplements 1 (CEC)
and 2 (HEAC or HDMI Ethernet and Audio Return Channel) of the HDMI 1.4a
(<xref linkend="hdmi" />) specification and the extensions added to CEC version 2.0
are defined in chapter 11 of the HDMI 2.0 (<xref linkend="hdmi2" />) specification.
</para>
<para>The bitrate is very slow (effectively no more than 36 bytes per second) and
is based on the ancient AV.link protocol used in old SCART connectors. The protocol
closely resembles a crazy Rube Goldberg contraption and is an unholy mix of low and
high level messages. Some messages, especially those part of the HEAC protocol layered
on top of CEC, need to be handled by the kernel, others can be handled either by the
kernel or by userspace.</para>
<para>In addition, CEC can be implemented in HDMI receivers, transmitters and in USB
devices that have an HDMI input and an HDMI output and that control just the CEC pin.</para>
<para>Drivers that support CEC will create a CEC device node (/dev/cecX)
to give userspace access to the CEC adapter. The &CEC-ADAP-G-CAPS; ioctl will tell userspace
what it is allowed to do.</para>
</section>
</chapter>
<appendix id="cec-user-func">
<title>Function Reference</title>
<!-- Keep this alphabetically sorted. -->
&sub-cec-func-open;
&sub-cec-func-close;
&sub-cec-func-ioctl;
&sub-cec-func-poll;
<!-- All ioctls go here. -->
&sub-cec-ioc-adap-g-caps;
&sub-cec-ioc-adap-g-log-addrs;
&sub-cec-ioc-adap-g-phys-addr;
&sub-cec-ioc-dqevent;
&sub-cec-ioc-g-mode;
&sub-cec-ioc-receive;
</appendix>
Documentation/DocBook/media/v4l/cec-func-close.xml 0 → 100644
View file @ c7169ad5
<refentry id="cec-func-close">
<refmeta>
<refentrytitle>cec close()</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>cec-close</refname>
<refpurpose>Close a cec device</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcsynopsisinfo>#include &lt;unistd.h&gt;</funcsynopsisinfo>
<funcprototype>
<funcdef>int <function>close</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>
Note: this documents the proposed CEC API. This API is not yet finalized and
is currently only available as a staging kernel module.
</para>
<para>Closes the cec device. Resources associated with the file descriptor
are freed. The device configuration remain unchanged.</para>
</refsect1>
<refsect1>
<title>Return Value</title>
<para><function>close</function> returns 0 on success. On error, -1 is
returned, and <varname>errno</varname> is set appropriately. Possible error
codes are:</para>
<variablelist>
<varlistentry>
<term><errorcode>EBADF</errorcode></term>
<listitem>
<para><parameter>fd</parameter> is not a valid open file descriptor.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
Documentation/DocBook/media/v4l/cec-func-ioctl.xml 0 → 100644
View file @ c7169ad5
<refentry id="cec-func-ioctl">
<refmeta>
<refentrytitle>cec ioctl()</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>cec-ioctl</refname>
<refpurpose>Control a cec device</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcsynopsisinfo>#include &lt;sys/ioctl.h&gt;</funcsynopsisinfo>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>void *<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>CEC ioctl request code as defined in the cec.h header file,
for example CEC_ADAP_G_CAPS.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para>Pointer to a request-specific structure.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>
Note: this documents the proposed CEC API. This API is not yet finalized and
is currently only available as a staging kernel module.
</para>
<para>The <function>ioctl()</function> function manipulates cec device
parameters. The argument <parameter>fd</parameter> must be an open file
descriptor.</para>
<para>The ioctl <parameter>request</parameter> code specifies the cec
function to be called. It has encoded in it whether the argument is an
input, output or read/write parameter, and the size of the argument
<parameter>argp</parameter> in bytes.</para>
<para>Macros and structures definitions specifying cec ioctl requests and
their parameters are located in the cec.h header file. All cec ioctl
requests, their respective function and parameters are specified in
<xref linkend="cec-user-func" />.</para>
</refsect1>
<refsect1>
&return-value;
<para>Request-specific error codes are listed in the
individual requests descriptions.</para>
<para>When an ioctl that takes an output or read/write parameter fails,
the parameter remains unmodified.</para>
</refsect1>
</refentry>
Documentation/DocBook/media/v4l/cec-func-open.xml 0 → 100644
View file @ c7169ad5
<refentry id="cec-func-open">
<refmeta>
<refentrytitle>cec open()</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>cec-open</refname>
<refpurpose>Open a cec device</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcsynopsisinfo>#include &lt;fcntl.h&gt;</funcsynopsisinfo>
<funcprototype>
<funcdef>int <function>open</function></funcdef>
<paramdef>const char *<parameter>device_name</parameter></paramdef>
<paramdef>int <parameter>flags</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>device_name</parameter></term>
<listitem>
<para>Device to be opened.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>flags</parameter></term>
<listitem>
<para>Open flags. Access mode must be <constant>O_RDWR</constant>.
</para>
<para>When the <constant>O_NONBLOCK</constant> flag is
given, the &CEC-RECEIVE; ioctl will return &EAGAIN; when no message is
available, and the &CEC-TRANSMIT;, &CEC-ADAP-S-PHYS-ADDR; and
&CEC-ADAP-S-LOG-ADDRS; ioctls all act in non-blocking mode.</para>
<para>Other flags have no effect.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>
Note: this documents the proposed CEC API. This API is not yet finalized and
is currently only available as a staging kernel module.
</para>
<para>To open a cec device applications call <function>open()</function>
with the desired device name. The function has no side effects; the device
configuration remain unchanged.</para>
<para>When the device is opened in read-only mode, attempts to modify its
configuration will result in an error, and <varname>errno</varname> will be
set to <errorcode>EBADF</errorcode>.</para>
</refsect1>
<refsect1>
<title>Return Value</title>
<para><function>open</function> returns the new file descriptor on success.
On error, -1 is returned, and <varname>errno</varname> is set appropriately.
Possible error codes include:</para>
<variablelist>
<varlistentry>
<term><errorcode>EACCES</errorcode></term>
<listitem>
<para>The requested access to the file is not allowed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EMFILE</errorcode></term>
<listitem>
<para>The process already has the maximum number of files open.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENFILE</errorcode></term>
<listitem>
<para>The system limit on the total number of open files has been
reached.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENOMEM</errorcode></term>
<listitem>
<para>Insufficient kernel memory was available.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENXIO</errorcode></term>
<listitem>
<para>No device corresponding to this device special file exists.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
Documentation/DocBook/media/v4l/cec-func-poll.xml 0 → 100644
View file @ c7169ad5
<refentry id="cec-func-poll">
<refmeta>
<refentrytitle>cec poll()</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>cec-poll</refname>
<refpurpose>Wait for some event on a file descriptor</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcsynopsisinfo>#include &lt;sys/poll.h&gt;</funcsynopsisinfo>
<funcprototype>
<funcdef>int <function>poll</function></funcdef>
<paramdef>struct pollfd *<parameter>ufds</parameter></paramdef>
<paramdef>unsigned int <parameter>nfds</parameter></paramdef>
<paramdef>int <parameter>timeout</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>
Note: this documents the proposed CEC API. This API is not yet finalized and
is currently only available as a staging kernel module.
</para>
<para>With the <function>poll()</function> function applications
can wait for CEC events.</para>
<para>On success <function>poll()</function> returns the number of
file descriptors that have been selected (that is, file descriptors
for which the <structfield>revents</structfield> field of the
respective <structname>pollfd</structname> structure is non-zero).
CEC devices set the <constant>POLLIN</constant> and
<constant>POLLRDNORM</constant> flags in the
<structfield>revents</structfield> field if there are messages in the
receive queue. If the transmit queue has room for new messages, the
<constant>POLLOUT</constant> and <constant>POLLWRNORM</constant>
flags are set. If there are events in the event queue, then the
<constant>POLLPRI</constant> flag is set.
When the function timed out it returns a value of zero, on
failure it returns <returnvalue>-1</returnvalue> and the
<varname>errno</varname> variable is set appropriately.
</para>
<para>For more details see the
<function>poll()</function> manual page.</para>
</refsect1>
<refsect1>
<title>Return Value</title>
<para>On success, <function>poll()</function> returns the number
structures which have non-zero <structfield>revents</structfield>
fields, or zero if the call timed out. On error
<returnvalue>-1</returnvalue> is returned, and the
<varname>errno</varname> variable is set appropriately:</para>
<variablelist>
<varlistentry>
<term><errorcode>EBADF</errorcode></term>
<listitem>
<para>One or more of the <parameter>ufds</parameter> members
specify an invalid file descriptor.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EFAULT</errorcode></term>
<listitem>
<para><parameter>ufds</parameter> references an inaccessible
memory area.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EINTR</errorcode></term>
<listitem>
<para>The call was interrupted by a signal.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The <parameter>nfds</parameter> argument is greater
than <constant>OPEN_MAX</constant>.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
Documentation/DocBook/media/v4l/cec-ioc-adap-g-caps.xml 0 → 100644
View file @ c7169ad5
<refentry id="cec-ioc-adap-g-caps">
<refmeta>
<refentrytitle>ioctl CEC_ADAP_G_CAPS</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>CEC_ADAP_G_CAPS</refname>
<refpurpose>Query device capabilities</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 cec_caps *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>File descriptor returned by
<link linkend='cec-func-open'><function>open()</function></link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>CEC_ADAP_G_CAPS</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>
Note: this documents the proposed CEC API. This API is not yet finalized and
is currently only available as a staging kernel module.
</para>
<para>All cec devices must support the <constant>CEC_ADAP_G_CAPS</constant>
ioctl. To query device information, applications call the ioctl with a
pointer to a &cec-caps;. The driver fills the structure and returns
the information to the application.
The ioctl never fails.</para>
<table pgwide="1" frame="none" id="cec-caps">
<title>struct <structname>cec_caps</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>char</entry>
<entry><structfield>driver[32]</structfield></entry>
<entry>The name of the cec adapter driver.</entry>
</row>
<row>
<entry>char</entry>
<entry><structfield>name[32]</structfield></entry>
<entry>The name of this CEC adapter. The combination <structfield>driver</structfield>
and <structfield>name</structfield> must be unique.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>capabilities</structfield></entry>
<entry>The capabilities of the CEC adapter, see <xref
linkend="cec-capabilities" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>version</structfield></entry>
<entry>CEC Framework API version, formatted with the
<constant>KERNEL_VERSION()</constant> macro.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="cec-capabilities">
<title>CEC Capabilities Flags</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>CEC_CAP_PHYS_ADDR</constant></entry>
<entry>0x00000001</entry>
<entry>Userspace has to configure the physical address by
calling &CEC-ADAP-S-PHYS-ADDR;. If this capability isn't set,
then setting the physical address is handled by the kernel
whenever the EDID is set (for an HDMI receiver) or read (for
an HDMI transmitter).</entry>
</row>
<row>
<entry><constant>CEC_CAP_LOG_ADDRS</constant></entry>
<entry>0x00000002</entry>
<entry>Userspace has to configure the logical addresses by
calling &CEC-ADAP-S-LOG-ADDRS;. If this capability isn't set,
then the kernel will have configured this.</entry>
</row>
<row>
<entry><constant>CEC_CAP_TRANSMIT</constant></entry>
<entry>0x00000004</entry>
<entry>Userspace can transmit CEC messages by calling &CEC-TRANSMIT;. This
implies that userspace can be a follower as well, since being able to
transmit messages is a prerequisite of becoming a follower. If this
capability isn't set, then the kernel will handle all CEC transmits
and process all CEC messages it receives.
</entry>
</row>
<row>
<entry><constant>CEC_CAP_PASSTHROUGH</constant></entry>
<entry>0x00000008</entry>
<entry>Userspace can use the passthrough mode by
calling &CEC-S-MODE;.</entry>
</row>
<row>
<entry><constant>CEC_CAP_RC</constant></entry>
<entry>0x00000010</entry>
<entry>This adapter supports the remote control protocol.</entry>
</row>
<row>
<entry><constant>CEC_CAP_MONITOR_ALL</constant></entry>
<entry>0x00000020</entry>
<entry>The CEC hardware can monitor all messages, not just directed and
broadcast messages.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
</refsect1>
</refentry>
Documentation/DocBook/media/v4l/cec-ioc-adap-g-log-addrs.xml 0 → 100644
View file @ c7169ad5
This diff is collapsed.
Documentation/DocBook/media/v4l/cec-ioc-adap-g-phys-addr.xml 0 → 100644
View file @ c7169ad5
<refentry id="cec-ioc-adap-g-phys-addr">
<refmeta>
<refentrytitle>ioctl CEC_ADAP_G_PHYS_ADDR, CEC_ADAP_S_PHYS_ADDR</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>CEC_ADAP_G_PHYS_ADDR</refname>
<refname>CEC_ADAP_S_PHYS_ADDR</refname>
<refpurpose>Get or set the physical address</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>__u16 *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>File descriptor returned by
<link linkend='cec-func-open'><function>open()</function></link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>CEC_ADAP_G_PHYS_ADDR, CEC_ADAP_S_PHYS_ADDR</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>
Note: this documents the proposed CEC API. This API is not yet finalized and
is currently only available as a staging kernel module.
</para>
<para>To query the current physical address applications call the
<constant>CEC_ADAP_G_PHYS_ADDR</constant> ioctl with a pointer to an __u16
where the driver stores the physical address.</para>
<para>To set a new physical address applications store the physical address in
an __u16 and call the <constant>CEC_ADAP_S_PHYS_ADDR</constant> ioctl with a
pointer to this integer. <constant>CEC_ADAP_S_PHYS_ADDR</constant> is only
available if <constant>CEC_CAP_PHYS_ADDR</constant> is set (&ENOTTY; will be returned
otherwise). <constant>CEC_ADAP_S_PHYS_ADDR</constant>
can only be called by a file handle in initiator mode (see &CEC-S-MODE;), if not
&EBUSY; will be returned.</para>
<para>The physical address is a 16-bit number where each group of 4 bits
represent a digit of the physical address a.b.c.d where the most significant
4 bits represent 'a'. The CEC root device (usually the TV) has address 0.0.0.0.
Every device that is hooked up to an input of the TV has address a.0.0.0 (where
'a' is &ge; 1), devices hooked up to those in turn have addresses a.b.0.0, etc.
So a topology of up to 5 devices deep is supported. The physical address a
device shall use is stored in the EDID of the sink.</para>
<para>For example, the EDID for each HDMI input of the TV will have a different
physical address of the form a.0.0.0 that the sources will read out and use as
their physical address.</para>
</refsect1>
<refsect1>
&return-value;
</refsect1>
</refentry>
Documentation/DocBook/media/v4l/cec-ioc-dqevent.xml 0 → 100644
View file @ c7169ad5
<refentry id="cec-ioc-g-event">
<refmeta>
<refentrytitle>ioctl CEC_DQEVENT</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>CEC_DQEVENT</refname>
<refpurpose>Dequeue a CEC event</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 cec_event *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>File descriptor returned by
<link linkend='cec-func-open'><function>open()</function></link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>CEC_DQEVENT</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>
Note: this documents the proposed CEC API. This API is not yet finalized and
is currently only available as a staging kernel module.
</para>
<para>CEC devices can send asynchronous events. These can be retrieved by calling
the <constant>CEC_DQEVENT</constant> ioctl. If the file descriptor is in non-blocking
mode and no event is pending, then it will return -1 and set errno to the &EAGAIN;.</para>
<para>The internal event queues are per-filehandle and per-event type. If there is
no more room in a queue then the last event is overwritten with the new one. This
means that intermediate results can be thrown away but that the latest event is always
available. This also means that is it possible to read two successive events that have
the same value (e.g. two CEC_EVENT_STATE_CHANGE events with the same state). In that
case the intermediate state changes were lost but it is guaranteed that the state
did change in between the two events.</para>
<table pgwide="1" frame="none" id="cec-event-state-change">
<title>struct <structname>cec_event_state_change</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u16</entry>
<entry><structfield>phys_addr</structfield></entry>
<entry>The current physical address.</entry>
</row>
<row>
<entry>__u16</entry>
<entry><structfield>log_addr_mask</structfield></entry>
<entry>The current set of claimed logical addresses.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="cec-event-lost-msgs">
<title>struct <structname>cec_event_lost_msgs</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>lost_msgs</structfield></entry>
<entry>Set to the number of lost messages since the filehandle
was opened or since the last time this event was dequeued for
this filehandle. The messages lost are the oldest messages. So
when a new message arrives and there is no more room, then the
oldest message is discarded to make room for the new one. The
internal size of the message queue guarantees that all messages
received in the last two seconds will be stored. Since messages
should be replied to within a second according to the CEC
specification, this is more than enough.
</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="cec-event">
<title>struct <structname>cec_event</structname></title>
<tgroup cols="4">
&cs-str;
<tbody valign="top">
<row>
<entry>__u64</entry>
<entry><structfield>ts</structfield></entry>
<entry>Timestamp of the event in ns.</entry>
<entry></entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>event</structfield></entry>
<entry>The CEC event type, see <xref linkend="cec-events" />.</entry>
<entry></entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>Event flags, see <xref linkend="cec-event-flags" />.</entry>
<entry></entry>
</row>
<row>
<entry>union</entry>
<entry>(anonymous)</entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry></entry>
<entry>struct cec_event_state_change</entry>
<entry><structfield>state_change</structfield></entry>
<entry>The new adapter state as sent by the <constant>CEC_EVENT_STATE_CHANGE</constant>
event.</entry>
</row>
<row>
<entry></entry>
<entry>struct cec_event_lost_msgs</entry>
<entry><structfield>lost_msgs</structfield></entry>
<entry>The number of lost messages as sent by the <constant>CEC_EVENT_LOST_MSGS</constant>
event.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="cec-events">
<title>CEC Events Types</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>CEC_EVENT_STATE_CHANGE</constant></entry>
<entry>1</entry>
<entry>Generated when the CEC Adapter's state changes. When open() is
called an initial event will be generated for that filehandle with the
CEC Adapter's state at that time.
</entry>
</row>
<row>
<entry><constant>CEC_EVENT_LOST_MSGS</constant></entry>
<entry>2</entry>
<entry>Generated if one or more CEC messages were lost because the
application didn't dequeue CEC messages fast enough.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="cec-event-flags">
<title>CEC Event Flags</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>CEC_EVENT_FL_INITIAL_VALUE</constant></entry>
<entry>1</entry>
<entry>Set for the initial events that are generated when the device is
opened. See the table above for which events do this. This allows
applications to learn the initial state of the CEC adapter at open()
time.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
</refsect1>
</refentry>
Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml 0 → 100644
View file @ c7169ad5
This diff is collapsed.
Documentation/DocBook/media/v4l/cec-ioc-receive.xml 0 → 100644
View file @ c7169ad5
This diff is collapsed.
Documentation/DocBook/media_api.tmpl
View file @ c7169ad5
...@@ -75,7 +75,7 @@ ...@@ -75,7 +75,7 @@
</mediaobject> </mediaobject>
</figure> </figure>
<para>The media infrastructure API was designed to control such <para>The media infrastructure API was designed to control such
devices. It is divided into four parts.</para> devices. It is divided into five parts.</para>
<para>The first part covers radio, video capture and output, <para>The first part covers radio, video capture and output,
cameras, analog TV devices and codecs.</para> cameras, analog TV devices and codecs.</para>
<para>The second part covers the <para>The second part covers the
...@@ -87,6 +87,7 @@ ...@@ -87,6 +87,7 @@
<xref linkend="fe-delivery-system-t" />.</para> <xref linkend="fe-delivery-system-t" />.</para>
<para>The third part covers the Remote Controller API.</para> <para>The third part covers the Remote Controller API.</para>
<para>The fourth part covers the Media Controller API.</para> <para>The fourth part covers the Media Controller API.</para>
<para>The fifth part covers the CEC (Consumer Electronics Control) API.</para>
<para>It should also be noted that a media device may also have audio <para>It should also be noted that a media device may also have audio
components, like mixers, PCM capture, PCM playback, etc, which components, like mixers, PCM capture, PCM playback, etc, which
are controlled via ALSA API.</para> are controlled via ALSA API.</para>
...@@ -107,6 +108,9 @@ ...@@ -107,6 +108,9 @@
<part id="media_common"> <part id="media_common">
&sub-media-controller; &sub-media-controller;
</part> </part>
<part id="cec">
&sub-cec-api;
</part>
<chapter id="gen_errors"> <chapter id="gen_errors">
&sub-gen-errors; &sub-gen-errors;
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7