Skip to content

HDMI CEC vComponent ‐ Roadmap items

sramani-metro edited this page Aug 12, 2024 · 2 revisions

HDMI CEC vComponent - Roadmap

1. Updates the YAML command template to be not specific to vComponent

  • Currently, the YAML command templates are specific to vComponent dealing with CEC commands. When integrated with the end-to-end automation system including Python RAFT framework which can also control real devices, a generic YAML command template that can be used to also control real devices by means of IR blasters or CEC adapters.
  • Update the command template to have a common format for sender/receiver names and the test scenario to trigger which may be user features like One touch play.
  • The command shall be generic and makes it easy to interpret by a test controller in a real system as well as the vComponent.

Command template proposal

In a real-world scenario, certain CEC commands like One Touch Play involve multiple actions. For instance, when a device initiates One Touch Play, it typically sends both the ImageViewOn and ActiveSource commands. To create a common YAML command template that can be used for both the virtual component and real devices, including integration with the Python RAFT framework, we can structure the YAML file to include generic fields that define the sender, receiver, and the action (test scenario). This will allow easy interpretation by a test controller, whether the command is executed on a virtual or real device.

Unified HDMI and CEC Adapter Commands

  • Unified Control Flow: In an end-to-end automation system, whether you're controlling a real device via an IR blaster or a CEC adapter, or using a virtual component, the test controller should interpret and trigger the appropriate sequence of commands uniformly. This reduces complexity and potential for errors.

  • Consistency Across Devices: By using a unified command structure, the system can ensure that the same sequence of actions is triggered on both real and virtual devices, maintaining consistency across different testing environments.

  • Simplified YAML Structure: A single command template that handles both HDMI and CEC Adapter actions ensures that the YAML files remain straightforward and easy to manage, making them less prone to errors during both development and testing.

---
hdmicec:
  scenario: "OneTouchPlay"
  initiator: "IPSTB"
  receiver: "TV"
  cec:
    - command: "ImageViewOn"
    - command: "ActiveSource"
      parameters:
        physical_address: "1000"  # Hexadecimal format

# Metadata for the test
  metadata:
    test_id: "Test_001"
    description: "Test One Touch Play with both virtual and real devices"
    expected_result: "TV should switch to the input corresponding to the IPSTB"
    timeout: 30  # Optional: timeout for the test in seconds

Key Points:

  • This template is generic and adaptable to various scenarios, whether it's controlling a virtual component, sending IR commands to real devices, or using a CEC adapter.

  • The sender and receiver fields are abstracted to accommodate both virtual and real devices, ensuring the command is interpretable in either context.

  • Parameters can be extended or customized based on the specific command being executed.

  • This format will streamline integration with the end-to-end automation system, making it easier to control both virtual and real devices using a consistent, unified YAML structure.

    For e.g, the template can be extended to include specific commands for the test controller to control non CEC devices like Power controllers, IR Blasters when real devices are being tested. In a real setup when the test controller needs to be instructed to power on a particular device using the ir blaster, the below snippet could be added to the scenario.

---
  ir:
    command: "PowerOn"  # IR command name (e.g., for controlling real devices via IR blasters)
    receiver: "TV"  # Target device receiving the IR signal
    parameters:
      delay: 2  # Optional: delay before sending the command in seconds

2. HDMI CEC Source tests

Update vComponent to input main profile and validation profile with DUT being an source device.

  • Make basic L1 and L2 tests pass
  • Define Main and validation profiles for source device
  • Create L3 tests to validate basic source functionality.

3 Create a framework in vComponent to parse CEC payload that comes in HdmiCecTx and HdmiCecTxAsync. Large task.

  • vComponent should respond back with appropriate cec payload derived from the YAML profile supplied. Example, Getting OSD string, Version, Power status or so on.
  • vComponent should change its internal state of devices based on the Tx command payload and also trigger callbacks based on new status as response. For e.g, Sending standby command using HdmiCecTxAsync should make sure all the devices in the virtual device map to swtch the power status to standby. If required, canned Rx callbacks like Report Power Status could be triggered from each device in the device map to report the stand by status.
  • Make changes to Device subsystem to change specific device parameters like power status.
  • Implement logging to verify the internal state machine of the DUT updates correctly based on the simulated responses.

