tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
/*
|
|
|
|
* Copyright © 2012 Intel Corporation
|
|
|
|
* Copyright © 2013 DENSO CORPORATION
|
|
|
|
* Copyright © 2015 Collabora, Ltd.
|
|
|
|
*
|
2015-06-12 01:39:40 +03:00
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining
|
|
|
|
* a copy of this software and associated documentation files (the
|
|
|
|
* "Software"), to deal in the Software without restriction, including
|
|
|
|
* without limitation the rights to use, copy, modify, merge, publish,
|
|
|
|
* distribute, sublicense, and/or sell copies of the Software, and to
|
|
|
|
* permit persons to whom the Software is furnished to do so, subject to
|
|
|
|
* the following conditions:
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
*
|
2015-06-12 01:39:40 +03:00
|
|
|
* The above copyright notice and this permission notice (including the
|
|
|
|
* next paragraph) shall be included in all copies or substantial
|
|
|
|
* portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
|
|
|
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
|
|
|
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
|
|
|
|
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
|
|
|
|
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
|
|
|
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
|
|
* SOFTWARE.
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
|
2016-07-19 14:16:27 +03:00
|
|
|
#include <stdint.h>
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
#include <unistd.h>
|
|
|
|
#include <signal.h>
|
|
|
|
#include <string.h>
|
2015-06-22 09:35:49 +03:00
|
|
|
#include <assert.h>
|
2016-11-24 23:45:45 +03:00
|
|
|
#include <limits.h>
|
2019-04-27 00:57:31 +03:00
|
|
|
#include <errno.h>
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
2019-03-28 17:28:47 +03:00
|
|
|
#include <libweston/libweston.h>
|
2016-06-03 16:45:21 +03:00
|
|
|
#include "compositor/weston.h"
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
#include "weston-test-server-protocol.h"
|
|
|
|
#include "ivi-test.h"
|
2015-06-16 01:37:07 +03:00
|
|
|
#include "ivi-shell/ivi-layout-export.h"
|
2015-06-16 01:37:10 +03:00
|
|
|
#include "shared/helpers.h"
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
|
|
|
struct test_context;
|
|
|
|
|
|
|
|
struct runner_test {
|
|
|
|
const char *name;
|
|
|
|
void (*run)(struct test_context *);
|
|
|
|
} __attribute__ ((aligned (32)));
|
|
|
|
|
|
|
|
#define RUNNER_TEST(name) \
|
|
|
|
static void runner_func_##name(struct test_context *); \
|
|
|
|
\
|
|
|
|
const struct runner_test runner_test_##name \
|
2019-11-11 16:18:51 +03:00
|
|
|
__attribute__ ((section ("plugin_test_section"))) = \
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
{ \
|
|
|
|
#name, runner_func_##name \
|
|
|
|
}; \
|
|
|
|
\
|
|
|
|
static void runner_func_##name(struct test_context *ctx)
|
|
|
|
|
2019-11-11 16:18:51 +03:00
|
|
|
extern const struct runner_test __start_plugin_test_section;
|
|
|
|
extern const struct runner_test __stop_plugin_test_section;
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
|
|
|
static const struct runner_test *
|
|
|
|
find_runner_test(const char *name)
|
|
|
|
{
|
|
|
|
const struct runner_test *t;
|
|
|
|
|
2019-11-11 16:18:51 +03:00
|
|
|
for (t = &__start_plugin_test_section;
|
|
|
|
t < &__stop_plugin_test_section; t++) {
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
if (strcmp(t->name, name) == 0)
|
|
|
|
return t;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2015-06-22 09:35:49 +03:00
|
|
|
struct test_context {
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *layout_interface;
|
2015-06-22 09:35:49 +03:00
|
|
|
struct wl_resource *runner_resource;
|
2015-06-22 09:35:58 +03:00
|
|
|
uint32_t user_flags;
|
2016-04-04 11:05:03 +03:00
|
|
|
|
|
|
|
struct wl_listener surface_property_changed;
|
2016-04-04 11:05:09 +03:00
|
|
|
struct wl_listener surface_created;
|
2016-04-04 11:05:18 +03:00
|
|
|
struct wl_listener surface_removed;
|
2016-04-04 11:05:20 +03:00
|
|
|
struct wl_listener surface_configured;
|
2015-06-22 09:35:49 +03:00
|
|
|
};
|
|
|
|
|
2019-11-05 17:32:18 +03:00
|
|
|
struct test_launcher {
|
|
|
|
struct weston_compositor *compositor;
|
|
|
|
struct test_context context;
|
|
|
|
const struct ivi_layout_interface *layout_interface;
|
|
|
|
};
|
2015-06-22 09:35:49 +03:00
|
|
|
|
|
|
|
static void
|
|
|
|
destroy_runner(struct wl_resource *resource)
|
|
|
|
{
|
2019-11-05 17:32:18 +03:00
|
|
|
struct test_launcher *launcher = wl_resource_get_user_data(resource);
|
|
|
|
struct test_context *ctx = &launcher->context;
|
2015-06-22 09:35:49 +03:00
|
|
|
|
2019-11-05 17:32:18 +03:00
|
|
|
assert(ctx->runner_resource == NULL ||
|
|
|
|
ctx->runner_resource == resource);
|
|
|
|
|
|
|
|
ctx->layout_interface = NULL;
|
|
|
|
ctx->runner_resource = NULL;
|
2015-06-22 09:35:49 +03:00
|
|
|
}
|
|
|
|
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
static void
|
|
|
|
runner_destroy_handler(struct wl_client *client, struct wl_resource *resource)
|
|
|
|
{
|
|
|
|
wl_resource_destroy(resource);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
runner_run_handler(struct wl_client *client, struct wl_resource *resource,
|
|
|
|
const char *test_name)
|
|
|
|
{
|
|
|
|
struct test_launcher *launcher;
|
|
|
|
const struct runner_test *t;
|
2019-11-05 17:32:18 +03:00
|
|
|
struct test_context *ctx;
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
|
|
|
launcher = wl_resource_get_user_data(resource);
|
2019-11-05 17:32:18 +03:00
|
|
|
ctx = &launcher->context;
|
|
|
|
|
|
|
|
assert(ctx->runner_resource == NULL ||
|
|
|
|
ctx->runner_resource == resource);
|
|
|
|
|
|
|
|
ctx->layout_interface = launcher->layout_interface;
|
|
|
|
ctx->runner_resource = resource;
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
|
|
|
t = find_runner_test(test_name);
|
|
|
|
if (!t) {
|
|
|
|
weston_log("Error: runner test \"%s\" not found.\n",
|
|
|
|
test_name);
|
|
|
|
wl_resource_post_error(resource,
|
|
|
|
WESTON_TEST_RUNNER_ERROR_UNKNOWN_TEST,
|
|
|
|
"weston_test_runner: unknown: '%s'",
|
|
|
|
test_name);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
weston_log("weston_test_runner.run(\"%s\")\n", test_name);
|
|
|
|
|
2019-11-05 17:32:18 +03:00
|
|
|
t->run(ctx);
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
|
|
|
weston_test_runner_send_finished(resource);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct weston_test_runner_interface runner_implementation = {
|
|
|
|
runner_destroy_handler,
|
|
|
|
runner_run_handler
|
|
|
|
};
|
|
|
|
|
|
|
|
static void
|
|
|
|
bind_runner(struct wl_client *client, void *data,
|
|
|
|
uint32_t version, uint32_t id)
|
|
|
|
{
|
|
|
|
struct test_launcher *launcher = data;
|
|
|
|
struct wl_resource *resource;
|
|
|
|
|
|
|
|
resource = wl_resource_create(client, &weston_test_runner_interface,
|
|
|
|
1, id);
|
|
|
|
if (!resource) {
|
|
|
|
wl_client_post_no_memory(client);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
wl_resource_set_implementation(resource, &runner_implementation,
|
2015-06-22 09:35:49 +03:00
|
|
|
launcher, destroy_runner);
|
|
|
|
|
2019-11-05 17:32:18 +03:00
|
|
|
if (launcher->context.runner_resource != NULL) {
|
2015-06-22 09:35:49 +03:00
|
|
|
weston_log("test FATAL: "
|
|
|
|
"attempting to run several tests in parallel.\n");
|
|
|
|
wl_resource_post_error(resource,
|
|
|
|
WESTON_TEST_RUNNER_ERROR_TEST_FAILED,
|
|
|
|
"attempt to run parallel tests");
|
|
|
|
}
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
WL_EXPORT int
|
2018-01-25 16:36:13 +03:00
|
|
|
wet_module_init(struct weston_compositor *compositor,
|
|
|
|
int *argc, char *argv[])
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
{
|
|
|
|
struct test_launcher *launcher;
|
2018-01-25 16:36:13 +03:00
|
|
|
const struct ivi_layout_interface *iface;
|
|
|
|
|
|
|
|
iface = ivi_layout_get_api(compositor);
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
2018-01-25 16:36:13 +03:00
|
|
|
if (!iface) {
|
|
|
|
weston_log("fatal: cannot use ivi_layout_interface.\n");
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
launcher = zalloc(sizeof *launcher);
|
|
|
|
if (!launcher)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
launcher->compositor = compositor;
|
2015-10-15 17:51:41 +03:00
|
|
|
launcher->layout_interface = iface;
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
|
|
|
if (wl_global_create(compositor->wl_display,
|
|
|
|
&weston_test_runner_interface, 1,
|
|
|
|
launcher, bind_runner) == NULL)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
runner_assert_fail(const char *cond, const char *file, int line,
|
|
|
|
const char *func, struct test_context *ctx)
|
|
|
|
{
|
|
|
|
weston_log("Assert failure in %s:%d, %s: '%s'\n",
|
|
|
|
file, line, func, cond);
|
2015-06-22 09:35:49 +03:00
|
|
|
|
|
|
|
assert(ctx->runner_resource);
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
wl_resource_post_error(ctx->runner_resource,
|
|
|
|
WESTON_TEST_RUNNER_ERROR_TEST_FAILED,
|
|
|
|
"Assert failure in %s:%d, %s: '%s'\n",
|
|
|
|
file, line, func, cond);
|
|
|
|
}
|
|
|
|
|
|
|
|
#define runner_assert(cond) ({ \
|
|
|
|
bool b_ = (cond); \
|
|
|
|
if (!b_) \
|
|
|
|
runner_assert_fail(#cond, __FILE__, __LINE__, \
|
|
|
|
__func__, ctx); \
|
|
|
|
b_; \
|
|
|
|
})
|
|
|
|
|
|
|
|
#define runner_assert_or_return(cond) do { \
|
|
|
|
bool b_ = (cond); \
|
|
|
|
if (!b_) { \
|
|
|
|
runner_assert_fail(#cond, __FILE__, __LINE__, \
|
|
|
|
__func__, ctx); \
|
|
|
|
return; \
|
|
|
|
} \
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
|
|
|
|
/*************************** tests **********************************/
|
|
|
|
|
|
|
|
/*
|
2019-11-11 16:30:07 +03:00
|
|
|
* This is a IVI controller module requiring ivi-shell.so.
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
* This module is specially written to execute tests that target the
|
|
|
|
* ivi_layout API.
|
|
|
|
*
|
2019-11-11 16:30:07 +03:00
|
|
|
* The test program containing the fixture setup and initiating the tests is
|
|
|
|
* test-ivi-layout-client (ivi-layout-test-client.c).
|
|
|
|
* That program uses the weston-test-runner framework to execute each TEST()
|
|
|
|
* in ivi-layout-test-client.c with a fresh connection to the single
|
|
|
|
* compositor instance.
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
*
|
2016-11-28 18:54:06 +03:00
|
|
|
* Each TEST() in ivi-layout-test-client.c will bind to weston_test_runner global
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
* interface. A TEST() will set up the client state, and issue
|
|
|
|
* weston_test_runner.run request to execute the compositor-side of the test.
|
|
|
|
*
|
|
|
|
* The compositor-side parts of the tests are in this file. They are specified
|
|
|
|
* by RUNNER_TEST() macro, where the name argument matches the name string
|
|
|
|
* passed to weston_test_runner.run.
|
|
|
|
*
|
|
|
|
* A RUNNER_TEST() function simply returns when it succeeds. If it fails,
|
|
|
|
* a fatal protocol error is sent to the client from runner_assert() or
|
2019-11-11 16:30:07 +03:00
|
|
|
* runner_assert_or_return().
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
*
|
2016-11-28 18:54:06 +03:00
|
|
|
* A single TEST() in ivi-layout-test-client.c may use multiple RUNNER_TEST()s to
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
* achieve multiple test points over a client action sequence.
|
|
|
|
*/
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_create_p1)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
struct ivi_layout_surface *ivisurf[2];
|
|
|
|
uint32_t ivi_id;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf[0] = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert(ivisurf[0]);
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf[1] = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(1));
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert(ivisurf[1]);
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivi_id = lyt->get_id_of_surface(ivisurf[0]);
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert(ivi_id == IVI_TEST_SURFACE_ID(0));
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivi_id = lyt->get_id_of_surface(ivisurf[1]);
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert(ivi_id == IVI_TEST_SURFACE_ID(1));
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_create_p2)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
struct ivi_layout_surface *ivisurf;
|
|
|
|
|
|
|
|
/* the ivi_surface was destroyed by the client */
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert(ivisurf == NULL);
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_visibility)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
struct ivi_layout_surface *ivisurf;
|
|
|
|
int32_t ret;
|
|
|
|
const struct ivi_layout_surface_properties *prop;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert(ivisurf);
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ret = lyt->surface_set_visibility(ivisurf, true);
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert(ret == IVI_SUCCEEDED);
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
prop = lyt->get_properties_of_surface(ivisurf);
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert(prop->visibility == true);
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_opacity)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
struct ivi_layout_surface *ivisurf;
|
|
|
|
int32_t ret;
|
|
|
|
const struct ivi_layout_surface_properties *prop;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert(ivisurf);
|
|
|
|
|
2016-03-04 15:50:12 +03:00
|
|
|
prop = lyt->get_properties_of_surface(ivisurf);
|
|
|
|
runner_assert(prop->opacity == wl_fixed_from_double(1.0));
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ret = lyt->surface_set_opacity(ivisurf, wl_fixed_from_double(0.5));
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert(ret == IVI_SUCCEEDED);
|
|
|
|
|
2016-03-04 15:50:12 +03:00
|
|
|
runner_assert(prop->opacity == wl_fixed_from_double(1.0));
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert(prop->opacity == wl_fixed_from_double(0.5));
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_dimension)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2015-06-22 09:33:17 +03:00
|
|
|
struct ivi_layout_surface *ivisurf;
|
|
|
|
const struct ivi_layout_surface_properties *prop;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert(ivisurf != NULL);
|
|
|
|
|
2016-03-04 15:50:28 +03:00
|
|
|
prop = lyt->get_properties_of_surface(ivisurf);
|
|
|
|
runner_assert_or_return(prop);
|
|
|
|
runner_assert(prop->dest_width == 1);
|
|
|
|
runner_assert(prop->dest_height == 1);
|
2015-06-22 09:33:17 +03:00
|
|
|
|
|
|
|
runner_assert(IVI_SUCCEEDED ==
|
2016-03-04 15:50:50 +03:00
|
|
|
lyt->surface_set_destination_rectangle(ivisurf, prop->dest_x,
|
|
|
|
prop->dest_y, 200, 300));
|
2015-06-22 09:33:17 +03:00
|
|
|
|
2016-03-04 15:50:28 +03:00
|
|
|
runner_assert(prop->dest_width == 1);
|
|
|
|
runner_assert(prop->dest_height == 1);
|
2015-06-22 09:33:17 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
2015-06-22 09:33:17 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
prop = lyt->get_properties_of_surface(ivisurf);
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert_or_return(prop);
|
|
|
|
runner_assert(prop->dest_width == 200);
|
|
|
|
runner_assert(prop->dest_height == 300);
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_position)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2015-06-22 09:33:17 +03:00
|
|
|
struct ivi_layout_surface *ivisurf;
|
|
|
|
const struct ivi_layout_surface_properties *prop;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert(ivisurf != NULL);
|
|
|
|
|
2016-03-04 15:50:20 +03:00
|
|
|
prop = lyt->get_properties_of_surface(ivisurf);
|
|
|
|
runner_assert_or_return(prop);
|
|
|
|
runner_assert(prop->dest_x == 0);
|
|
|
|
runner_assert(prop->dest_y == 0);
|
2015-06-22 09:33:17 +03:00
|
|
|
|
2016-03-04 15:50:43 +03:00
|
|
|
runner_assert(lyt->surface_set_destination_rectangle(
|
|
|
|
ivisurf, 20, 30,
|
|
|
|
prop->dest_width, prop->dest_height) == IVI_SUCCEEDED);
|
2015-06-22 09:33:17 +03:00
|
|
|
|
2016-03-04 15:50:20 +03:00
|
|
|
runner_assert(prop->dest_x == 0);
|
|
|
|
runner_assert(prop->dest_y == 0);
|
2015-06-22 09:33:17 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
2015-06-22 09:33:17 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
prop = lyt->get_properties_of_surface(ivisurf);
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert_or_return(prop);
|
|
|
|
runner_assert(prop->dest_x == 20);
|
|
|
|
runner_assert(prop->dest_y == 30);
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_destination_rectangle)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2015-06-22 09:33:17 +03:00
|
|
|
struct ivi_layout_surface *ivisurf;
|
|
|
|
const struct ivi_layout_surface_properties *prop;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert(ivisurf != NULL);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
prop = lyt->get_properties_of_surface(ivisurf);
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert_or_return(prop);
|
|
|
|
runner_assert(prop->dest_width == 1);
|
|
|
|
runner_assert(prop->dest_height == 1);
|
|
|
|
runner_assert(prop->dest_x == 0);
|
|
|
|
runner_assert(prop->dest_y == 0);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->surface_set_destination_rectangle(
|
2015-06-22 09:33:17 +03:00
|
|
|
ivisurf, 20, 30, 200, 300) == IVI_SUCCEEDED);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
prop = lyt->get_properties_of_surface(ivisurf);
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert_or_return(prop);
|
|
|
|
runner_assert(prop->dest_width == 1);
|
|
|
|
runner_assert(prop->dest_height == 1);
|
|
|
|
runner_assert(prop->dest_x == 0);
|
|
|
|
runner_assert(prop->dest_y == 0);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
2015-06-22 09:33:17 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
prop = lyt->get_properties_of_surface(ivisurf);
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert_or_return(prop);
|
|
|
|
runner_assert(prop->dest_width == 200);
|
|
|
|
runner_assert(prop->dest_height == 300);
|
|
|
|
runner_assert(prop->dest_x == 20);
|
|
|
|
runner_assert(prop->dest_y == 30);
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_source_rectangle)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2015-06-22 09:33:17 +03:00
|
|
|
struct ivi_layout_surface *ivisurf;
|
|
|
|
const struct ivi_layout_surface_properties *prop;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert(ivisurf != NULL);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
prop = lyt->get_properties_of_surface(ivisurf);
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert_or_return(prop);
|
|
|
|
runner_assert(prop->source_width == 0);
|
|
|
|
runner_assert(prop->source_height == 0);
|
|
|
|
runner_assert(prop->source_x == 0);
|
|
|
|
runner_assert(prop->source_y == 0);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->surface_set_source_rectangle(
|
2015-06-22 09:33:17 +03:00
|
|
|
ivisurf, 20, 30, 200, 300) == IVI_SUCCEEDED);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
prop = lyt->get_properties_of_surface(ivisurf);
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert_or_return(prop);
|
|
|
|
runner_assert(prop->source_width == 0);
|
|
|
|
runner_assert(prop->source_height == 0);
|
|
|
|
runner_assert(prop->source_x == 0);
|
|
|
|
runner_assert(prop->source_y == 0);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
prop = lyt->get_properties_of_surface(ivisurf);
|
2015-06-22 09:33:17 +03:00
|
|
|
runner_assert_or_return(prop);
|
|
|
|
runner_assert(prop->source_width == 200);
|
|
|
|
runner_assert(prop->source_height == 300);
|
|
|
|
runner_assert(prop->source_x == 20);
|
|
|
|
runner_assert(prop->source_y == 30);
|
tests: ivi_layout test infrastructure
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)
2015-03-25 13:50:31 +03:00
|
|
|
}
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
|
|
|
|
RUNNER_TEST(surface_bad_opacity)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
struct ivi_layout_surface *ivisurf;
|
2016-03-04 15:50:12 +03:00
|
|
|
const struct ivi_layout_surface_properties *prop;
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
runner_assert(ivisurf != NULL);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->surface_set_opacity(
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
NULL, wl_fixed_from_double(0.3)) == IVI_FAILED);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->surface_set_opacity(
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
ivisurf, wl_fixed_from_double(0.3)) == IVI_SUCCEEDED);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->surface_set_opacity(
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
ivisurf, wl_fixed_from_double(-1)) == IVI_FAILED);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
|
2016-03-04 15:50:12 +03:00
|
|
|
prop = lyt->get_properties_of_surface(ivisurf);
|
|
|
|
runner_assert(prop->opacity == wl_fixed_from_double(0.3));
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->surface_set_opacity(
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
ivisurf, wl_fixed_from_double(1.1)) == IVI_FAILED);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
|
2016-03-04 15:50:12 +03:00
|
|
|
runner_assert(prop->opacity == wl_fixed_from_double(0.3));
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->surface_set_opacity(
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
NULL, wl_fixed_from_double(0.5)) == IVI_FAILED);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
}
|
|
|
|
|
2016-06-07 12:40:21 +03:00
|
|
|
RUNNER_TEST(surface_on_many_layer)
|
|
|
|
{
|
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
|
|
|
struct ivi_layout_surface *ivisurf;
|
|
|
|
struct ivi_layout_layer *ivilayers[IVI_TEST_LAYER_COUNT] = {};
|
|
|
|
struct ivi_layout_layer **array;
|
|
|
|
int32_t length = 0;
|
|
|
|
uint32_t i;
|
|
|
|
|
|
|
|
ivisurf = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
|
|
|
runner_assert(ivisurf != NULL);
|
|
|
|
|
|
|
|
for (i = 0; i < IVI_TEST_LAYER_COUNT; i++) {
|
|
|
|
ivilayers[i] = lyt->layer_create_with_dimension(
|
|
|
|
IVI_TEST_LAYER_ID(i), 200, 300);
|
|
|
|
runner_assert(lyt->layer_add_surface(
|
|
|
|
ivilayers[i], ivisurf) == IVI_SUCCEEDED);
|
|
|
|
}
|
|
|
|
|
|
|
|
lyt->commit_changes();
|
|
|
|
|
|
|
|
runner_assert(lyt->get_layers_under_surface(
|
|
|
|
ivisurf, &length, &array) == IVI_SUCCEEDED);
|
|
|
|
runner_assert(IVI_TEST_LAYER_COUNT == length);
|
|
|
|
for (i = 0; i < IVI_TEST_LAYER_COUNT; i++)
|
|
|
|
runner_assert(array[i] == ivilayers[i]);
|
|
|
|
|
|
|
|
if (length > 0)
|
|
|
|
free(array);
|
|
|
|
|
|
|
|
for (i = 0; i < IVI_TEST_LAYER_COUNT; i++)
|
|
|
|
lyt->layer_remove_surface(ivilayers[i], ivisurf);
|
|
|
|
|
|
|
|
array = NULL;
|
|
|
|
|
|
|
|
lyt->commit_changes();
|
|
|
|
|
|
|
|
runner_assert(lyt->get_layers_under_surface(
|
|
|
|
ivisurf, &length, &array) == IVI_SUCCEEDED);
|
|
|
|
runner_assert(length == 0 && array == NULL);
|
|
|
|
|
|
|
|
for (i = 0; i < IVI_TEST_LAYER_COUNT; i++)
|
|
|
|
lyt->layer_destroy(ivilayers[i]);
|
|
|
|
}
|
|
|
|
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
RUNNER_TEST(ivi_layout_commit_changes)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(commit_changes_after_visibility_set_surface_destroy)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
struct ivi_layout_surface *ivisurf;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
runner_assert(ivisurf != NULL);
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->surface_set_visibility(
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
ivisurf, true) == IVI_SUCCEEDED);
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(commit_changes_after_opacity_set_surface_destroy)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
struct ivi_layout_surface *ivisurf;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
runner_assert(ivisurf != NULL);
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->surface_set_opacity(
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
ivisurf, wl_fixed_from_double(0.5)) == IVI_SUCCEEDED);
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(commit_changes_after_source_rectangle_set_surface_destroy)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
struct ivi_layout_surface *ivisurf;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
runner_assert(ivisurf != NULL);
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->surface_set_source_rectangle(
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
ivisurf, 20, 30, 200, 300) == IVI_SUCCEEDED);
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(commit_changes_after_destination_rectangle_set_surface_destroy)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
struct ivi_layout_surface *ivisurf;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
runner_assert(ivisurf != NULL);
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->surface_set_destination_rectangle(
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
ivisurf, 20, 30, 200, 300) == IVI_SUCCEEDED);
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(get_surface_after_destroy_surface)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
struct ivi_layout_surface *ivisurf;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
tests: test set for ivi-surface bad condition with helper client
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>
2015-06-22 09:33:26 +03:00
|
|
|
runner_assert(ivisurf == NULL);
|
|
|
|
}
|
|
|
|
|
2015-06-22 09:34:09 +03:00
|
|
|
RUNNER_TEST(layer_render_order)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2015-06-22 09:34:09 +03:00
|
|
|
struct ivi_layout_layer *ivilayer;
|
|
|
|
struct ivi_layout_surface *ivisurfs[IVI_TEST_SURFACE_COUNT] = {};
|
|
|
|
struct ivi_layout_surface **array;
|
|
|
|
int32_t length = 0;
|
|
|
|
uint32_t i;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivilayer = lyt->layer_create_with_dimension(IVI_TEST_LAYER_ID(0), 200, 300);
|
2015-06-22 09:34:09 +03:00
|
|
|
|
|
|
|
for (i = 0; i < IVI_TEST_SURFACE_COUNT; i++)
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurfs[i] = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(i));
|
2015-06-22 09:34:09 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->layer_set_render_order(
|
2015-06-22 09:34:09 +03:00
|
|
|
ivilayer, ivisurfs, IVI_TEST_SURFACE_COUNT) == IVI_SUCCEEDED);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
2015-06-22 09:34:09 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->get_surfaces_on_layer(
|
2015-06-22 09:34:09 +03:00
|
|
|
ivilayer, &length, &array) == IVI_SUCCEEDED);
|
|
|
|
runner_assert(IVI_TEST_SURFACE_COUNT == length);
|
|
|
|
for (i = 0; i < IVI_TEST_SURFACE_COUNT; i++)
|
|
|
|
runner_assert(array[i] == ivisurfs[i]);
|
|
|
|
|
|
|
|
if (length > 0)
|
|
|
|
free(array);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->layer_set_render_order(
|
2015-06-22 09:34:09 +03:00
|
|
|
ivilayer, NULL, 0) == IVI_SUCCEEDED);
|
|
|
|
|
|
|
|
array = NULL;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
2015-06-22 09:34:09 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->get_surfaces_on_layer(
|
2015-06-22 09:34:09 +03:00
|
|
|
ivilayer, &length, &array) == IVI_SUCCEEDED);
|
|
|
|
runner_assert(length == 0 && array == NULL);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->layer_destroy(ivilayer);
|
2015-06-22 09:34:09 +03:00
|
|
|
}
|
|
|
|
|
2015-06-22 09:34:42 +03:00
|
|
|
RUNNER_TEST(test_layer_render_order_destroy_one_surface_p1)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2015-06-22 09:34:42 +03:00
|
|
|
struct ivi_layout_layer *ivilayer;
|
|
|
|
struct ivi_layout_surface *ivisurfs[IVI_TEST_SURFACE_COUNT] = {};
|
|
|
|
struct ivi_layout_surface **array;
|
|
|
|
int32_t length = 0;
|
|
|
|
int32_t i;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivilayer = lyt->layer_create_with_dimension(IVI_TEST_LAYER_ID(0), 200, 300);
|
2015-06-22 09:34:42 +03:00
|
|
|
|
|
|
|
for (i = 0; i < IVI_TEST_SURFACE_COUNT; i++)
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurfs[i] = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(i));
|
2015-06-22 09:34:42 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->layer_set_render_order(
|
2015-06-22 09:34:42 +03:00
|
|
|
ivilayer, ivisurfs, IVI_TEST_SURFACE_COUNT) == IVI_SUCCEEDED);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
2015-06-22 09:34:42 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->get_surfaces_on_layer(
|
2015-06-22 09:34:42 +03:00
|
|
|
ivilayer, &length, &array) == IVI_SUCCEEDED);
|
|
|
|
runner_assert(IVI_TEST_SURFACE_COUNT == length);
|
|
|
|
for (i = 0; i < length; i++)
|
|
|
|
runner_assert(array[i] == ivisurfs[i]);
|
|
|
|
|
|
|
|
if (length > 0)
|
|
|
|
free(array);
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(test_layer_render_order_destroy_one_surface_p2)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2015-06-22 09:34:42 +03:00
|
|
|
struct ivi_layout_layer *ivilayer;
|
|
|
|
struct ivi_layout_surface *ivisurfs[2] = {};
|
|
|
|
struct ivi_layout_surface **array;
|
|
|
|
int32_t length = 0;
|
|
|
|
int32_t i;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivilayer = lyt->get_layer_from_id(IVI_TEST_LAYER_ID(0));
|
|
|
|
ivisurfs[0] = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
|
|
|
ivisurfs[1] = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(2));
|
2015-06-22 09:34:42 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->get_surfaces_on_layer(
|
2015-06-22 09:34:42 +03:00
|
|
|
ivilayer, &length, &array) == IVI_SUCCEEDED);
|
|
|
|
runner_assert(2 == length);
|
|
|
|
for (i = 0; i < length; i++)
|
|
|
|
runner_assert(array[i] == ivisurfs[i]);
|
|
|
|
|
|
|
|
if (length > 0)
|
|
|
|
free(array);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->layer_destroy(ivilayer);
|
2015-06-22 09:34:42 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(layer_bad_render_order)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2015-06-22 09:34:42 +03:00
|
|
|
struct ivi_layout_layer *ivilayer;
|
|
|
|
struct ivi_layout_surface *ivisurfs[IVI_TEST_SURFACE_COUNT] = {};
|
|
|
|
struct ivi_layout_surface **array = NULL;
|
|
|
|
int32_t length = 0;
|
|
|
|
uint32_t i;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivilayer = lyt->layer_create_with_dimension(IVI_TEST_LAYER_ID(0), 200, 300);
|
2015-06-22 09:34:42 +03:00
|
|
|
|
|
|
|
for (i = 0; i < IVI_TEST_SURFACE_COUNT; i++)
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurfs[i] = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(i));
|
2015-06-22 09:34:42 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->layer_set_render_order(
|
2015-06-22 09:34:42 +03:00
|
|
|
NULL, ivisurfs, IVI_TEST_SURFACE_COUNT) == IVI_FAILED);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
2015-06-22 09:34:42 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->get_surfaces_on_layer(
|
2015-06-22 09:34:42 +03:00
|
|
|
NULL, &length, &array) == IVI_FAILED);
|
|
|
|
runner_assert(length == 0 && array == NULL);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->get_surfaces_on_layer(
|
2015-06-22 09:34:42 +03:00
|
|
|
ivilayer, NULL, &array) == IVI_FAILED);
|
|
|
|
runner_assert(array == NULL);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->get_surfaces_on_layer(
|
2015-06-22 09:34:42 +03:00
|
|
|
ivilayer, &length, NULL) == IVI_FAILED);
|
|
|
|
runner_assert(length == 0);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->layer_destroy(ivilayer);
|
2015-06-22 09:34:42 +03:00
|
|
|
}
|
|
|
|
|
2017-01-18 18:25:35 +03:00
|
|
|
RUNNER_TEST(layer_add_surfaces)
|
|
|
|
{
|
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
|
|
|
struct ivi_layout_layer *ivilayer;
|
|
|
|
struct ivi_layout_surface *ivisurfs[IVI_TEST_SURFACE_COUNT] = {};
|
|
|
|
struct ivi_layout_surface **array;
|
|
|
|
int32_t length = 0;
|
|
|
|
uint32_t i;
|
|
|
|
|
|
|
|
ivilayer = lyt->layer_create_with_dimension(IVI_TEST_LAYER_ID(0), 200, 300);
|
|
|
|
|
|
|
|
for (i = 0; i < IVI_TEST_SURFACE_COUNT; i++) {
|
|
|
|
ivisurfs[i] = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(i));
|
|
|
|
runner_assert(lyt->layer_add_surface(
|
|
|
|
ivilayer, ivisurfs[i]) == IVI_SUCCEEDED);
|
|
|
|
}
|
|
|
|
|
|
|
|
lyt->commit_changes();
|
|
|
|
|
|
|
|
runner_assert(lyt->get_surfaces_on_layer(
|
|
|
|
ivilayer, &length, &array) == IVI_SUCCEEDED);
|
|
|
|
runner_assert(IVI_TEST_SURFACE_COUNT == length);
|
|
|
|
for (i = 0; i < IVI_TEST_SURFACE_COUNT; i++)
|
|
|
|
runner_assert(array[i] == ivisurfs[i]);
|
|
|
|
|
|
|
|
if (length > 0)
|
|
|
|
free(array);
|
|
|
|
|
|
|
|
runner_assert(lyt->layer_set_render_order(
|
|
|
|
ivilayer, NULL, 0) == IVI_SUCCEEDED);
|
|
|
|
|
|
|
|
for (i = IVI_TEST_SURFACE_COUNT; i-- > 0;)
|
|
|
|
runner_assert(lyt->layer_add_surface(
|
|
|
|
ivilayer, ivisurfs[i]) == IVI_SUCCEEDED);
|
|
|
|
|
|
|
|
lyt->commit_changes();
|
|
|
|
|
|
|
|
runner_assert(lyt->get_surfaces_on_layer(
|
|
|
|
ivilayer, &length, &array) == IVI_SUCCEEDED);
|
|
|
|
runner_assert(IVI_TEST_SURFACE_COUNT == length);
|
|
|
|
for (i = 0; i < IVI_TEST_SURFACE_COUNT; i++)
|
|
|
|
runner_assert(array[i] == ivisurfs[IVI_TEST_SURFACE_COUNT - (i + 1)]);
|
|
|
|
|
|
|
|
if (length > 0)
|
|
|
|
free(array);
|
|
|
|
|
|
|
|
lyt->layer_destroy(ivilayer);
|
|
|
|
}
|
|
|
|
|
2015-06-22 09:34:42 +03:00
|
|
|
RUNNER_TEST(commit_changes_after_render_order_set_surface_destroy)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2015-06-22 09:34:42 +03:00
|
|
|
struct ivi_layout_layer *ivilayer;
|
|
|
|
struct ivi_layout_surface *ivisurfs[IVI_TEST_SURFACE_COUNT] = {};
|
|
|
|
int i;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivilayer = lyt->layer_create_with_dimension(IVI_TEST_LAYER_ID(0), 200, 300);
|
2015-06-22 09:34:42 +03:00
|
|
|
|
|
|
|
for (i = 0; i < IVI_TEST_SURFACE_COUNT; i++)
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurfs[i] = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(i));
|
2015-06-22 09:34:42 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->layer_set_render_order(
|
2015-06-22 09:34:42 +03:00
|
|
|
ivilayer, ivisurfs, IVI_TEST_SURFACE_COUNT) == IVI_SUCCEEDED);
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(cleanup_layer)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2015-06-22 09:34:42 +03:00
|
|
|
struct ivi_layout_layer *ivilayer;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivilayer = lyt->get_layer_from_id(IVI_TEST_LAYER_ID(0));
|
|
|
|
lyt->layer_destroy(ivilayer);
|
2015-06-22 09:34:42 +03:00
|
|
|
}
|
|
|
|
|
2015-06-22 09:35:58 +03:00
|
|
|
static void
|
2016-04-04 11:05:03 +03:00
|
|
|
test_surface_properties_changed_notification_callback(struct wl_listener *listener, void *data)
|
|
|
|
|
2015-06-22 09:35:58 +03:00
|
|
|
{
|
2016-04-04 11:05:03 +03:00
|
|
|
struct test_context *ctx =
|
|
|
|
container_of(listener, struct test_context,
|
|
|
|
surface_property_changed);
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2016-04-04 11:05:03 +03:00
|
|
|
struct ivi_layout_surface *ivisurf = data;
|
2015-06-22 09:35:58 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert_or_return(lyt->get_id_of_surface(ivisurf) == IVI_TEST_SURFACE_ID(0));
|
2015-06-22 09:35:58 +03:00
|
|
|
|
|
|
|
ctx->user_flags = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_properties_changed_notification)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2015-06-22 09:35:58 +03:00
|
|
|
const uint32_t id_surface = IVI_TEST_SURFACE_ID(0);
|
|
|
|
struct ivi_layout_surface *ivisurf;
|
|
|
|
|
|
|
|
ctx->user_flags = 0;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf = lyt->get_surface_from_id(id_surface);
|
2015-06-22 09:35:58 +03:00
|
|
|
runner_assert(ivisurf != NULL);
|
|
|
|
|
2016-04-04 11:05:03 +03:00
|
|
|
ctx->surface_property_changed.notify = test_surface_properties_changed_notification_callback;
|
|
|
|
|
|
|
|
runner_assert(lyt->surface_add_listener(
|
|
|
|
ivisurf, &ctx->surface_property_changed) == IVI_SUCCEEDED);
|
2015-06-22 09:35:58 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
2015-06-22 09:35:58 +03:00
|
|
|
|
|
|
|
runner_assert(ctx->user_flags == 0);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->surface_set_destination_rectangle(
|
2015-06-22 09:35:58 +03:00
|
|
|
ivisurf, 20, 30, 200, 300) == IVI_SUCCEEDED);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
2015-06-22 09:35:58 +03:00
|
|
|
|
|
|
|
runner_assert(ctx->user_flags == 1);
|
|
|
|
|
|
|
|
ctx->user_flags = 0;
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->surface_set_destination_rectangle(
|
2015-06-22 09:35:58 +03:00
|
|
|
ivisurf, 20, 30, 200, 300) == IVI_SUCCEEDED);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
2015-06-22 09:35:58 +03:00
|
|
|
|
|
|
|
runner_assert(ctx->user_flags == 0);
|
|
|
|
|
2016-04-04 11:05:03 +03:00
|
|
|
// remove surface property changed listener.
|
|
|
|
wl_list_remove(&ctx->surface_property_changed.link);
|
2015-06-22 09:35:58 +03:00
|
|
|
ctx->user_flags = 0;
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert(lyt->surface_set_destination_rectangle(
|
2015-06-22 09:35:58 +03:00
|
|
|
ivisurf, 40, 50, 400, 500) == IVI_SUCCEEDED);
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
2015-06-22 09:35:58 +03:00
|
|
|
|
|
|
|
runner_assert(ctx->user_flags == 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2016-04-04 11:05:20 +03:00
|
|
|
test_surface_configure_notification_callback(struct wl_listener *listener, void *data)
|
2015-06-22 09:35:58 +03:00
|
|
|
{
|
2016-04-04 11:05:20 +03:00
|
|
|
struct test_context *ctx =
|
|
|
|
container_of(listener, struct test_context,
|
|
|
|
surface_configured);
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2016-04-04 11:05:20 +03:00
|
|
|
struct ivi_layout_surface *ivisurf = data;
|
2015-06-22 09:35:58 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert_or_return(lyt->get_id_of_surface(ivisurf) == IVI_TEST_SURFACE_ID(0));
|
2015-06-22 09:35:58 +03:00
|
|
|
|
|
|
|
ctx->user_flags = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_configure_notification_p1)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2015-06-22 09:35:58 +03:00
|
|
|
|
2016-04-04 11:05:20 +03:00
|
|
|
ctx->surface_configured.notify = test_surface_configure_notification_callback;
|
|
|
|
runner_assert(IVI_SUCCEEDED == lyt->add_listener_configure_surface(&ctx->surface_configured));
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
2015-06-22 09:35:58 +03:00
|
|
|
|
|
|
|
ctx->user_flags = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_configure_notification_p2)
|
|
|
|
{
|
|
|
|
runner_assert(ctx->user_flags == 1);
|
|
|
|
|
2016-04-04 11:05:20 +03:00
|
|
|
// remove surface configured listener.
|
|
|
|
wl_list_remove(&ctx->surface_configured.link);
|
2015-06-22 09:35:58 +03:00
|
|
|
ctx->user_flags = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_configure_notification_p3)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2015-06-22 09:35:58 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
lyt->commit_changes();
|
2015-06-22 09:35:58 +03:00
|
|
|
runner_assert(ctx->user_flags == 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2016-04-04 11:05:09 +03:00
|
|
|
test_surface_create_notification_callback(struct wl_listener *listener, void *data)
|
2015-06-22 09:35:58 +03:00
|
|
|
{
|
2016-04-04 11:05:09 +03:00
|
|
|
struct test_context *ctx =
|
|
|
|
container_of(listener, struct test_context,
|
|
|
|
surface_created);
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2016-04-04 11:05:09 +03:00
|
|
|
struct ivi_layout_surface *ivisurf = data;
|
2015-06-22 09:35:58 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert_or_return(lyt->get_id_of_surface(ivisurf) == IVI_TEST_SURFACE_ID(0));
|
2015-06-22 09:35:58 +03:00
|
|
|
|
|
|
|
ctx->user_flags = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_create_notification_p1)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2015-06-22 09:35:58 +03:00
|
|
|
|
2016-04-04 11:05:09 +03:00
|
|
|
ctx->surface_created.notify = test_surface_create_notification_callback;
|
|
|
|
runner_assert(lyt->add_listener_create_surface(
|
|
|
|
&ctx->surface_created) == IVI_SUCCEEDED);
|
2015-06-22 09:35:58 +03:00
|
|
|
|
|
|
|
ctx->user_flags = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_create_notification_p2)
|
|
|
|
{
|
|
|
|
runner_assert(ctx->user_flags == 1);
|
|
|
|
|
2016-04-04 11:05:09 +03:00
|
|
|
// remove surface created listener.
|
|
|
|
wl_list_remove(&ctx->surface_created.link);
|
2015-06-22 09:35:58 +03:00
|
|
|
ctx->user_flags = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_create_notification_p3)
|
|
|
|
{
|
|
|
|
runner_assert(ctx->user_flags == 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2016-04-04 11:05:18 +03:00
|
|
|
test_surface_remove_notification_callback(struct wl_listener *listener, void *data)
|
2015-06-22 09:35:58 +03:00
|
|
|
{
|
2016-04-04 11:05:18 +03:00
|
|
|
struct test_context *ctx =
|
|
|
|
container_of(listener, struct test_context,
|
|
|
|
surface_removed);
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2016-04-04 11:05:18 +03:00
|
|
|
struct ivi_layout_surface *ivisurf = data;
|
2015-06-22 09:35:58 +03:00
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
runner_assert_or_return(lyt->get_id_of_surface(ivisurf) == IVI_TEST_SURFACE_ID(0));
|
2015-06-22 09:35:58 +03:00
|
|
|
|
|
|
|
ctx->user_flags = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_remove_notification_p1)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2015-06-22 09:35:58 +03:00
|
|
|
|
2016-04-04 11:05:18 +03:00
|
|
|
ctx->surface_removed.notify = test_surface_remove_notification_callback;
|
|
|
|
runner_assert(lyt->add_listener_remove_surface(&ctx->surface_removed)
|
|
|
|
== IVI_SUCCEEDED);
|
2015-06-22 09:35:58 +03:00
|
|
|
|
|
|
|
ctx->user_flags = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_remove_notification_p2)
|
|
|
|
{
|
|
|
|
runner_assert(ctx->user_flags == 1);
|
|
|
|
|
2016-04-04 11:05:18 +03:00
|
|
|
// remove surface removed listener.
|
|
|
|
wl_list_remove(&ctx->surface_removed.link);
|
2015-06-22 09:35:58 +03:00
|
|
|
ctx->user_flags = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_remove_notification_p3)
|
|
|
|
{
|
|
|
|
runner_assert(ctx->user_flags == 0);
|
|
|
|
}
|
2015-06-22 09:36:21 +03:00
|
|
|
|
|
|
|
static void
|
2016-04-04 11:05:03 +03:00
|
|
|
test_surface_bad_properties_changed_notification_callback(struct wl_listener *listener, void *data)
|
2015-06-22 09:36:21 +03:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
RUNNER_TEST(surface_bad_properties_changed_notification)
|
|
|
|
{
|
2015-10-15 17:51:41 +03:00
|
|
|
const struct ivi_layout_interface *lyt = ctx->layout_interface;
|
2015-06-22 09:36:21 +03:00
|
|
|
struct ivi_layout_surface *ivisurf;
|
|
|
|
|
2015-10-15 17:51:41 +03:00
|
|
|
ivisurf = lyt->get_surface_from_id(IVI_TEST_SURFACE_ID(0));
|
2015-06-22 09:36:21 +03:00
|
|
|
runner_assert(ivisurf != NULL);
|
|
|
|
|
2016-04-04 11:05:03 +03:00
|
|
|
ctx->surface_property_changed.notify = test_surface_bad_properties_changed_notification_callback;
|
|
|
|
|
|
|
|
runner_assert(lyt->surface_add_listener(
|
|
|
|
NULL, &ctx->surface_property_changed) == IVI_FAILED);
|
|
|
|
runner_assert(lyt->surface_add_listener(
|
|
|
|
ivisurf, NULL) == IVI_FAILED);
|
2015-06-22 09:36:21 +03:00
|
|
|
}
|