-
Notifications
You must be signed in to change notification settings - Fork 2
HDMI CEC vComponent ‐ Roadmap items
- 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.
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
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 likeReport 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:
-
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")
-
-
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)
-
-
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.
-
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")
-
-
Example Response:
-
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")
-
-
Example Response:
-
Command:
50:72:01
(Set Audio Mode On) -
Expected Responses:
-
Example Response:
-
50:7E:01
(Audio mode confirmed)
-
-
Example Response:
-
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)
-
-
Example Response:
-
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.
-
Example Response:
-
Command:
20:08
(TV requests status from Tuner 1) -
Expected Responses:
-
Example Response:
-
20:09:80
(Tuner 1 responds with status information)
-
-
Example Response:
-
Command:
0F:85
(Request current active source) -
Expected Responses:
-
Example Response:
-
40:82:10:00
(TV responds with its current active source)
-
-
Example Response:
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.
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.
-
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
orText View On
command.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Action: Use
HdmiCecTx
to send aText View On
orImage 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.
-
Action: Use
HdmiCecTx
to send aStandby
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.
-
Action: Use
HdmiCecTx
to send anActive 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.
-
Action: Use
HdmiCecTx
to send aUser 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.
-
Action: Use
HdmiCecTx
to send aUser 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.
-
Action: Use
HdmiCecTx
to send aUser 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.
-
Action: Use
HdmiCecTx
to send aGive 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.
-
Action: Use
HdmiCecTx
to send aRouting 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.
-
Action: Use
HdmiCecTx
to send aSystem 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.
-
Action: Use
HdmiCecTx
to send aSystem 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.
-
Action: Use
HdmiCecTx
to send aGet 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.
-
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.
Some examples:
- Sending Unsupported commands
- Sending expected commands with invalid sender/receiver address
- Sending commands with invalid parameters like physical address.