1CEC-COMPLIANCE(1)                User Commands               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
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

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
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

EXIT STATUS

268       On success, it returns 0. Otherwise, it will return the error code.
269

EXAMPLE

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

BUGS

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

SEE ALSO

303       cec-follower(1), cec-ctl(1)
304
305
306
307v4l-utils 1.20.0                  August 2016                CEC-COMPLIANCE(1)
Impressum