Commit 73a16745 authored by Hans Verkuil's avatar Hans Verkuil Committed by Mauro Carvalho Chehab

media: cec-ioc-g-mode.rst: improve description of message, processing

The description of how messages are processed by the core was not
always very clear. Reword it to improve this.

In particular for the USER_CONTROL_* messages a critical bit was
missing in that the core also checks for the CEC_LOG_ADDRS_FL_ALLOW_RC_PASSTHRU
flag. This was confusing.
Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
parent 88afc1cf
...@@ -206,55 +206,68 @@ Core message processing details: ...@@ -206,55 +206,68 @@ Core message processing details:
* .. _`CEC-MSG-GET-CEC-VERSION`: * .. _`CEC-MSG-GET-CEC-VERSION`:
- ``CEC_MSG_GET_CEC_VERSION`` - ``CEC_MSG_GET_CEC_VERSION``
- When in passthrough mode this message has to be handled by - The core will return the CEC version that was set with
userspace, otherwise the core will return the CEC version that was :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>`,
set with :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>`. except when in passthrough mode. In passthrough mode the core
does nothing and this message has to be handled by a follower
instead.
* .. _`CEC-MSG-GIVE-DEVICE-VENDOR-ID`: * .. _`CEC-MSG-GIVE-DEVICE-VENDOR-ID`:
- ``CEC_MSG_GIVE_DEVICE_VENDOR_ID`` - ``CEC_MSG_GIVE_DEVICE_VENDOR_ID``
- When in passthrough mode this message has to be handled by - The core will return the vendor ID that was set with
userspace, otherwise the core will return the vendor ID that was :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>`,
set with :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>`. except when in passthrough mode. In passthrough mode the core
does nothing and this message has to be handled by a follower
instead.
* .. _`CEC-MSG-ABORT`: * .. _`CEC-MSG-ABORT`:
- ``CEC_MSG_ABORT`` - ``CEC_MSG_ABORT``
- When in passthrough mode this message has to be handled by - The core will return a Feature Abort message with reason
userspace, otherwise the core will return a feature refused 'Feature Refused' as per the specification, except when in
message as per the specification. passthrough mode. In passthrough mode the core does nothing
and this message has to be handled by a follower instead.
* .. _`CEC-MSG-GIVE-PHYSICAL-ADDR`: * .. _`CEC-MSG-GIVE-PHYSICAL-ADDR`:
- ``CEC_MSG_GIVE_PHYSICAL_ADDR`` - ``CEC_MSG_GIVE_PHYSICAL_ADDR``
- When in passthrough mode this message has to be handled by - The core will report the current physical address, except when
userspace, otherwise the core will report the current physical in passthrough mode. In passthrough mode the core does nothing
address. and this message has to be handled by a follower instead.
* .. _`CEC-MSG-GIVE-OSD-NAME`: * .. _`CEC-MSG-GIVE-OSD-NAME`:
- ``CEC_MSG_GIVE_OSD_NAME`` - ``CEC_MSG_GIVE_OSD_NAME``
- When in passthrough mode this message has to be handled by - The core will report the current OSD name that was set with
userspace, otherwise the core will report the current OSD name as :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>`,
was set with :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>`. except when in passthrough mode. In passthrough mode the core
does nothing and this message has to be handled by a follower
instead.
* .. _`CEC-MSG-GIVE-FEATURES`: * .. _`CEC-MSG-GIVE-FEATURES`:
- ``CEC_MSG_GIVE_FEATURES`` - ``CEC_MSG_GIVE_FEATURES``
- When in passthrough mode this message has to be handled by - The core will do nothing if the CEC version is older than 2.0,
userspace, otherwise the core will report the current features as otherwise it will report the current features that were set with
was set with :ref:`ioctl CEC_ADAP_S_LOG_ADDRS <CEC_ADAP_S_LOG_ADDRS>` :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. except when in passthrough mode. In passthrough mode the core
does nothing (for any CEC version) and this message has to be handled
by a follower instead.
* .. _`CEC-MSG-USER-CONTROL-PRESSED`: * .. _`CEC-MSG-USER-CONTROL-PRESSED`:
- ``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 - If :ref:`CEC_CAP_RC <CEC-CAP-RC>` is set and if
press. This message is always passed on to userspace. :ref:`CEC_LOG_ADDRS_FL_ALLOW_RC_PASSTHRU <CEC-LOG-ADDRS-FL-ALLOW-RC-PASSTHRU>`
is set, then generate a remote control key
press. This message is always passed on to the follower(s).
* .. _`CEC-MSG-USER-CONTROL-RELEASED`: * .. _`CEC-MSG-USER-CONTROL-RELEASED`:
- ``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 - If :ref:`CEC_CAP_RC <CEC-CAP-RC>` is set and if
release. This message is always passed on to userspace. :ref:`CEC_LOG_ADDRS_FL_ALLOW_RC_PASSTHRU <CEC-LOG-ADDRS-FL-ALLOW-RC-PASSTHRU>`
is set, then generate a remote control key
release. This message is always passed on to the follower(s).
* .. _`CEC-MSG-REPORT-PHYSICAL-ADDR`: * .. _`CEC-MSG-REPORT-PHYSICAL-ADDR`:
- ``CEC_MSG_REPORT_PHYSICAL_ADDR`` - ``CEC_MSG_REPORT_PHYSICAL_ADDR``
- The CEC framework will make note of the reported physical address - The CEC framework will make note of the reported physical address
and then just pass the message on to userspace. and then just pass the message on to the follower(s).
......
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