The name of ivi_controller_interface is changed to ivi_layout_interface
with this patch.
This name is better suited to the interface, because it is implemented
in ivi-layout.c and its methods are linked to ivi_layout* functions.
Furthermore, the controller modules (e.g. hmi-controller) are the users
of this interface and they have their own interfaces,
which are called *_controller_interface,
e.g.: ivi_hmi_controller_interface.
This causes confusion about the software architecture.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Tested-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
These tests are implemented on test suite framework, which provides
helper client.
Following features are tested,
- add notfication of ivi-surface with bad condition
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
These tests are implemented on test suite framework, which provides
helper client.
Following features are tested,
- notification of adding ivi-surface
- notification of ivi-surface configure
- notification of creating ivi-surface
- notification of removing ivi-surface
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
The TESTs in ivi_layout-test.c may have several server-side parts
(RUNNER_TEST in ivi_layout-test-plugin.c) each. Sometimes we need to
carry state from one RUNNER_TEST to another within one TEST, but not
across multiple TESTs. The correct lifetime of that state would be the
lifetime (and identity) of the runner_resource, as one TEST creates and
uses at most one weston_test_runner during its lifetime.
However, tests are executed one by one. Take a shortcut, and use a static
global for storing that state. This turns the test_context into a
singleton. To ensure it is not confused between multiple TESTs, add
asserts to verify its identity.
Following patches will add tests for notification callbacks. These will
be using the carried state.
[Pekka: add serialization checks, rename the global, rewrite commit message.]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
These tests are implemented on test suite framework, which provides
helper client.
Following features are tested,
- bad render order of ivi-surface on ivi-layer
- call commitchanges after a ivi_surface in render order is destoryed
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
These test are implemented on test suite framework, which provides
helper client.
Following features are tested,
- render order of ivi-surfaces on ivi-layer
Signed-off-by: Nobuhiko Tanibata <nobuhiko_tanibata@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
These tests are implemented on test suite framework, which provides
helper client.
Following features are tested,
- ivi_layout_runner with basic_test_names[]
- surface with bad opacity
- destroy ivi/wl_surface and call get_surface
- commit_changes_after_properties_set_surface_destroy with
surface_property_commit_changes_test_names[]
- call set_visibility, destroy ivi-surface, and commit_changes
- call set_opacity, destroy ivi-surface, and commit_changes
- call set_orientation, destroy ivi-surface, and commit_changes
- call set_dimension, destroy ivi-surface, and commit_changes
- call set_position, destroy ivi-surface, and commit_changes
- call set_source_rectangle, destroy ivi-surface, and commit_changes
- call set_destination_rectangle, destroy ivi-surface, and
commit_changes
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
These tests are implemented on test suite framework, which provides
helper client.
Following features are tested for ivi-surface
- orientation
- dimension
- position
- destination rectangle
- source rectangle
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
Removed duplicate definitions of the container_of() macro and
refactored sources to use the single implementation.
Signed-off-by: Jon A. Cruz <jonc@osg.samsung.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Using the parent '../' path component in #include statements makes
the codebase more rigid and is redundant due to proper -I use.
Signed-off-by: Jon A. Cruz <jonc@osg.samsung.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Testing the ivi_layout API requires two things:
- the tests must be written as a controller module to access the API
- the tests need a helper client to create some objects that can then be
managed via the API
This patch adds all the infrastructure and two different kinds of
example tests.
Internal ivi-shell (ivi_layout) API tests are listed as ivi-*.la files
in TESTS in Makefile.am. Weston-tests-env detects these, and runs Weston
with ivi-shell, and loads the given module as a controller module, not
as a normal plugin.
The test controller module ivi-*.la will launch a helper client. For
ivi-layout-test.la the helper client is ivi-layout.ivi.
The helper client uses the weston-test-runner framework to fork and exec
each TEST with a fresh connection to the compositor.
The actual test is triggered by the weston_test_runner protocol
interface, a new addition to weston-test.xml. The helper client uses
weston_test_runner to trigger a test, and the server side of the
interface is implemented by the test controller module
(ivi-layout-test.la).
The server side of weston_test_runner uses the same trick as
weston-test-runner.h to gather a list of defined tests. A test is
defined with the RUNNER_TEST macro.
If a test defined by RUNNER_TEST succeeds, an event is sent to the
helper client that it can continue (or exit). If a test fails, a fatal
protocol error is sent to the helper client.
Once the helper client has iterated over all of its tests, it signals
the batch success/failure via process exit code. That is cought in the
test controller module, and forwarded as Weston's exit code.
In summary: each ivi_layout test is a combination of a client side
helper/setup and server side actual tests.
v2: Load weston-test.so, because create_client() needs it.
v3: add a comment about IVI_TEST_SURFACE_ID_BASE.
v4: Rebased to upstream weston-tests-env changes.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com> (v2)