Currently all CEC commands received though control plane are queued and a worker thread processes each command, parses the YAML and creates CEC payload that will be sent through the Rx Callback. Similarly, the payload from HdmiCecTx should be parsed and appropriate changes should be made in the internal device map. Appropriate responses should be made based on current state and Rx callback will be triggered. Internal state machine including the device map should be under mutex protection to avoid processing controlplane and Tx commands in parallel.

Some common commands and responses expected:

1. Standby (0x36)

  • Command: 36 (Broadcast)
  • Expected Responses:
    • Devices respond with their power status.
    • Example Response:
      • 40:90:00 (TV reports power status as "On")
      • 50:90:01 (Playback device reports power status as "Standby")
      • 60:90:02 (Tuner reports power status as "Transitioning to Standby")

2. Active Source (0x82)

  • Command: 4F:82:10:00 (Playback device declares itself as the active source)
  • Expected Responses:
    • TVs or Audio Systems may acknowledge this.
    • Example Response:
      • 5F:84:10:00:04 (Audio System acknowledges the new active source)

3. Report Physical Address (0x84)

  • Command: 5F:84:20:00:05 (Audio System reports its physical address as 2000 and device type as Audio)
  • Expected Responses:
    • No response required, but other devices may update their internal maps.

4. Request Power Status (0x8F)

  • Command: 0F:8F (Request power status from TV)
  • Expected Responses:
    • Example Response:
      • 0F:90:00 (TV responds with "On")
      • 0F:90:01 (TV responds with "Standby")

5. Give Device Power Status (0x8F)

  • Command: 40:8F (TV requests power status from Playback Device 1)
  • Expected Responses:
    • Example Response:
      • 40:90:00 (Playback Device 1 responds with "On")
      • 40:90:01 (Playback Device 1 responds with "Standby")

6. Set Audio Mode (0x72)

  • Command: 50:72:01 (Set Audio Mode On)
  • Expected Responses:
    • Example Response:
      • 50:7E:01 (Audio mode confirmed)

7. System Audio Mode Request (0x70)

  • Command: 0F:70:01 (TV requests Audio System to turn on audio mode)
  • Expected Responses:
    • Example Response:
      • 0F:7E:01 (Audio System acknowledges the request)

8. Text View On (0x0D)

  • Command: 40:0D (TV indicates it is now displaying text)
  • Expected Responses:
    • Example Response:
      • No specific response required, but Playback devices may switch to a different mode.

9. Give Tuner Device Status (0x08)

  • Command: 20:08 (TV requests status from Tuner 1)
  • Expected Responses:
    • Example Response:
      • 20:09:80 (Tuner 1 responds with status information)

10. Request Active Source (0x85)

  • Command: 0F:85 (Request current active source)
  • Expected Responses:
    • Example Response:
      • 40:82:10:00 (TV responds with its current active source)

To keep the YAML template simple and extensible, we can structure the canned responses with placeholders that get substituted by the state machine's current values for each device. Here's an example template:

cec_responses:
  - command: "0x36"  # Standby
    responses:
      - type: "power_status"
        loop_devices: true  # Apply this response to all devices in the device map
        payload: "[:sender]:90:[:power_status]"  # Response pattern with placeholders
        description: "Devices report their power status"

  - command: "0x82"  # Active Source
    responses:
      - type: "active_source_ack"
        loop_devices: false  # Apply this response to a specific device (like an Audio System)
        payload: "[:receiver]:84:[:physical_address]:[:device_type]"  # Acknowledge new active source
        description: "Acknowledge new active source"

  - command: "0x8F"  # Request Power Status
    responses:
      - type: "power_status_response"
        loop_devices: true  # Apply this response to all devices in the device map
        payload: "[:sender]:90:[:power_status]"  # Response pattern with placeholders
        description: "Devices respond with their current power status"

  - command: "0x70"  # System Audio Mode Request
    responses:
      - type: "audio_mode_ack"
        loop_devices: false  # Apply this response to the Audio System
        payload: "[:receiver]:7E:01"  # Audio mode acknowledged
        description: "Audio System acknowledges the request"

  - command: "0x85"  # Request Active Source
    responses:
      - type: "active_source_response"
        loop_devices: true  # Apply this response to all devices in the device map
        payload: "[:sender]:82:[:physical_address]"  # Response pattern with placeholders
        description: "Devices respond with their current active source"

