buffer-count was introduced in line with a Mesa change which forced
an earlier block on frame events to try to enforce double-buffering
where available.
The Mesa change has since been reverted (Mesa commit 9ca6711faa), as
this had unpleasant interactions with buffer_age in particular, so this
test is no longer valid.
Additionally, it only worked on backends which initialised EGL (not
headless-backend, where tests generally run), which can be flaky due to
initialisation races. Not only that, but on the DRM backend, we can
legitimately enter triple-buffering due to promoting the surface to a
hardware plane, skipping GPU composition.
In light of all this, just remove the test.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
This adds a capture_screenshot request which returns an image of the
screen in the client-supplied wl_buffer for the given display output.
A 'done' event is used to indicate when screenshotting has finished and
the wl_buffer is ready to be read.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
Testing the ivi_layout API requires two things:
- the tests must be written as a controller module to access the API
- the tests need a helper client to create some objects that can then be
managed via the API
This patch adds all the infrastructure and two different kinds of
example tests.
Internal ivi-shell (ivi_layout) API tests are listed as ivi-*.la files
in TESTS in Makefile.am. Weston-tests-env detects these, and runs Weston
with ivi-shell, and loads the given module as a controller module, not
as a normal plugin.
The test controller module ivi-*.la will launch a helper client. For
ivi-layout-test.la the helper client is ivi-layout.ivi.
The helper client uses the weston-test-runner framework to fork and exec
each TEST with a fresh connection to the compositor.
The actual test is triggered by the weston_test_runner protocol
interface, a new addition to weston-test.xml. The helper client uses
weston_test_runner to trigger a test, and the server side of the
interface is implemented by the test controller module
(ivi-layout-test.la).
The server side of weston_test_runner uses the same trick as
weston-test-runner.h to gather a list of defined tests. A test is
defined with the RUNNER_TEST macro.
If a test defined by RUNNER_TEST succeeds, an event is sent to the
helper client that it can continue (or exit). If a test fails, a fatal
protocol error is sent to the helper client.
Once the helper client has iterated over all of its tests, it signals
the batch success/failure via process exit code. That is cought in the
test controller module, and forwarded as Weston's exit code.
In summary: each ivi_layout test is a combination of a client side
helper/setup and server side actual tests.
v2: Load weston-test.so, because create_client() needs it.
v3: add a comment about IVI_TEST_SURFACE_ID_BASE.
v4: Rebased to upstream weston-tests-env changes.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com> (v2)
This request simulates device creation/destruction from evdev (libinput)
v2: added support for touch. Touch is not supported yet,
but better be prepared
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
wayland-test isn't and will never be wayland protocol, it's weston internal.
Renamed wayland-test to weston-test, and wl_test to weston_test.
Also added a Big Fat Warning to the description of weston_test to try to
keep people from thinking it's a good idea to use some of these functions
outside of testing.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Acked-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
