1CEC-COMPLIANCE(1) User Commands CEC-COMPLIANCE(1)
2
3
4
6 cec-compliance - An application to verify remote CEC devices
7
9 cec-compliance [-h] [-d <dev>] [other options]
10
12 The cec-compliance utility can be used to test how well remote CEC
13 devices comply with the CEC specification. It can also be used to test
14 the local CEC adapter (with the -A option).
15
16 By default it will run through all tests, but if one or more of the
17 feature test options is given, then only those tests will be performed.
18 A set of core tests is always run.
19
20 The CEC adapter needs to be configured before it is used to run tests
21 with cec-compliance. Use cec-ctl for configuration.
22
23 If the CEC adapter has claimed several logical addresses, the test set
24 is run from each logical address in succession. The remote device needs
25 to report a valid physical address in order to run tests on it.
26
27 When running compliance tests, cec-follower should be run on the same
28 adapter. cec-follower will reply to messages that are not handled by
29 cec-compliance. cec-follower will also monitor the device under test
30 for behaviors that are not compliant with the specification. Before
31 each test-run cec-follower should be restarted if it is already run‐
32 ning, to initialize the emulated device with a clean and known initial
33 state.
34
35 Some tests require interactive mode (with the -i option) to confirm
36 that the test passed. When in interactive mode, the user is asked to
37 observe or perform actions on the remote device. Some tests also give
38 conclusive test results when run in interactive mode.
39
40 When testing the local CEC adapter's compliance with the CEC API, there
41 must be at least one remote device present in order to test transmit‐
42 ting and receiving.
43
44 The compliance tests can have several possible outcomes besides passing
45 and failing:
46
47 OK The test passed.
48
49 OK (Unexpected) The test passed, but it was unexpected for
50 the device
51 under test to support it. This might for
52 example occur
53 when a TV replies to messages in the Deck
54 Control
55 feature.
56
57 OK (Not Supported) The feature that was tested is not supported
58 by the
59 device under test, and that feature was not
60 mandatory for
61 the device to pass.
62
63 OK (Presumed) Nothing went wrong during the test, but the
64 test cannot
65 positively verify that the required effects
66 of the test
67 occurred. The test runner should verify that
68 the test
69 passed by manually observing the device under
70 test. This
71 is typically the test result for tests that
72 send
73 messages that are not replied to, but which
74 induce some
75 side effect on the device under test, such as
76 a TV
77 switching to another input or sending a
78 Remote Control
79 command.
80
81 OK (Refused) The device supports the feature or message
82 being tested,
83 but responded <Feature Abort> ["Refused"] to
84 indicate
85 that it cannot perform the given operation.
86 This might
87 for example occur when trying to test the One
88 Touch
89 Record feature on a TV with copy protection
90 enabled.
91
92 FAIL The test failed and was expected to pass on
93 the device.
94
95 OK (Expected Failure) Failed but this was expected. This can only
96 happen
97 if the --expect option was used that speci‐
98 fied
99 that a particular test would return a FAIL
100 result.
101
102 FAIL (Expected X, got Y) The test returned a different result than
103 was expected.
104 This can only happen if the --expect option
105 was used
106 that specified that a particular test would
107 return a specific
108 non-FAIL result.
109
110 Some tests depend on other tests being successful. These are not run if
111 the tests they depend on failed, and they will not be shown in the test
112 listing.
113
115 -d, --device <dev>
116 Use device <dev> as the CEC device. If <dev> is a number, then
117 /dev/cec<dev> is used.
118
119 -D, --driver <drv>
120 Use a cec device that has driver name <drv>, as returned by the
121 CEC_ADAP_G_CAPS ioctl. This option can be combined with -a to
122 uniquely identify a CEC device without having to rely on the
123 device node number.
124
125 -a, --adapter <adap-name>
126 Use a cec device that has adapter name <adap-name>, as returned
127 by the CEC_ADAP_G_CAPS ioctl. This option can be combined with
128 -D to uniquely identify a CEC device without having to rely on
129 the device node number.
130
131 -E, --exit-on-fail
132 Exit this application when the first failure occurs instead of
133 continuing with a possible inconsistent state.
134
135 -l, --list-tests
136 List all tests and the possible test results. This is used by
137 the --expect option.
138
139 -e, --expect <test>=<result>
140 -n, --expect-with-no-warnings <test>=<result> Fail if the test
141 gave a different result. The --list-tests option lists all the
142 possible tests and what result values can be used.
143
144 This can be used in test scripts to verify that a specific
145 result was returned by the test. One use-case is to verify that
146 an optional feature is actually supported, so an OK result
147 instead of an OK (Not Supported) result is expected.
148
149 It can also be used to accept known failures. In that case the
150 test will not fail, but return an OK (Expected Failure) result.
151
152 The --expect-with-no-warnings variant is more strict and will
153 also check that the test produced no warnings.
154
155 -v, --verbose
156 Turn on verbose reporting.
157
158 -w, --wall-clock
159 Show timestamps as wall-clock time. This also turns on verbose
160 reporting.
161
162 -T, --trace
163 Trace all called ioctls. Useful for debugging.
164
165 -h, --help
166 Prints the help message.
167
168 -W, --exit-on-warn
169 Exit this application when the first warning occurs instead of
170 continuing.
171
172 -s, --skip-info
173 Skip the Driver Info output section.
174
175 -C, --color <when>
176 Highlight OK/warn/fail/FAIL strings with colors. OK is marked
177 green, warn is marked bold, and fail/FAIL are marked bright red
178 if enabled. <when> can be always, never, or auto (the default).
179
180 -N, --no-warnings
181 Turn off warning messages.
182
183 -r, --remote <la>
184 As initiator test the remote logical address <la> or all LAs if
185 no LA was given.
186
187 -i, --interactive
188 Interactive mode when doing remote tests.
189
190 -R, --reply-threshold <timeout>
191 Warn if replies take longer than this threshold (default
192 1000ms).
193
194 -t, --timeout <secs>
195 Set the standby/resume timeout to the given number of seconds.
196 Default is 60s.
197
198 -A, --test-adapter
199 Test the CEC adapter API
200
201 -F, --test-fuzzing
202 Test the remote CEC adapter by randomly creating CEC messages.
203 This runs forever until an error occurs.
204
205 --test-core
206 Test the core functionality
207
208 --test-audio-rate-control
209 Test the Audio Rate Control feature
210
211 --test-audio-return-channel-control
212 Test the Audio Return Channel Control feature
213
214 --test-capability-discovery-and-control
215 Test the Capability Discovery and Control feature
216
217 --test-deck-control
218 Test the Deck Control feature
219
220 --test-device-menu-control
221 Test the Device Menu Control feature
222
223 --test-device-osd-transfer
224 Test the Device OSD Transfer feature
225
226 --test-dynamic-audio-lipsync
227 Test the Dynamic Audio Lipsync feature
228
229 --test-osd-display
230 Test the OSD Display feature
231
232 --test-one-touch-play
233 Test the One Touch Play feature
234
235 --test-one-touch-record
236 Test the One Touch Record feature
237
238 --test-power-status
239 Test the Power Status feature
240
241 --test-remote-control-passthrough
242 Test the Remote Control Passthrough feature
243
244 --test-routing-control
245 Test the Routing Control feature
246
247 --test-system-audio-control
248 Test the System Audio Control feature
249
250 --test-system-information
251 Test the System Information feature
252
253 --test-timer-programming
254 Test the Timer Programming feature
255
256 --test-tuner-control
257 Test the Tuner Control feature
258
259 --test-vendor-specific-commands
260 Test the Vendor Specific Commands feature
261
262 --test-standby-resume
263 Test standby and resume functionality. This will activate test‐
264 ing of Standby, Give Device Power Status and One Touch Play.
265
266
268 On success, it returns 0. Otherwise, it will return the error code.
269
271 We want to test the compliance of a TV when it is interacting with a
272 Playback device. The device node of the CEC adapter which the TV is
273 connected to is /dev/cec1.
274
275 The local CEC adapter first needs to be configured as a Playback
276 device, and it must have an appropriate physical address. It is impor‐
277 tant that the physical address is correct, so as to not confuse the
278 device under test. For example, if the CEC adapter is connected to the
279 first input of the TV, the physical address 1.0.0.0 should generally be
280 used.
281
282 cec-ctl -d1 --playback --phys-addr 1.0.0.0
283
284 Most CEC adapters will automatically detect the physical address, and
285 for those adapters the --phys-addr option is not needed.
286
287 Next, cec-follower also has to be started on the same device:
288
289 cec-follower -d1
290
291 cec-compliance can now be run towards the TV by supplying the -r option
292 with the logical address 0:
293
294 cec-compliance -d1 -r0
295
297 This manual page is a work in progress.
298
299 Bug reports or questions about this utility should be sent to the
300 linux-media@vger.kernel.org mailinglist.
301
303 cec-follower(1), cec-ctl(1)
304
305
306
307v4l-utils 1.20.0 August 2016 CEC-COMPLIANCE(1)