1CEC-COMPLIANCE(1)                  1.25.0""                  CEC-COMPLIANCE(1)
2
3
4

NAME

6       cec-compliance - An application to verify remote CEC devices
7

SYNOPSIS

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

DESCRIPTION

12       The  cec-compliance utility can be used to test how well remote CEC de‐
13       vices 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 ex‐
52       ample 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  Re‐
78       mote 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

OPTIONS

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 de‐
123              vice 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  re‐
145              sult was returned by the test. One use-case is to verify that an
146              optional feature is actually supported, so an OK result  instead
147              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       --version
159              Show version information.
160
161       -w, --wall-clock
162              Show  timestamps  as wall-clock time. This also turns on verbose
163              reporting.
164
165       -T, --trace
166              Trace all called ioctls. Useful for debugging.
167
168       -h, --help
169              Prints the help message.
170
171       -W, --exit-on-warn
172              Exit this application when the first warning occurs  instead  of
173              continuing.
174
175       -s, --skip-info
176              Skip the Driver Info output section.
177
178       -C, --color <when>
179              Highlight  OK/warn/fail/FAIL  strings  with colors. OK is marked
180              green, warn is marked bold, and fail/FAIL are marked bright  red
181              if enabled. <when> can be always, never, or auto (the default).
182
183       -N, --no-warnings
184              Turn off warning messages.
185
186       -r, --remote <la>
187              As  initiator test the remote logical address <la> or all LAs if
188              no LA was given.
189
190       -i, --interactive
191              Interactive mode when doing remote tests.
192
193       -R, --reply-threshold <timeout>
194              Warn  if  replies  take  longer  than  this  threshold  (default
195              1000ms).
196
197       -t, --timeout <secs>
198              Set  the  standby/resume timeout to the given number of seconds.
199              Default is 60s.
200
201       -A, --test-adapter
202              Test the CEC adapter API
203
204       -F, --test-fuzzing
205              Test the remote CEC adapter by randomly creating  CEC  messages.
206              This runs forever until an error occurs.
207
208       --test-core
209              Test the core functionality
210
211       --test-audio-rate-control
212              Test the Audio Rate Control feature
213
214       --test-audio-return-channel-control
215              Test the Audio Return Channel Control feature
216
217       --test-capability-discovery-and-control
218              Test the Capability Discovery and Control feature
219
220       --test-deck-control
221              Test the Deck Control feature
222
223       --test-device-menu-control
224              Test the Device Menu Control feature
225
226       --test-device-osd-transfer
227              Test the Device OSD Transfer feature
228
229       --test-dynamic-audio-lipsync
230              Test the Dynamic Audio Lipsync feature
231
232       --test-osd-display
233              Test the OSD Display feature
234
235       --test-one-touch-play
236              Test the One Touch Play feature
237
238       --test-one-touch-record
239              Test the One Touch Record feature
240
241       --test-power-status
242              Test the Power Status feature
243
244       --test-remote-control-passthrough
245              Test the Remote Control Passthrough feature
246
247       --test-routing-control
248              Test the Routing Control feature
249
250       --test-system-audio-control
251              Test the System Audio Control feature
252
253       --test-system-information
254              Test the System Information feature
255
256       --test-timer-programming
257              Test the Timer Programming feature
258
259       --test-tuner-control
260              Test the Tuner Control feature
261
262       --test-vendor-specific-commands
263              Test the Vendor Specific Commands feature
264
265       --test-standby-resume
266              Test  standby and resume functionality. This will activate test‐
267              ing of Standby, Give Device Power Status and One Touch Play.
268
269

EXIT STATUS

271       On success, it returns 0. Otherwise, it will return the error code.
272

EXAMPLE

274       We want to test the compliance of a TV when it is  interacting  with  a
275       Playback  device.  The  device  node of the CEC adapter which the TV is
276       connected to is /dev/cec1.
277
278       The local CEC adapter first needs to be configured as  a  Playback  de‐
279       vice, and it must have an appropriate physical address. It is important
280       that the physical address is correct, so as to not confuse  the  device
281       under  test.  For example, if the CEC adapter is connected to the first
282       input of the TV, the physical address 1.0.0.0 should generally be used.
283
284           cec-ctl -d1 --playback --phys-addr 1.0.0.0
285
286       Most CEC adapters will automatically detect the physical  address,  and
287       for those adapters the --phys-addr option is not needed.
288
289       Next, cec-follower also has to be started on the same device:
290
291           cec-follower -d1
292
293       cec-compliance can now be run towards the TV by supplying the -r option
294       with the logical address 0:
295
296           cec-compliance -d1 -r0
297

BUGS

299       This manual page is a work in progress.
300
301       Bug reports or questions about this  utility  should  be  sent  to  the
302       linux-media@vger.kernel.org mailinglist.
303

SEE ALSO

305       cec-follower(1), cec-ctl(1)
306
307
308
309v4l-utils                         August 2016                CEC-COMPLIANCE(1)
Impressum