mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2025-01-24 08:19:41 +07:00
5bd4bb7817
LaTeX doesn't handle too well auto-width on tables, and ReST
markup requires an special tag to give it the needed hints.
As we're using A4 paper, we have 17cm of useful spaces. As
most media tables have widths, let's use it to generate the
needed via the following perl script:
my ($line_size, $table_header, $has_cols) = (17.5, 0, 0);
my $out;
my $header = "";
my @widths = ();
sub round { $_[0] > 0 ? int($_[0] + .5) : -int(-$_[0] + .5) }
while (<>) {
if (!$table_header) {
$has_cols = 1 if (m/..\s+tabularcolumns::/);
if (m/..\s+flat-table::/) {
$table_header = 1;
$header = $_;
next;
}
$out .= $_;
next;
}
$header .= $_;
@widths = split(/ /, $1) if (m/:widths:\s+(.*)/);
if (m/^\n$/) {
if (!$has_cols && @widths) {
my ($tot, $t, $i) = (0, 0, 0);
foreach my $v(@widths) { $tot += $v; };
$out .= ".. tabularcolumns:: |";
for ($i = 0; $i < scalar @widths - 1; $i++) {
my $v = $widths[$i];
my $w = round(10 * ($v * $line_size) / $tot) / 10;
$out .= sprintf "p{%.1fcm}|", $w;
$t += $w;
}
my $w = $line_size - $t;
$out .= sprintf "p{%.1fcm}|\n\n", $w;
}
$out .= $header;
$table_header = 0;
$has_cols = 0;
$header = "";
@widths = ();
}
}
print $out;
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
304 lines
9.9 KiB
ReStructuredText
304 lines
9.9 KiB
ReStructuredText
.. -*- 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:
|
|
|
|
.. tabularcolumns:: |p{2.6cm}|p{0.9cm}|p{14.0cm}|
|
|
|
|
.. 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:
|
|
|
|
.. tabularcolumns:: |p{2.6cm}|p{0.9cm}|p{14.0cm}|
|
|
|
|
.. 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:
|
|
|
|
.. tabularcolumns:: |p{1.9cm}|p{15.6cm}|
|
|
|
|
.. 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.
|