command: The CEC command being sent via HdmiCecTx. responses: A list of potential responses that could be triggered by the command.

type: A label describing the type of response (e.g., power_status, active_source_ack). loop_devices:

  • true: The response will be applied to all devices in the device map.
  • false: The response will be applied to a specific device.

payload: The CEC response payload template, with placeholders for dynamic values from the device map's state machine (e.g., [:sender], [:receiver], [:physical_address], [:power_status]). description: A human-readable explanation of the response.

Looping Over Devices: The loop_devices: true directive tells the state machine to generate a response for each device in the current device map using the provided payload template. Dynamic Values: Placeholders like [:sender], [:receiver], [:physical_address], etc., are substituted with values from the device's state within the state machine.

4. L3 Tests updates

Currently, the L3 tests focussed on sink devices verifies receive callback data and validate it. but these are based on specific cec commands like ActiveSource, ImageViewOn etc. The L3 tests should rather match real world scenarios which may have one or more commands to validate when control plane triggers them. All L3 tests shall be written keeping real setup in focus. Some basic tests are listed below.

1. Power Control Tests

  • Power Off Using TV Remote:

    • DUT - STB
    • Action: Use the TV remote control to power off the TV.
    • Verify: The DUT receives and logs a Standby command.
  • Power On Using TV Remote:

    • Action: Use the TV remote control to power on the TV.
    • Verify: The DUT receives and logs a Image View On or Text View On command.

2. One Touch Play Tests

  • Play Media Using STB Remote:
    • Action: Use the STB remote control to start media playback.
    • Verify: The TV powers on and switches to the HDMI input source connected to the STB. The DUT logs the One Touch Play command.

3. Volume Control Tests

  • Volume Up Using TV Remote:

    • Action: Use the TV remote control to increase the volume.
    • Verify: The DUT receives and logs a Volume Up command and the volume level increases.
  • Volume Down Using TV Remote:

    • Action: Use the TV remote control to decrease the volume.
    • Verify: The DUT receives and logs a Volume Down command and the volume level decreases.

4. System Information Tests

  • Request Device Vendor ID Using TV Remote:
    • Action: Use the TV remote control to request the vendor ID.
    • Verify: The DUT logs the Give Device Vendor ID command and responds with the correct vendor ID.

5. Remote Control Pass-Through Tests

  • Play/Pause Media Using TV Remote:
    • Action: Use the TV remote control to play or pause media on the STB.
    • Verify: The DUT receives and logs the User Control Pressed command for play/pause and performs the expected action.

6. Device Menu Control Tests

  • Open Device Menu Using TV Remote:
    • Action: Use the TV remote control to open the device menu.
    • Verify: The DUT receives and logs the Menu Request command and opens the device menu.

7. Routing Control Tests

  • Switch HDMI Source Using TV Remote:
    • Action: Use the TV remote control to switch HDMI input sources.
    • Verify: The DUT receives and logs the Routing Change command and switches to the specified HDMI source.

8. CEC Version Tests

  • Get CEC Version Using TV Remote:
    • Action: Use the TV remote control to request the CEC version.
    • Verify: The DUT logs the Get CEC Version command and responds with the supported CEC version.

9. Feature Abort Tests

  • Unsupported Command Handling Using TV Remote:
    • Action: Use the TV remote control to send an unsupported CEC command.
    • Verify: The DUT receives and logs the Feature Abort command, indicating the reason for the abort.

