...

HDMI-CEC is a protocol that provides high-level control functions between audio-visual devices connected over HDMI. CEC is a one-wire bidirectional serial bus based on industry-standard AV.Link protocol to perform control functions. All audio-visual sources are connected directly or indirectly to a display device as the ‘root’ in a tree-like structure.

Feature Summary

• Hardware support for HDMI-CEC as specified in HDMI 1.4a

  • CEC 4 – Electrical Specification
  • CEC 5 – Signaling and Bit Timings
  • CEC 6 – Frame Description
  • CEC 7 – Reliable Communication Mechanisms
  • CEC 8 – Protocol Extensions
  • CEC 9 – CEC Arbitration
  • CEC 10.1 – Physical Address Discovery
  • CEC 11 – Switch Requirements

• Send raw or formatted CEC messages on behalf of application
• Provide received CEC messages to registered application listener
• Get information about a device connected to HDMI input
• Autonomously handle subset of CEC messages
• Provide list of connected CEC capable device to application
• Send "Feature Abort" response if message is not handled autonomously by RDK and message is not handled by application listener

Device Applicability

This feature applies to the following devices:

• Hybrid
• IP

Architecture Overview

Capabilities

Component Impacts

CEC Protocol Library

• Translate application commands to CEC commands
• Receive CEC commands and provide to application listeners
• Autonomously respond to a subset of CEC messages

...

• Source video from HDMI input

How HDMI-CEC Works in RDK

Application API Specification

Overall the RDK-CEC library offers 3 categories of application APIs,

...

The Driver Component access the HDMI-CEC SoC Driver via the CEC HAL API. The vendors are responsible in delivering a SoC Driver that conforms to the HAL API (see the header file hdmi_cec_driver.h)

HDMI-CEC Applications

The relation between Application, Connection and CEC-Bus is described in the figure.

...

In most cases application need not access CECFrame directly, but manipulate the raw bytes through the Message API. The Message API allows the application to send or receive high-level CEC message construct instead of raw bytes. Basically for each CEC message (such as ActiveSource), there is a C++ class implementation representing it. Each message class provides necessary getter and setter methods to access the properties of each message.

Asynchronous Vs. Synchronous

When messages converge on the logical buses, they are queued for sending opportunities on the physical bus. The waiting time for such send to complete, though short in most cases, can be problematic to some interactive real-time applications. It is recommended that the applications always send CEC messages asynchronously via the Connection API and use the listener APIs to monitor response messages or device state changes. The CEC library offers abundant APIs to facilitate such asynchronous implementation and the application is encouraged to make full use of them. 

...

The message flow on Connections and Logical Buses are full duplex.

Methods

"CECAddresses" : {
 "physicalAddress": Array of 4 bytes [byte0, byte1, byte2, byte3],
 "logicalAddresses" : Array of <CECLogicalAddress>
}

"CECLogicalAddress" : {
 "deviceType" : <string> 
 "logicalAddress": <integer>
}

Events