diff options
Diffstat (limited to 'Documentation/media/uapi/cec')
| -rw-r--r-- | Documentation/media/uapi/cec/cec-api.rst | 43 | ||||
| -rw-r--r-- | Documentation/media/uapi/cec/cec-func-close.rst | 49 | ||||
| -rw-r--r-- | Documentation/media/uapi/cec/cec-func-ioctl.rst | 68 | ||||
| -rw-r--r-- | Documentation/media/uapi/cec/cec-func-open.rst | 80 | ||||
| -rw-r--r-- | Documentation/media/uapi/cec/cec-func-poll.rst | 70 | ||||
| -rw-r--r-- | Documentation/media/uapi/cec/cec-funcs.rst | 21 | ||||
| -rw-r--r-- | Documentation/media/uapi/cec/cec-header.rst | 10 | ||||
| -rw-r--r-- | Documentation/media/uapi/cec/cec-intro.rst | 31 | ||||
| -rw-r--r-- | Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst | 165 | ||||
| -rw-r--r-- | Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst | 455 | ||||
| -rw-r--r-- | Documentation/media/uapi/cec/cec-ioc-adap-g-phys-addr.rst | 82 | ||||
| -rw-r--r-- | Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 235 | ||||
| -rw-r--r-- | Documentation/media/uapi/cec/cec-ioc-g-mode.rst | 295 | ||||
| -rw-r--r-- | Documentation/media/uapi/cec/cec-ioc-receive.rst | 360 |
14 files changed, 1964 insertions, 0 deletions
diff --git a/Documentation/media/uapi/cec/cec-api.rst b/Documentation/media/uapi/cec/cec-api.rst new file mode 100644 index 000000000..bb0187099 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-api.rst @@ -0,0 +1,43 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. include:: <isonum.txt> + +.. _cec: + +######################################### +Part V - Consumer Electronics Control API +######################################### + +This part describes the CEC: Consumer Electronics Control + +.. class:: toc-title + + Table of Contents + +.. toctree:: + :maxdepth: 5 + :numbered: + + cec-intro + cec-funcs + cec-header + + +********************** +Revision and Copyright +********************** +Authors: + +- Verkuil, Hans <hans.verkuil@cisco.com> + + - Initial version. + +**Copyright** |copy| 2016 : Hans Verkuil + +**************** +Revision History +**************** + +:revision: 1.0.0 / 2016-03-17 (*hv*) + +Initial revision diff --git a/Documentation/media/uapi/cec/cec-func-close.rst b/Documentation/media/uapi/cec/cec-func-close.rst new file mode 100644 index 000000000..bb94e4358 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-func-close.rst @@ -0,0 +1,49 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _cec-func-close: + +*********** +cec close() +*********** + +Name +==== + +cec-close - Close a cec device + + +Synopsis +======== + +.. code-block:: c + + #include <unistd.h> + + +.. cpp:function:: int close( int fd ) + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() <func-open>`. + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +Closes the cec device. Resources associated with the file descriptor are +freed. The device configuration remain unchanged. + + +Return Value +============ + +:c:func:`close()` returns 0 on success. On error, -1 is returned, and +``errno`` is set appropriately. Possible error codes are: + +``EBADF`` + ``fd`` is not a valid open file descriptor. diff --git a/Documentation/media/uapi/cec/cec-func-ioctl.rst b/Documentation/media/uapi/cec/cec-func-ioctl.rst new file mode 100644 index 000000000..d0279e6d2 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-func-ioctl.rst @@ -0,0 +1,68 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _cec-func-ioctl: + +*********** +cec ioctl() +*********** + +Name +==== + +cec-ioctl - Control a cec device + +Synopsis +======== + +.. code-block:: c + + #include <sys/ioctl.h> + + +.. cpp:function:: int ioctl( int fd, int request, void *argp ) + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() <func-open>`. + +``request`` + CEC ioctl request code as defined in the cec.h header file, for + example :ref:`CEC_ADAP_G_CAPS`. + +``argp`` + Pointer to a request-specific structure. + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +The :c:func:`ioctl()` function manipulates cec device parameters. The +argument ``fd`` must be an open file descriptor. + +The ioctl ``request`` 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 ``argp`` in bytes. + +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 +:ref:`cec-user-func`. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes <gen-errors>` chapter. + +Request-specific error codes are listed in the individual requests +descriptions. + +When an ioctl that takes an output or read/write parameter fails, the +parameter remains unmodified. diff --git a/Documentation/media/uapi/cec/cec-func-open.rst b/Documentation/media/uapi/cec/cec-func-open.rst new file mode 100644 index 000000000..38fd7e0cf --- /dev/null +++ b/Documentation/media/uapi/cec/cec-func-open.rst @@ -0,0 +1,80 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _cec-func-open: + +********** +cec open() +********** + +Name +==== + +cec-open - Open a cec device + +Synopsis +======== + +.. code-block:: c + + #include <fcntl.h> + + +.. cpp:function:: int open( const char *device_name, int flags ) + + +Arguments +========= + +``device_name`` + Device to be opened. + +``flags`` + Open flags. Access mode must be ``O_RDWR``. + + When the ``O_NONBLOCK`` flag is given, the + :ref:`CEC_RECEIVE <CEC_RECEIVE>` and :ref:`CEC_DQEVENT <CEC_DQEVENT>` ioctls + will return the ``EAGAIN`` error code when no message or event is available, and + ioctls :ref:`CEC_TRANSMIT <CEC_TRANSMIT>`, + :ref:`CEC_ADAP_S_PHYS_ADDR <CEC_ADAP_S_PHYS_ADDR>` and + :ref:`CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>` + all return 0. + + Other flags have no effect. + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +To open a cec device applications call :c:func:`open()` with the +desired device name. The function has no side effects; the device +configuration remain unchanged. + +When the device is opened in read-only mode, attempts to modify its +configuration will result in an error, and ``errno`` will be set to +EBADF. + + +Return Value +============ + +:c:func:`open()` returns the new file descriptor on success. On error, +-1 is returned, and ``errno`` is set appropriately. Possible error codes +include: + +``EACCES`` + The requested access to the file is not allowed. + +``EMFILE`` + The process already has the maximum number of files open. + +``ENFILE`` + The system limit on the total number of open files has been reached. + +``ENOMEM`` + Insufficient kernel memory was available. + +``ENXIO`` + No device corresponding to this device special file exists. diff --git a/Documentation/media/uapi/cec/cec-func-poll.rst b/Documentation/media/uapi/cec/cec-func-poll.rst new file mode 100644 index 000000000..fcab65f6d --- /dev/null +++ b/Documentation/media/uapi/cec/cec-func-poll.rst @@ -0,0 +1,70 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _cec-func-poll: + +********** +cec poll() +********** + +Name +==== + +cec-poll - Wait for some event on a file descriptor + + +Synopsis +======== + +.. code-block:: c + + #include <sys/poll.h> + + +.. cpp:function:: int poll( struct pollfd *ufds, unsigned int nfds, int timeout ) + +Arguments +========= + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +With the :c:func:`poll()` function applications can wait for CEC +events. + +On success :c:func:`poll()` returns the number of file descriptors +that have been selected (that is, file descriptors for which the +``revents`` field of the respective :c:type:`struct pollfd` structure +is non-zero). CEC devices set the ``POLLIN`` and ``POLLRDNORM`` flags in +the ``revents`` field if there are messages in the receive queue. If the +transmit queue has room for new messages, the ``POLLOUT`` and +``POLLWRNORM`` flags are set. If there are events in the event queue, +then the ``POLLPRI`` flag is set. When the function timed out it returns +a value of zero, on failure it returns -1 and the ``errno`` variable is +set appropriately. + +For more details see the :c:func:`poll()` manual page. + + +Return Value +============ + +On success, :c:func:`poll()` returns the number structures which have +non-zero ``revents`` fields, or zero if the call timed out. On error -1 +is returned, and the ``errno`` variable is set appropriately: + +``EBADF`` + One or more of the ``ufds`` members specify an invalid file + descriptor. + +``EFAULT`` + ``ufds`` references an inaccessible memory area. + +``EINTR`` + The call was interrupted by a signal. + +``EINVAL`` + The ``nfds`` argument is greater than ``OPEN_MAX``. diff --git a/Documentation/media/uapi/cec/cec-funcs.rst b/Documentation/media/uapi/cec/cec-funcs.rst new file mode 100644 index 000000000..5b7630f2e --- /dev/null +++ b/Documentation/media/uapi/cec/cec-funcs.rst @@ -0,0 +1,21 @@ +.. _cec-user-func: + +****************** +Function Reference +****************** + + +.. toctree:: + :maxdepth: 1 + :numbered: + + cec-func-open + cec-func-close + cec-func-ioctl + cec-func-poll + cec-ioc-adap-g-caps + cec-ioc-adap-g-log-addrs + cec-ioc-adap-g-phys-addr + cec-ioc-dqevent + cec-ioc-g-mode + cec-ioc-receive diff --git a/Documentation/media/uapi/cec/cec-header.rst b/Documentation/media/uapi/cec/cec-header.rst new file mode 100644 index 000000000..d5a9a2828 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-header.rst @@ -0,0 +1,10 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _cec_header: + +*************** +CEC Header File +*************** + +.. kernel-include:: $BUILDDIR/cec.h.rst + diff --git a/Documentation/media/uapi/cec/cec-intro.rst b/Documentation/media/uapi/cec/cec-intro.rst new file mode 100644 index 000000000..afa76f26f --- /dev/null +++ b/Documentation/media/uapi/cec/cec-intro.rst @@ -0,0 +1,31 @@ +.. _cec-intro: + +Introduction +============ + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +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 (:ref:`hdmi`) specification and the +extensions added to CEC version 2.0 are defined in chapter 11 of the +HDMI 2.0 (:ref:`hdmi2`) specification. + +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. + +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. + +Drivers that support CEC will create a CEC device node (/dev/cecX) to +give userspace access to the CEC adapter. The +:ref:`CEC_ADAP_G_CAPS` ioctl will tell userspace what it is allowed to do. diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst new file mode 100644 index 000000000..eaedc6318 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst @@ -0,0 +1,165 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CEC_ADAP_G_CAPS: + +********************* +ioctl CEC_ADAP_G_CAPS +********************* + +Name +==== + +CEC_ADAP_G_CAPS - Query device capabilities + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct cec_caps *argp ) + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() <cec-func-open>`. + +``request`` + CEC_ADAP_G_CAPS + +``argp`` + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +All cec devices must support :ref:`ioctl CEC_ADAP_G_CAPS <CEC_ADAP_G_CAPS>`. To query +device information, applications call the ioctl with a pointer to a +struct :ref:`cec_caps <cec-caps>`. The driver fills the structure and +returns the information to the application. The ioctl never fails. + + +.. _cec-caps: + +.. flat-table:: struct cec_caps + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 16 + + + - .. row 1 + + - char + + - ``driver[32]`` + + - The name of the cec adapter driver. + + - .. row 2 + + - char + + - ``name[32]`` + + - The name of this CEC adapter. The combination ``driver`` and + ``name`` must be unique. + + - .. row 3 + + - __u32 + + - ``capabilities`` + + - The capabilities of the CEC adapter, see + :ref:`cec-capabilities`. + + - .. row 4 + + - __u32 + + - ``version`` + + - CEC Framework API version, formatted with the ``KERNEL_VERSION()`` + macro. + + + +.. _cec-capabilities: + +.. flat-table:: CEC Capabilities Flags + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 8 + + + - .. _`CEC-CAP-PHYS-ADDR`: + + - ``CEC_CAP_PHYS_ADDR`` + + - 0x00000001 + + - Userspace has to configure the physical address by calling + :ref:`ioctl CEC_ADAP_S_PHYS_ADDR <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). + + - .. _`CEC-CAP-LOG-ADDRS`: + + - ``CEC_CAP_LOG_ADDRS`` + + - 0x00000002 + + - Userspace has to configure the logical addresses by calling + :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>`. If + this capability isn't set, then the kernel will have configured + this. + + - .. _`CEC-CAP-TRANSMIT`: + + - ``CEC_CAP_TRANSMIT`` + + - 0x00000004 + + - Userspace can transmit CEC messages by calling + :ref:`ioctl CEC_TRANSMIT <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. + + - .. _`CEC-CAP-PASSTHROUGH`: + + - ``CEC_CAP_PASSTHROUGH`` + + - 0x00000008 + + - Userspace can use the passthrough mode by calling + :ref:`ioctl CEC_S_MODE <CEC_S_MODE>`. + + - .. _`CEC-CAP-RC`: + + - ``CEC_CAP_RC`` + + - 0x00000010 + + - This adapter supports the remote control protocol. + + - .. _`CEC-CAP-MONITOR-ALL`: + + - ``CEC_CAP_MONITOR_ALL`` + + - 0x00000020 + + - The CEC hardware can monitor all messages, not just directed and + broadcast messages. + + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst new file mode 100644 index 000000000..201d48399 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst @@ -0,0 +1,455 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CEC_ADAP_LOG_ADDRS: +.. _CEC_ADAP_G_LOG_ADDRS: +.. _CEC_ADAP_S_LOG_ADDRS: + +**************************************************** +ioctls CEC_ADAP_G_LOG_ADDRS and CEC_ADAP_S_LOG_ADDRS +**************************************************** + +Name +==== + +CEC_ADAP_G_LOG_ADDRS, CEC_ADAP_S_LOG_ADDRS - Get or set the logical addresses + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct cec_log_addrs *argp ) + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() <cec-func-open>`. + +``request`` + CEC_ADAP_G_LOG_ADDRS, CEC_ADAP_S_LOG_ADDRS + +``argp`` + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +To query the current CEC logical addresses, applications call +:ref:`ioctl CEC_ADAP_G_LOG_ADDRS <CEC_ADAP_G_LOG_ADDRS>` with a pointer to a +:c:type:`struct cec_log_addrs` where the driver stores the logical addresses. + +To set new logical addresses, applications fill in +:c:type:`struct cec_log_addrs` and call :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>` +with a pointer to this struct. The :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>` +is only available if ``CEC_CAP_LOG_ADDRS`` is set (the ``ENOTTY`` error code is +returned otherwise). The :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>` +can only be called by a file descriptor in initiator mode (see :ref:`CEC_S_MODE`), if not +the ``EBUSY`` error code will be returned. + +To clear existing logical addresses set ``num_log_addrs`` to 0. All other fields +will be ignored in that case. The adapter will go to the unconfigured state. + +If the physical address is valid (see :ref:`ioctl CEC_ADAP_S_PHYS_ADDR <CEC_ADAP_S_PHYS_ADDR>`), +then this ioctl will block until all requested logical +addresses have been claimed. If the file descriptor is in non-blocking mode then it will +not wait for the logical addresses to be claimed, instead it just returns 0. + +A :ref:`CEC_EVENT_STATE_CHANGE <CEC-EVENT-STATE-CHANGE>` event is sent when the +logical addresses are claimed or cleared. + +Attempting to call :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>` when +logical address types are already defined will return with error ``EBUSY``. + + +.. _cec-log-addrs: + +.. flat-table:: struct cec_log_addrs + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 16 + + + - .. row 1 + + - __u8 + + - ``log_addr[CEC_MAX_LOG_ADDRS]`` + + - The actual logical addresses that were claimed. This is set by the + driver. If no logical address could be claimed, then it is set to + ``CEC_LOG_ADDR_INVALID``. If this adapter is Unregistered, then + ``log_addr[0]`` is set to 0xf and all others to + ``CEC_LOG_ADDR_INVALID``. + + - .. row 2 + + - __u16 + + - ``log_addr_mask`` + + - The bitmask of all logical addresses this adapter has claimed. If + this adapter is Unregistered then ``log_addr_mask`` sets bit 15 + and clears all other bits. If this adapter is not configured at + all, then ``log_addr_mask`` is set to 0. Set by the driver. + + - .. row 3 + + - __u8 + + - ``cec_version`` + + - The CEC version that this adapter shall use. See + :ref:`cec-versions`. Used to implement the + ``CEC_MSG_CEC_VERSION`` and ``CEC_MSG_REPORT_FEATURES`` messages. + Note that :ref:`CEC_OP_CEC_VERSION_1_3A <CEC-OP-CEC-VERSION-1-3A>` is not allowed by the CEC + framework. + + - .. row 4 + + - __u8 + + - ``num_log_addrs`` + + - Number of logical addresses to set up. Must be ≤ + ``available_log_addrs`` as returned by + :ref:`CEC_ADAP_G_CAPS`. All arrays in + this structure are only filled up to index + ``available_log_addrs``-1. The remaining array elements will be + ignored. Note that the CEC 2.0 standard allows for a maximum of 2 + logical addresses, although some hardware has support for more. + ``CEC_MAX_LOG_ADDRS`` is 4. The driver will return the actual + number of logical addresses it could claim, which may be less than + what was requested. If this field is set to 0, then the CEC + adapter shall clear all claimed logical addresses and all other + fields will be ignored. + + - .. row 5 + + - __u32 + + - ``vendor_id`` + + - The vendor ID is a 24-bit number that identifies the specific + vendor or entity. Based on this ID vendor specific commands may be + defined. If you do not want a vendor ID then set it to + ``CEC_VENDOR_ID_NONE``. + + - .. row 6 + + - __u32 + + - ``flags`` + + - Flags. See :ref:`cec-log-addrs-flags` for a list of available flags. + + - .. row 7 + + - char + + - ``osd_name[15]`` + + - The On-Screen Display name as is returned by the + ``CEC_MSG_SET_OSD_NAME`` message. + + - .. row 8 + + - __u8 + + - ``primary_device_type[CEC_MAX_LOG_ADDRS]`` + + - Primary device type for each logical address. See + :ref:`cec-prim-dev-types` for possible types. + + - .. row 9 + + - __u8 + + - ``log_addr_type[CEC_MAX_LOG_ADDRS]`` + + - Logical address types. See :ref:`cec-log-addr-types` for + possible types. The driver will update this with the actual + logical address type that it claimed (e.g. it may have to fallback + to :ref:`CEC_LOG_ADDR_TYPE_UNREGISTERED <CEC-LOG-ADDR-TYPE-UNREGISTERED>`). + + - .. row 10 + + - __u8 + + - ``all_device_types[CEC_MAX_LOG_ADDRS]`` + + - CEC 2.0 specific: the bit mask of all device types. See + :ref:`cec-all-dev-types-flags`. It is used in the CEC 2.0 + ``CEC_MSG_REPORT_FEATURES`` message. For CEC 1.4 you can either leave + this field to 0, or fill it in according to the CEC 2.0 guidelines to + give the CEC framework more information about the device type, even + though the framework won't use it directly in the CEC message. + + - .. row 11 + + - __u8 + + - ``features[CEC_MAX_LOG_ADDRS][12]`` + + - Features for each logical address. It is used in the CEC 2.0 + ``CEC_MSG_REPORT_FEATURES`` message. The 12 bytes include both the + RC Profile and the Device Features. For CEC 1.4 you can either leave + this field to all 0, or fill it in according to the CEC 2.0 guidelines to + give the CEC framework more information about the device type, even + though the framework won't use it directly in the CEC message. + +.. _cec-log-addrs-flags: + +.. flat-table:: Flags for struct cec_log_addrs + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 4 + + + - .. _`CEC-LOG-ADDRS-FL-ALLOW-UNREG-FALLBACK`: + + - ``CEC_LOG_ADDRS_FL_ALLOW_UNREG_FALLBACK`` + + - 1 + + - By default if no logical address of the requested type can be claimed, then + it will go back to the unconfigured state. If this flag is set, then it will + fallback to the Unregistered logical address. Note that if the Unregistered + logical address was explicitly requested, then this flag has no effect. + +.. _cec-versions: + +.. flat-table:: CEC Versions + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 4 + + + - .. _`CEC-OP-CEC-VERSION-1-3A`: + + - ``CEC_OP_CEC_VERSION_1_3A`` + + - 4 + + - CEC version according to the HDMI 1.3a standard. + + - .. _`CEC-OP-CEC-VERSION-1-4B`: + + - ``CEC_OP_CEC_VERSION_1_4B`` + + - 5 + + - CEC version according to the HDMI 1.4b standard. + + - .. _`CEC-OP-CEC-VERSION-2-0`: + + - ``CEC_OP_CEC_VERSION_2_0`` + + - 6 + + - CEC version according to the HDMI 2.0 standard. + + + +.. _cec-prim-dev-types: + +.. flat-table:: CEC Primary Device Types + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 4 + + + - .. _`CEC-OP-PRIM-DEVTYPE-TV`: + + - ``CEC_OP_PRIM_DEVTYPE_TV`` + + - 0 + + - Use for a TV. + + - .. _`CEC-OP-PRIM-DEVTYPE-RECORD`: + + - ``CEC_OP_PRIM_DEVTYPE_RECORD`` + + - 1 + + - Use for a recording device. + + - .. _`CEC-OP-PRIM-DEVTYPE-TUNER`: + + - ``CEC_OP_PRIM_DEVTYPE_TUNER`` + + - 3 + + - Use for a device with a tuner. + + - .. _`CEC-OP-PRIM-DEVTYPE-PLAYBACK`: + + - ``CEC_OP_PRIM_DEVTYPE_PLAYBACK`` + + - 4 + + - Use for a playback device. + + - .. _`CEC-OP-PRIM-DEVTYPE-AUDIOSYSTEM`: + + - ``CEC_OP_PRIM_DEVTYPE_AUDIOSYSTEM`` + + - 5 + + - Use for an audio system (e.g. an audio/video receiver). + + - .. _`CEC-OP-PRIM-DEVTYPE-SWITCH`: + + - ``CEC_OP_PRIM_DEVTYPE_SWITCH`` + + - 6 + + - Use for a CEC switch. + + - .. _`CEC-OP-PRIM-DEVTYPE-VIDEOPROC`: + + - ``CEC_OP_PRIM_DEVTYPE_VIDEOPROC`` + + - 7 + + - Use for a video processor device. + + + +.. _cec-log-addr-types: + +.. flat-table:: CEC Logical Address Types + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 16 + + + - .. _`CEC-LOG-ADDR-TYPE-TV`: + + - ``CEC_LOG_ADDR_TYPE_TV`` + + - 0 + + - Use for a TV. + + - .. _`CEC-LOG-ADDR-TYPE-RECORD`: + + - ``CEC_LOG_ADDR_TYPE_RECORD`` + + - 1 + + - Use for a recording device. + + - .. _`CEC-LOG-ADDR-TYPE-TUNER`: + + - ``CEC_LOG_ADDR_TYPE_TUNER`` + + - 2 + + - Use for a tuner device. + + - .. _`CEC-LOG-ADDR-TYPE-PLAYBACK`: + + - ``CEC_LOG_ADDR_TYPE_PLAYBACK`` + + - 3 + + - Use for a playback device. + + - .. _`CEC-LOG-ADDR-TYPE-AUDIOSYSTEM`: + + - ``CEC_LOG_ADDR_TYPE_AUDIOSYSTEM`` + + - 4 + + - Use for an audio system device. + + - .. _`CEC-LOG-ADDR-TYPE-SPECIFIC`: + + - ``CEC_LOG_ADDR_TYPE_SPECIFIC`` + + - 5 + + - Use for a second TV or for a video processor device. + + - .. _`CEC-LOG-ADDR-TYPE-UNREGISTERED`: + + - ``CEC_LOG_ADDR_TYPE_UNREGISTERED`` + + - 6 + + - Use this if you just want to remain unregistered. Used for pure + CEC switches or CDC-only devices (CDC: Capability Discovery and + Control). + + + +.. _cec-all-dev-types-flags: + +.. flat-table:: CEC All Device Types Flags + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 4 + + + - .. _`CEC-OP-ALL-DEVTYPE-TV`: + + - ``CEC_OP_ALL_DEVTYPE_TV`` + + - 0x80 + + - This supports the TV type. + + - .. _`CEC-OP-ALL-DEVTYPE-RECORD`: + + - ``CEC_OP_ALL_DEVTYPE_RECORD`` + + - 0x40 + + - This supports the Recording type. + + - .. _`CEC-OP-ALL-DEVTYPE-TUNER`: + + - ``CEC_OP_ALL_DEVTYPE_TUNER`` + + - 0x20 + + - This supports the Tuner type. + + - .. _`CEC-OP-ALL-DEVTYPE-PLAYBACK`: + + - ``CEC_OP_ALL_DEVTYPE_PLAYBACK`` + + - 0x10 + + - This supports the Playback type. + + - .. _`CEC-OP-ALL-DEVTYPE-AUDIOSYSTEM`: + + - ``CEC_OP_ALL_DEVTYPE_AUDIOSYSTEM`` + + - 0x08 + + - This supports the Audio System type. + + - .. _`CEC-OP-ALL-DEVTYPE-SWITCH`: + + - ``CEC_OP_ALL_DEVTYPE_SWITCH`` + + - 0x04 + + - This supports the CEC Switch or Video Processing type. + + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes <gen-errors>` chapter. + diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-phys-addr.rst b/Documentation/media/uapi/cec/cec-ioc-adap-g-phys-addr.rst new file mode 100644 index 000000000..b955d044b --- /dev/null +++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-phys-addr.rst @@ -0,0 +1,82 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CEC_ADAP_PHYS_ADDR: +.. _CEC_ADAP_G_PHYS_ADDR: +.. _CEC_ADAP_S_PHYS_ADDR: + +**************************************************** +ioctls CEC_ADAP_G_PHYS_ADDR and CEC_ADAP_S_PHYS_ADDR +**************************************************** + +Name +==== + +CEC_ADAP_G_PHYS_ADDR, CEC_ADAP_S_PHYS_ADDR - Get or set the physical address + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u16 *argp ) + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() <cec-func-open>`. + +``request`` + CEC_ADAP_G_PHYS_ADDR, CEC_ADAP_S_PHYS_ADDR + +``argp`` + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +To query the current physical address applications call +:ref:`ioctl CEC_ADAP_G_PHYS_ADDR <CEC_ADAP_G_PHYS_ADDR>` with a pointer to a __u16 where the +driver stores the physical address. + +To set a new physical address applications store the physical address in +a __u16 and call :ref:`ioctl CEC_ADAP_S_PHYS_ADDR <CEC_ADAP_S_PHYS_ADDR>` with a pointer to +this integer. The :ref:`ioctl CEC_ADAP_S_PHYS_ADDR <CEC_ADAP_S_PHYS_ADDR>` is only available if +``CEC_CAP_PHYS_ADDR`` is set (the ``ENOTTY`` error code will be returned +otherwise). The :ref:`ioctl CEC_ADAP_S_PHYS_ADDR <CEC_ADAP_S_PHYS_ADDR>` can only be called +by a file descriptor in initiator mode (see :ref:`CEC_S_MODE`), if not +the ``EBUSY`` error code will be returned. + +To clear an existing physical address use ``CEC_PHYS_ADDR_INVALID``. +The adapter will go to the unconfigured state. + +If logical address types have been defined (see :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>`), +then this ioctl will block until all +requested logical addresses have been claimed. If the file descriptor is in non-blocking mode +then it will not wait for the logical addresses to be claimed, instead it just returns 0. + +A :ref:`CEC_EVENT_STATE_CHANGE <CEC-EVENT-STATE-CHANGE>` event is sent when the physical address +changes. + +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 ≥ 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. + +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. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst new file mode 100644 index 000000000..2e1e73928 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst @@ -0,0 +1,235 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CEC_DQEVENT: + +***************** +ioctl CEC_DQEVENT +***************** + +Name +==== + +CEC_DQEVENT - Dequeue a CEC event + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct cec_event *argp ) + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() <cec-func-open>`. + +``request`` + CEC_DQEVENT + +``argp`` + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +CEC devices can send asynchronous events. These can be retrieved by +calling :ref:`ioctl CEC_DQEVENT <CEC_DQEVENT>`. 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`` error code. + +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 :ref:`CEC_EVENT_STATE_CHANGE <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. + + +.. _cec-event-state-change_s: + +.. flat-table:: struct cec_event_state_change + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 8 + + + - .. row 1 + + - __u16 + + - ``phys_addr`` + + - The current physical address. This is ``CEC_PHYS_ADDR_INVALID`` if no + valid physical address is set. + + - .. row 2 + + - __u16 + + - ``log_addr_mask`` + + - The current set of claimed logical addresses. This is 0 if no logical + addresses are claimed or if ``phys_addr`` is ``CEC_PHYS_ADDR_INVALID``. + If bit 15 is set (``1 << CEC_LOG_ADDR_UNREGISTERED``) then this device + has the unregistered logical address. In that case all other bits are 0. + + + +.. _cec-event-lost-msgs_s: + +.. flat-table:: struct cec_event_lost_msgs + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 16 + + + - .. row 1 + + - __u32 + + - ``lost_msgs`` + + - 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. + + + +.. _cec-event: + +.. flat-table:: struct cec_event + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 1 8 + + + - .. row 1 + + - __u64 + + - ``ts`` + + - Timestamp of the event in ns. + The timestamp has been taken from the ``CLOCK_MONOTONIC`` clock. To access + the same clock from userspace use :c:func:`clock_gettime(2)`. + + - + + - .. row 2 + + - __u32 + + - ``event`` + + - The CEC event type, see :ref:`cec-events`. + + - + + - .. row 3 + + - __u32 + + - ``flags`` + + - Event flags, see :ref:`cec-event-flags`. + + - + + - .. row 4 + + - union + + - (anonymous) + + - + - + + - .. row 5 + + - + - struct cec_event_state_change + + - ``state_change`` + + - The new adapter state as sent by the :ref:`CEC_EVENT_STATE_CHANGE <CEC-EVENT-STATE-CHANGE>` + event. + + - .. row 6 + + - + - struct cec_event_lost_msgs + + - ``lost_msgs`` + + - The number of lost messages as sent by the :ref:`CEC_EVENT_LOST_MSGS <CEC-EVENT-LOST-MSGS>` + event. + + + +.. _cec-events: + +.. flat-table:: CEC Events Types + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 16 + + + - .. _`CEC-EVENT-STATE-CHANGE`: + + - ``CEC_EVENT_STATE_CHANGE`` + + - 1 + + - 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. + + - .. _`CEC-EVENT-LOST-MSGS`: + + - ``CEC_EVENT_LOST_MSGS`` + + - 2 + + - Generated if one or more CEC messages were lost because the + application didn't dequeue CEC messages fast enough. + + + +.. _cec-event-flags: + +.. flat-table:: CEC Event Flags + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 8 + + + - .. _`CEC-EVENT-FL-INITIAL-VALUE`: + + - ``CEC_EVENT_FL_INITIAL_VALUE`` + + - 1 + + - 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. + + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/media/uapi/cec/cec-ioc-g-mode.rst b/Documentation/media/uapi/cec/cec-ioc-g-mode.rst new file mode 100644 index 000000000..f0084d892 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-ioc-g-mode.rst @@ -0,0 +1,295 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CEC_MODE: +.. _CEC_G_MODE: +.. _CEC_S_MODE: + +******************************** +ioctls CEC_G_MODE and CEC_S_MODE +******************************** + +CEC_G_MODE, CEC_S_MODE - Get or set exclusive use of the CEC adapter + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, __u32 *argp ) + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() <cec-func-open>`. + +``request`` + CEC_G_MODE, CEC_S_MODE + +``argp`` + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +By default any filehandle can use :ref:`CEC_TRANSMIT`, but in order to prevent +applications from stepping on each others toes it must be possible to +obtain exclusive access to the CEC adapter. This ioctl sets the +filehandle to initiator and/or follower mode which can be exclusive +depending on the chosen mode. The initiator is the filehandle that is +used to initiate messages, i.e. it commands other CEC devices. The +follower is the filehandle that receives messages sent to the CEC +adapter and processes them. The same filehandle can be both initiator +and follower, or this role can be taken by two different filehandles. + +When a CEC message is received, then the CEC framework will decide how +it will be processed. If the message is a reply to an earlier +transmitted message, then the reply is sent back to the filehandle that +is waiting for it. In addition the CEC framework will process it. + +If the message is not a reply, then the CEC framework will process it +first. If there is no follower, then the message is just discarded and a +feature abort is sent back to the initiator if the framework couldn't +process it. If there is a follower, then the message is passed on to the +follower who will use :ref:`ioctl CEC_RECEIVE <CEC_RECEIVE>` to dequeue +the new message. The framework expects the follower to make the right +decisions. + +The CEC framework will process core messages unless requested otherwise +by the follower. The follower can enable the passthrough mode. In that +case, the CEC framework will pass on most core messages without +processing them and the follower will have to implement those messages. +There are some messages that the core will always process, regardless of +the passthrough mode. See :ref:`cec-core-processing` for details. + +If there is no initiator, then any CEC filehandle can use +:ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>`. If there is an exclusive +initiator then only that initiator can call +:ref:`CEC_TRANSMIT`. The follower can of course +always call :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>`. + +Available initiator modes are: + + +.. _cec-mode-initiator_e: + +.. flat-table:: Initiator Modes + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 16 + + + - .. _`CEC-MODE-NO-INITIATOR`: + + - ``CEC_MODE_NO_INITIATOR`` + + - 0x0 + + - This is not an initiator, i.e. it cannot transmit CEC messages or + make any other changes to the CEC adapter. + + - .. _`CEC-MODE-INITIATOR`: + + - ``CEC_MODE_INITIATOR`` + + - 0x1 + + - This is an initiator (the default when the device is opened) and + it can transmit CEC messages and make changes to the CEC adapter, + unless there is an exclusive initiator. + + - .. _`CEC-MODE-EXCL-INITIATOR`: + + - ``CEC_MODE_EXCL_INITIATOR`` + + - 0x2 + + - This is an exclusive initiator and this file descriptor is the + only one that can transmit CEC messages and make changes to the + CEC adapter. If someone else is already the exclusive initiator + then an attempt to become one will return the ``EBUSY`` error code + error. + + +Available follower modes are: + + +.. _cec-mode-follower_e: + +.. flat-table:: Follower Modes + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 16 + + + - .. _`CEC-MODE-NO-FOLLOWER`: + + - ``CEC_MODE_NO_FOLLOWER`` + + - 0x00 + + - This is not a follower (the default when the device is opened). + + - .. _`CEC-MODE-FOLLOWER`: + + - ``CEC_MODE_FOLLOWER`` + + - 0x10 + + - This is a follower and it will receive CEC messages unless there + is an exclusive follower. You cannot become a follower if + :ref:`CEC_CAP_TRANSMIT <CEC-CAP-TRANSMIT>` is not set or if :ref:`CEC_MODE_NO_INITIATOR <CEC-MODE-NO-INITIATOR>` + was specified, the ``EINVAL`` error code is returned in that case. + + - .. _`CEC-MODE-EXCL-FOLLOWER`: + + - ``CEC_MODE_EXCL_FOLLOWER`` + + - 0x20 + + - This is an exclusive follower and only this file descriptor will + receive CEC messages for processing. If someone else is already + the exclusive follower then an attempt to become one will return + the ``EBUSY`` error code. You cannot become a follower if + :ref:`CEC_CAP_TRANSMIT <CEC-CAP-TRANSMIT>` is not set or if :ref:`CEC_MODE_NO_INITIATOR <CEC-MODE-NO-INITIATOR>` + was specified, the ``EINVAL`` error code is returned in that case. + + - .. _`CEC-MODE-EXCL-FOLLOWER-PASSTHRU`: + + - ``CEC_MODE_EXCL_FOLLOWER_PASSTHRU`` + + - 0x30 + + - This is an exclusive follower and only this file descriptor will + receive CEC messages for processing. In addition it will put the + CEC device into passthrough mode, allowing the exclusive follower + to handle most core messages instead of relying on the CEC + framework for that. If someone else is already the exclusive + follower then an attempt to become one will return the ``EBUSY`` error + code. You cannot become a follower if :ref:`CEC_CAP_TRANSMIT <CEC-CAP-TRANSMIT>` + is not set or if :ref:`CEC_MODE_NO_INITIATOR <CEC-MODE-NO-INITIATOR>` was specified, + the ``EINVAL`` error code is returned in that case. + + - .. _`CEC-MODE-MONITOR`: + + - ``CEC_MODE_MONITOR`` + + - 0xe0 + + - Put the file descriptor into monitor mode. Can only be used in + combination with :ref:`CEC_MODE_NO_INITIATOR <CEC-MODE-NO-INITIATOR>`, otherwise EINVAL error + code will be returned. In monitor mode all messages this CEC + device transmits and all messages it receives (both broadcast + messages and directed messages for one its logical addresses) will + be reported. This is very useful for debugging. This is only + allowed if the process has the ``CAP_NET_ADMIN`` capability. If + that is not set, then the ``EPERM`` error code is returned. + + - .. _`CEC-MODE-MONITOR-ALL`: + + - ``CEC_MODE_MONITOR_ALL`` + + - 0xf0 + + - Put the file descriptor into 'monitor all' mode. Can only be used + in combination with :ref:`CEC_MODE_NO_INITIATOR <CEC-MODE-NO-INITIATOR>`, otherwise + the ``EINVAL`` error code will be returned. In 'monitor all' mode all messages + this CEC device transmits and all messages it receives, including + directed messages for other CEC devices will be reported. This is + very useful for debugging, but not all devices support this. This + mode requires that the :ref:`CEC_CAP_MONITOR_ALL <CEC-CAP-MONITOR-ALL>` capability is set, + otherwise the ``EINVAL`` error code is returned. This is only allowed if + the process has the ``CAP_NET_ADMIN`` capability. If that is not + set, then the ``EPERM`` error code is returned. + + +Core message processing details: + + +.. _cec-core-processing: + +.. flat-table:: Core Message Processing + :header-rows: 0 + :stub-columns: 0 + :widths: 1 8 + + + - .. _`CEC-MSG-GET-CEC-VERSION`: + + - ``CEC_MSG_GET_CEC_VERSION`` + + - When in passthrough mode this message has to be handled by + userspace, otherwise the core will return the CEC version that was + set with :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>`. + + - .. _`CEC-MSG-GIVE-DEVICE-VENDOR-ID`: + + - ``CEC_MSG_GIVE_DEVICE_VENDOR_ID`` + + - When in passthrough mode this message has to be handled by + userspace, otherwise the core will return the vendor ID that was + set with :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>`. + + - .. _`CEC-MSG-ABORT`: + + - ``CEC_MSG_ABORT`` + + - When in passthrough mode this message has to be handled by + userspace, otherwise the core will return a feature refused + message as per the specification. + + - .. _`CEC-MSG-GIVE-PHYSICAL-ADDR`: + + - ``CEC_MSG_GIVE_PHYSICAL_ADDR`` + + - When in passthrough mode this message has to be handled by + userspace, otherwise the core will report the current physical + address. + + - .. _`CEC-MSG-GIVE-OSD-NAME`: + + - ``CEC_MSG_GIVE_OSD_NAME`` + + - When in passthrough mode this message has to be handled by + userspace, otherwise the core will report the current OSD name as + was set with :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>`. + + - .. _`CEC-MSG-GIVE-FEATURES`: + + - ``CEC_MSG_GIVE_FEATURES`` + + - When in passthrough mode this message has to be handled by + userspace, otherwise the core will report the current features as + was set with :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>` + or the message is ignored if the CEC version was older than 2.0. + + - .. _`CEC-MSG-USER-CONTROL-PRESSED`: + + - ``CEC_MSG_USER_CONTROL_PRESSED`` + + - If :ref:`CEC_CAP_RC <CEC-CAP-RC>` is set, then generate a remote control key + press. This message is always passed on to userspace. + + - .. _`CEC-MSG-USER-CONTROL-RELEASED`: + + - ``CEC_MSG_USER_CONTROL_RELEASED`` + + - If :ref:`CEC_CAP_RC <CEC-CAP-RC>` is set, then generate a remote control key + release. This message is always passed on to userspace. + + - .. _`CEC-MSG-REPORT-PHYSICAL-ADDR`: + + - ``CEC_MSG_REPORT_PHYSICAL_ADDR`` + + - The CEC framework will make note of the reported physical address + and then just pass the message on to userspace. + + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/media/uapi/cec/cec-ioc-receive.rst b/Documentation/media/uapi/cec/cec-ioc-receive.rst new file mode 100644 index 000000000..ae5a39ade --- /dev/null +++ b/Documentation/media/uapi/cec/cec-ioc-receive.rst @@ -0,0 +1,360 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _CEC_TRANSMIT: +.. _CEC_RECEIVE: + +*********************************** +ioctls CEC_RECEIVE and CEC_TRANSMIT +*********************************** + +Name +==== + +CEC_RECEIVE, CEC_TRANSMIT - Receive or transmit a CEC message + + +Synopsis +======== + +.. cpp:function:: int ioctl( int fd, int request, struct cec_msg *argp ) + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() <cec-func-open>`. + +``request`` + CEC_RECEIVE, CEC_TRANSMIT + +``argp`` + + +Description +=========== + +.. note:: This documents the proposed CEC API. This API is not yet finalized + and is currently only available as a staging kernel module. + +To receive a CEC message the application has to fill in the +``timeout`` field of :c:type:`struct cec_msg` and pass it to :ref:`ioctl CEC_RECEIVE <CEC_RECEIVE>`. +If the file descriptor is in non-blocking mode and there are no received +messages pending, then it will return -1 and set errno to the ``EAGAIN`` +error code. If the file descriptor is in blocking mode and ``timeout`` +is non-zero and no message arrived within ``timeout`` milliseconds, then +it will return -1 and set errno to the ``ETIMEDOUT`` error code. + +A received message can be: + +1. a message received from another CEC device (the ``sequence`` field will + be 0). +2. the result of an earlier non-blocking transmit (the ``sequence`` field will + be non-zero). + +To send a CEC message the application has to fill in the +:c:type:`struct cec_msg` and pass it to +:ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>`. The :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>` is only available if +``CEC_CAP_TRANSMIT`` is set. If there is no more room in the transmit +queue, then it will return -1 and set errno to the ``EBUSY`` error code. +The transmit queue has enough room for 18 messages (about 1 second worth +of 2-byte messages). Note that the CEC kernel framework will also reply +to core messages (see :ref:cec-core-processing), so it is not a good +idea to fully fill up the transmit queue. + +If the file descriptor is in non-blocking mode then the transmit will +return 0 and the result of the transmit will be available via +:ref:`ioctl CEC_RECEIVE <CEC_RECEIVE>` once the transmit has finished +(including waiting for a reply, if requested). + +The ``sequence`` field is filled in for every transmit and this can be +checked against the received messages to find the corresponding transmit +result. + + +.. _cec-msg: + +.. flat-table:: struct cec_msg + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 16 + + + - .. row 1 + + - __u64 + + - ``tx_ts`` + + - Timestamp in ns of when the last byte of the message was transmitted. + The timestamp has been taken from the ``CLOCK_MONOTONIC`` clock. To access + the same clock from userspace use :c:func:`clock_gettime(2)`. + + - .. row 2 + + - __u64 + + - ``rx_ts`` + + - Timestamp in ns of when the last byte of the message was received. + The timestamp has been taken from the ``CLOCK_MONOTONIC`` clock. To access + the same clock from userspace use :c:func:`clock_gettime(2)`. + + - .. row 3 + + - __u32 + + - ``len`` + + - The length of the message. For :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>` this is filled in + by the application. The driver will fill this in for + :ref:`ioctl CEC_RECEIVE <CEC_RECEIVE>`. For :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>` it will be + filled in by the driver with the length of the reply message if ``reply`` was set. + + - .. row 4 + + - __u32 + + - ``timeout`` + + - The timeout in milliseconds. This is the time the device will wait + for a message to be received before timing out. If it is set to 0, + then it will wait indefinitely when it is called by :ref:`ioctl CEC_RECEIVE <CEC_RECEIVE>`. + If it is 0 and it is called by :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>`, + then it will be replaced by 1000 if the ``reply`` is non-zero or + ignored if ``reply`` is 0. + + - .. row 5 + + - __u32 + + - ``sequence`` + + - A non-zero sequence number is automatically assigned by the CEC framework + for all transmitted messages. It is used by the CEC framework when it queues + the transmit result (when transmit was called in non-blocking mode). This + allows the application to associate the received message with the original + transmit. + + - .. row 6 + + - __u32 + + - ``flags`` + + - Flags. No flags are defined yet, so set this to 0. + + - .. row 7 + + - __u8 + + - ``tx_status`` + + - The status bits of the transmitted message. See + :ref:`cec-tx-status` for the possible status values. It is 0 if + this messages was received, not transmitted. + + - .. row 8 + + - __u8 + + - ``msg[16]`` + + - The message payload. For :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>` this is filled in by the + application. The driver will fill this in for :ref:`ioctl CEC_RECEIVE <CEC_RECEIVE>`. + For :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>` it will be filled in by the driver with + the payload of the reply message if ``timeout`` was set. + + - .. row 8 + + - __u8 + + - ``reply`` + + - Wait until this message is replied. If ``reply`` is 0 and the + ``timeout`` is 0, then don't wait for a reply but return after + transmitting the message. Ignored by :ref:`ioctl CEC_RECEIVE <CEC_RECEIVE>`. + The case where ``reply`` is 0 (this is the opcode for the Feature Abort + message) and ``timeout`` is non-zero is specifically allowed to make it + possible to send a message and wait up to ``timeout`` milliseconds for a + Feature Abort reply. In this case ``rx_status`` will either be set + to :ref:`CEC_RX_STATUS_TIMEOUT <CEC-RX-STATUS-TIMEOUT>` or + :ref:`CEC_RX_STATUS_FEATURE_ABORT <CEC-RX-STATUS-FEATURE-ABORT>`. + + - .. row 9 + + - __u8 + + - ``rx_status`` + + - The status bits of the received message. See + :ref:`cec-rx-status` for the possible status values. It is 0 if + this message was transmitted, not received, unless this is the + reply to a transmitted message. In that case both ``rx_status`` + and ``tx_status`` are set. + + - .. row 10 + + - __u8 + + - ``tx_status`` + + - The status bits of the transmitted message. See + :ref:`cec-tx-status` for the possible status values. It is 0 if + this messages was received, not transmitted. + + - .. row 11 + + - __u8 + + - ``tx_arb_lost_cnt`` + + - A counter of the number of transmit attempts that resulted in the + Arbitration Lost error. This is only set if the hardware supports + this, otherwise it is always 0. This counter is only valid if the + :ref:`CEC_TX_STATUS_ARB_LOST <CEC-TX-STATUS-ARB-LOST>` status bit is set. + + - .. row 12 + + - __u8 + + - ``tx_nack_cnt`` + + - A counter of the number of transmit attempts that resulted in the + Not Acknowledged error. This is only set if the hardware supports + this, otherwise it is always 0. This counter is only valid if the + :ref:`CEC_TX_STATUS_NACK <CEC-TX-STATUS-NACK>` status bit is set. + + - .. row 13 + + - __u8 + + - ``tx_low_drive_cnt`` + + - A counter of the number of transmit attempts that resulted in the + Arbitration Lost error. This is only set if the hardware supports + this, otherwise it is always 0. This counter is only valid if the + :ref:`CEC_TX_STATUS_LOW_DRIVE <CEC-TX-STATUS-LOW-DRIVE>` status bit is set. + + - .. row 14 + + - __u8 + + - ``tx_error_cnt`` + + - A counter of the number of transmit errors other than Arbitration + Lost or Not Acknowledged. This is only set if the hardware + supports this, otherwise it is always 0. This counter is only + valid if the :ref:`CEC_TX_STATUS_ERROR <CEC-TX-STATUS-ERROR>` status bit is set. + + + +.. _cec-tx-status: + +.. flat-table:: CEC Transmit Status + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 16 + + + - .. _`CEC-TX-STATUS-OK`: + + - ``CEC_TX_STATUS_OK`` + + - 0x01 + + - The message was transmitted successfully. This is mutually + exclusive with :ref:`CEC_TX_STATUS_MAX_RETRIES <CEC-TX-STATUS-MAX-RETRIES>`. Other bits can still + be set if earlier attempts met with failure before the transmit + was eventually successful. + + - .. _`CEC-TX-STATUS-ARB-LOST`: + + - ``CEC_TX_STATUS_ARB_LOST`` + + - 0x02 + + - CEC line arbitration was lost. + + - .. _`CEC-TX-STATUS-NACK`: + + - ``CEC_TX_STATUS_NACK`` + + - 0x04 + + - Message was not acknowledged. + + - .. _`CEC-TX-STATUS-LOW-DRIVE`: + + - ``CEC_TX_STATUS_LOW_DRIVE`` + + - 0x08 + + - Low drive was detected on the CEC bus. This indicates that a + follower detected an error on the bus and requests a + retransmission. + + - .. _`CEC-TX-STATUS-ERROR`: + + - ``CEC_TX_STATUS_ERROR`` + + - 0x10 + + - Some error occurred. This is used for any errors that do not fit + the previous two, either because the hardware could not tell which + error occurred, or because the hardware tested for other + conditions besides those two. + + - .. _`CEC-TX-STATUS-MAX-RETRIES`: + + - ``CEC_TX_STATUS_MAX_RETRIES`` + + - 0x20 + + - The transmit failed after one or more retries. This status bit is + mutually exclusive with :ref:`CEC_TX_STATUS_OK <CEC-TX-STATUS-OK>`. Other bits can still + be set to explain which failures were seen. + + + +.. _cec-rx-status: + +.. flat-table:: CEC Receive Status + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 16 + + + - .. _`CEC-RX-STATUS-OK`: + + - ``CEC_RX_STATUS_OK`` + + - 0x01 + + - The message was received successfully. + + - .. _`CEC-RX-STATUS-TIMEOUT`: + + - ``CEC_RX_STATUS_TIMEOUT`` + + - 0x02 + + - The reply to an earlier transmitted message timed out. + + - .. _`CEC-RX-STATUS-FEATURE-ABORT`: + + - ``CEC_RX_STATUS_FEATURE_ABORT`` + + - 0x04 + + - The message was received successfully but the reply was + ``CEC_MSG_FEATURE_ABORT``. This status is only set if this message + was the reply to an earlier transmitted message. + + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes <gen-errors>` chapter. |