10. System Audio Control Tests

  • Enable/Disable System Audio Using TV Remote:
    • Action: Use the TV remote control to enable or disable system audio mode.
    • Verify: The DUT receives and logs the System Audio Mode Request command and enables or disables system audio mode accordingly.

4 Identify L3 tests that would require triggering a send using HdmiCecTx and create tests to validate.

1. Power Control Tests

Power On Sequence

  • Action: Use HdmiCecTx to send a Text View On or Image View On command from the DUT.
  • Canned Response: Simulate a response indicating the target device has powered on.
  • Verify: The DUT's internal state machine updates to reflect the powered-on state of the target device.

Power Off Sequence

  • Action: Use HdmiCecTx to send a Standby command from the DUT.
  • Canned Response: Simulate a response indicating the target device has powered off.
  • Verify: The DUT's internal state machine updates to reflect the powered-off state of the target device.

2. One Touch Play Tests

One Touch Play Command

  • Action: Use HdmiCecTx to send an Active Source command from the DUT.
  • Canned Response: Simulate a response indicating the TV has switched to the active source.
  • Verify: The DUT's internal state machine updates to reflect that the TV has switched to the DUT's HDMI port.

3. Volume Control Tests

Volume Up Command

  • Action: Use HdmiCecTx to send a User Control Pressed (Volume Up) command from the DUT.
  • Canned Response: Simulate a response indicating the volume has increased.
  • Verify: The DUT's internal state machine updates to reflect the volume increase.

Volume Down Command

  • Action: Use HdmiCecTx to send a User Control Pressed (Volume Down) command from the DUT.
  • Canned Response: Simulate a response indicating the volume has decreased.
  • Verify: The DUT's internal state machine updates to reflect the volume decrease.

Mute Command

  • Action: Use HdmiCecTx to send a User Control Pressed (Mute) command from the DUT.
  • Canned Response: Simulate a response indicating the device has muted.
  • Verify: The DUT's internal state machine updates to reflect the mute state.

4. System Information Tests

Request Device Vendor ID

  • Action: Use HdmiCecTx to send a Give Device Vendor ID command from the DUT.
  • Canned Response: Simulate a response with the vendor ID.
  • Verify: The DUT's internal state machine updates to store the vendor ID information.

5. Routing Control Tests

Switch HDMI Source

  • Action: Use HdmiCecTx to send a Routing Change command from the DUT.
  • Canned Response: Simulate a response indicating the HDMI source has changed.
  • Verify: The DUT's internal state machine updates to reflect the new HDMI source.

6. System Audio Control Tests

Enable System Audio

  • Action: Use HdmiCecTx to send a System Audio Mode Request (On) command from the DUT.
  • Canned Response: Simulate a response indicating the system audio mode has been enabled.
  • Verify: The DUT's internal state machine updates to reflect the system audio mode is enabled.

Disable System Audio

  • Action: Use HdmiCecTx to send a System Audio Mode Request (Off) command from the DUT.
  • Canned Response: Simulate a response indicating the system audio mode has been disabled.
  • Verify: The DUT's internal state machine updates to reflect the system audio mode is disabled.

7. CEC Version Tests

Request CEC Version

  • Action: Use HdmiCecTx to send a Get CEC Version command from the DUT.
  • Canned Response: Simulate a response with the CEC version.
  • Verify: The DUT's internal state machine updates to store the CEC version information.

8. Feature Abort Tests

Unsupported Command Handling

  • Action: Use HdmiCecTx to send an unsupported command from the DUT.
  • Canned Response: Simulate a Feature Abort response.
  • Verify: The DUT logs the Feature Abort command with the appropriate reason for the abort.

5. Identify L3 Negative tests for both Source and Sink profiles

Some examples:

  1. Sending Unsupported commands
  2. Sending expected commands with invalid sender/receiver address
  3. Sending commands with invalid parameters like physical address.
Clone this wiki locally