CEC-COMPLIANCE(1)

🌈 cec-compliance 🌈 — User Commands, but make it a vibe

okay so bestie, welcome to cec-compliance(1) — the little utility whose entire job is checking whether your remote CEC devices actually behave like the spec says they should. it's giving ✨compliance girlie✨ and honestly she eats. let's get into it 💅

---

✨ NAME ✨

cec-compliance — an application to verify remote CEC devices 🦋

---

✨ SYNOPSIS ✨

cec-compliance [-h] [-d <dev>] [other options]

---

✨ DESCRIPTION ✨

so, the cec-compliance utility is what you use to test how well remote CEC devices comply with the CEC specification. no cap. it can also be used to test the local CEC adapter itself — that's the -A option, and yes she contains multitudes 💖

By default it will run through all the tests. but if you give it one or more of the feature test options, then only those tests get performed. a set of core tests is always run though — those ones are non-negotiable, main character energy only 👑

The CEC adapter needs to be configured before you use it to run tests with cec-compliance. use cec-ctl for configuration. (yes, that's a different manpage, go read it, i'll wait 🫶)

If the CEC adapter has claimed several logical addresses, the test set is run from each logical address in succession. and the remote device needs to report a valid physical address in order to run tests on it — no address, no tests, that's the rule 🚫

When running compliance tests, cec-follower should be run on the same adapter. why? because cec-follower will reply to messages that are not handled by cec-compliance, and it will also monitor the device under test for behaviors that are not compliant with the specification. she's the backup dancer AND the security camera 💀 Before each test-run, cec-follower should be restarted if it is already running, so the emulated device gets initialized with a clean and known initial state. fresh start, fresh vibes, you know how it is 🌸

Some tests require interactive mode (with the -i option) to confirm that the test passed. when you're in interactive mode, the user is asked to observe or perform actions on the remote device. some tests also give conclusive test results when run in interactive mode — so like, sometimes you gotta be there in person for the plot to resolve 🎀

When testing the local CEC adapter's compliance with the CEC API, there must be at least one remote device present in order to test transmitting and receiving. literally cannot test talking to nobody, that's just screaming into the void 😭

---

🧚 the possible outcomes (vibe check results)

The compliance tests can have several possible outcomes besides passing and failing:

• OK — the test passed. slay 💅
• OK (Unexpected) — the test passed, but it was unexpected for the device under test to support it. this might for example occur when a TV replies to messages in the Deck Control feature. not mad, just surprised 🙈
• OK (Not Supported) — the feature that was tested is not supported by the device under test, and that feature was not mandatory for the device to pass. so like, it's fine, it's allowed ✨
• OK (Presumed) — nothing went wrong during the test, but the test cannot positively verify that the required effects of the test occurred. the test runner should verify that the test passed by manually observing the device under test. this is typically the test result for tests that send messages that are not replied to, but which induce some side effect on the device under test, such as a TV switching to another input or sending a Remote Control command. tl;dr: trust me bro, go look with your eyeballs 👀
• OK (Refused) — the device supports the feature or message being tested, but responded <Feature Abort> ["Refused"] to indicate that it cannot perform the given operation. this might for example occur when trying to test the One Touch Record feature on a TV with copy protection enabled. she said no and that's valid 🚫
• FAIL — the test failed and was expected to pass on the device. 😭
• OK (Expected Failure) — failed but this was expected. this can only happen if the --expect option was used that specified that a particular test would return a FAIL result. we called it, we accept it 🫶
• FAIL (Expected X, got Y) — the test returned a different result than was expected. this can only happen if the --expect option was used that specified that a particular test would return a specific non-FAIL result. the plot twist nobody asked for 💀

Some tests depend on other tests being successful. these are not run if the tests they depend on failed, and they will not be shown in the test listing. no skipping ahead in the syllabus, bestie 📚

---

✨ OPTIONS ✨

• -d, --device <dev> — use device <dev> as the CEC device. if <dev> is a number, then /dev/cec<dev> is used.
• -D, --driver <drv> — use a cec device that has driver name <drv>, as returned by the CEC_ADAP_G_CAPS ioctl. this option can be combined with -a to uniquely identify a CEC device without having to rely on the device node number. iconic duo behavior 🤝
• -a, --adapter <adap-name> — use a cec device that has adapter name <adap-name>, as returned by the CEC_ADAP_G_CAPS ioctl. this option can be combined with -D to uniquely identify a CEC device without having to rely on the device node number. yeah, same energy, other half of the duo 💞
• -E, --exit-on-fail — exit this application when the first failure occurs instead of continuing with a possible inconsistent state. we're leaving the party the second things get weird 🚪
• -l, --list-tests — list all tests and the possible test results. this is used by the --expect option.
• -e, --expect <test>=<result> / -n, --expect-with-no-warnings <test>=<result> — fail if the test gave a different result. the --list-tests option lists all the possible tests and what result values can be used.

