home | help 
CEC-COMPLIANCE(1)		  User Commands 	       CEC-COMPLIANCE(1)

NAME
     cec-compliance - An application to verify remote CEC devices

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

DESCRIPTION
     The  cec-compliance utility can be used to test how well remote CEC devices
     comply with the CEC specification. It can also be used to	test  the  local
     CEC adapter (with the -A option).

     By default it will run through all tests, but if one or more of the feature
     test  options  is	given, then only those tests will be performed. A set of
     core tests is always run.

     The CEC adapter needs to be configured before it is used to run tests  with
     cec-compliance. Use cec-ctl for configuration.

     If  the  CEC adapter has claimed several logical addresses, the test set is
     run from each logical address in succession. The remote device needs to re-
     port a valid physical address in order to run tests on it.

     When running compliance tests, cec-follower  should  be  run  on  the  same
     adapter.  cec-follower  will reply to messages that are not handled by cec-
     compliance. cec-follower will also monitor the device under test for behav-
     iors that are not compliant with the specification.  Before  each	test-run
     cec-follower  should  be  restarted if it is already running, to initialize
     the emulated device with a clean and known initial state.

     Some tests require interactive mode (with the -i option)  to  confirm  that
     the  test passed. When 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.

     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.

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

	 OK		       The test passed.

	 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.

	 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.

	 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 in-
     duce some
			       side effect on the device under test, such  as  a
     TV
			       switching  to  another  input or sending a Remote
     Control
			       command.

	 OK (Refused)	       The device supports the feature or message  being
     tested,
			       but  responded <Feature Abort> ["Refused"] to in-
     dicate
			       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  en-
     abled.

	 FAIL			The  test failed and was expected to pass on the
     device.

	 OK (Expected Failure) Failed but this was expected. This can only  hap-
     pen
			       if the --expect option was used that specified
			       that  a	particular  test would return a FAIL re-
     sult.

	 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  re-
     turn a specific
			       non-FAIL result.

     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 list-
     ing.

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.

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

     -E, --exit-on-fail
	    Exit  this application when the first failure occurs instead of con-
	    tinuing with a possible inconsistent state.

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

	    The  --expect-with-no-warnings  variant is more strict and will also
	    check that the test produced no warnings.

     -v, --verbose
	    Turn on verbose reporting.

     --version
	    Show version information.

     -w, --wall-clock
	    Show timestamps as wall-clock time. This also turns on  verbose  re-
	    porting.

     -T, --trace
	    Trace all called ioctls. Useful for debugging.

     -h, --help
	    Prints the help message.

     -W, --exit-on-warn
	    Exit  this application when the first warning occurs instead of con-
	    tinuing.

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

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

     -R, --reply-threshold <timeout>
	    Warn if replies take longer than this threshold (default 1000ms).

     -t, --timeout <secs>
	    Set  the  standby/resume timeout to the given number of seconds. De-
	    fault 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.

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

EXIT STATUS
     On success, it returns 0. Otherwise, it will return the error code.

EXAMPLE
     We want to test the compliance of a TV when it is interacting with a  Play-
     back  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.

     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

BUGS
     This manual page is a work in progress.

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

SEE ALSO
     cec-follower(1), cec-ctl(1)

v4l-utils 1.23.0		   August 2016		       CEC-COMPLIANCE(1)
home | help