this can be used in test scripts to verify that a specific result was returned by the test. one use-case is to verify that an optional feature is actually supported, so an OK result instead of an OK (Not Supported) result is expected. 🎯

it can also be used to accept known failures. in that case the test will not fail, but return an OK (Expected Failure) result. we forgive her 💖

the --expect-with-no-warnings variant is more strict and will also check that the test produced no warnings. she's watching you like a hawk 👁️

• -v, --verbose — turn on verbose reporting. spill the tea, tell me everything ☕
• --version — show version information.
• -w, --wall-clock — show timestamps as wall-clock time.
• -S, --show-timestamp — for each test, show the timestamp of when the test started. ⏰
• -T, --trace — trace all called ioctls. useful for debugging. detective mode activated 🔍
• -h, --help — prints the help message.
• -W, --exit-on-warn — exit this application when the first warning occurs instead of continuing. one yellow flag and we're out 🏃♀️
• -s, --skip-info — skip the Driver Info output section.
• -C, --color <when> — highlight OK/warn/fail/FAIL strings with colors. OK is marked green, warn is marked bold, and fail/FAIL are marked bright red if enabled. <when> can be always, never, or auto (the default). aesthetic matters 🌈
• -N, --no-warnings — turn off warning messages.
• -r, --remote <la> — as initiator test the remote logical address <la> or all LAs if no LA was given.
• -i, --interactive — interactive mode when doing remote tests. you're part of the test now bestie 🫵
• -R, --reply-threshold <timeout> — warn if replies take longer than this threshold (default 1000ms). we are timing her 📱
• -t, --timeout <secs> — set the standby/resume timeout to the given number of seconds. default is 60s. 🛌
• -A, --test-adapter — test the CEC adapter API
• -F, --test-fuzzing — test the remote CEC adapter by randomly creating CEC messages. this runs forever until an error occurs. forever?? FOREVER. good luck 🌀💀
• --test-core — test the core functionality
• --test-audio-rate-control — test the Audio Rate Control feature
• --test-audio-return-channel-control — test the Audio Return Channel Control feature
• --test-capability-discovery-and-control — test the Capability Discovery and Control feature
• --test-deck-control — test the Deck Control feature
• --test-device-menu-control — test the Device Menu Control feature
• --test-device-osd-transfer — test the Device OSD Transfer feature
• --test-dynamic-audio-lipsync — test the Dynamic Audio Lipsync feature
• --test-osd-display — test the OSD Display feature
• --test-one-touch-play — test the One Touch Play feature
• --test-one-touch-record — test the One Touch Record feature
• --test-power-status — test the Power Status feature
• --test-remote-control-passthrough — test the Remote Control Passthrough feature
• --test-routing-control — test the Routing Control feature
• --test-system-audio-control — test the System Audio Control feature
• --test-system-information — test the System Information feature
• --test-timer-programming — test the Timer Programming feature
• --test-tuner-control — test the Tuner Control feature
• --test-vendor-specific-commands — test the Vendor Specific Commands feature
• --test-standby-resume — test standby and resume functionality. this will activate testing of Standby, Give Device Power Status and One Touch Play. the triple threat 💅

---

✨ EXIT STATUS ✨

On success, it returns 0. otherwise, it will return the error code. zero or she's telling you exactly what went wrong, no cryptic nonsense 🫶

---

✨ EXAMPLE ✨

okay picture this: we want to test the compliance of a TV when it is interacting with a Playback device. the device node of the CEC adapter which the TV is connected to is /dev/cec1.

The local CEC adapter first needs to be configured as a Playback device, and it must have an appropriate physical address. it is important that the physical address is correct, so as to not confuse the device under test. for example, if the CEC adapter is connected to the first input of the TV, the physical address 1.0.0.0 should generally be used.

cec-ctl -d1 --playback --phys-addr 1.0.0.0

Most CEC adapters will automatically detect the physical address, and for those adapters the --phys-addr option is not needed. she already knows where she is 🧭

Next, cec-follower also has to be started on the same device:

cec-follower -d1

cec-compliance can now be run towards the TV by supplying the -r option with the logical address 0:

cec-compliance -d1 -r0

and that's it. go get your results bestie 🎉

---

✨ BUGS ✨

This manual page is a work in progress. (relatable, honestly 🚧)

Bug reports or questions about this utility should be sent to the linux-media@vger.kernel.org mailinglist. 📬

---

✨ SEE ALSO ✨

• cec-follower(1)
• cec-ctl(1)

---

and that's the whole page, bestie 💖 this one shipped as v4l-utils 1.32.0, back in August 2016 — old but still absolutely serving. mwah, go forth and verify some remote CEC devices ✨🎀🦋