Skip to content
Wayland Functional Integration Test Suite - This project is no longer maintained and looking for new maintainer/owner..
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
.gitignore .gitignore: ignore autogenerated test-driver Oct 16, 2013
COPYING add COPYING and copyright to source files Apr 29, 2013 Refactored project layout and build results Sep 14, 2012
README Need new maintainer May 5, 2017
TODO more README and TODO updates May 15, 2013 initialize project Apr 18, 2012 test/efl: make actionslider test compatible with 1.9.99 Mar 19, 2014




Wayland Functional Integration Test Suite (aka. wayland-fits)

Wayland-fits is a fully automated functional integration test suite.  It's
main purpose is to test the functionality and integration of client-side
(i.e. toolkit) and server-side (compositor) implementations of the Wayland
protocol.  It includes tests that validate user input events originating from
the server-side or from an emulated system-level device (depends on the type
of backend used).  There are also tests with emphasis on cross-validating client
and server states.

The test framework design includes a wayland-fits test extension that defines two
Wayland protocols. The first protocol is a interface for generating input events
on the server-side (e.g. mouse, keyboard, touch). The second is a interface for
querying state information from the server/compositor.  This extension is
exploited by most of the tests.  Thus, to run these tests on a particular Wayland
server/compositor, there has to be an implementation of this extension for that
compositor (i.e. src/extensions/<compositor>).

A Weston implementation of the wayland-fits test extension ( is
included as a pluggable module to Weston.  For the drm and x11 backends, it
employs uinput to emulate various input devices.  For the headless backend, it
uses the weston input API's directly.  It also exposes various other
internal compositor states that can be queried by tests, such as surface
geometry and pointer coordinates.


MIT - see COPYING file


 * check - A unit testing framework for C >= 0.9.8
 * boost - Boost C++ libraries >= 1.48.0
 * Wayland >= 1.2.0
 * Weston >= 1.2.0

 * EFL/Elementary Wayland >= 1.7.6
 * GTK+ Wayland
 * Cogl/Clutter Wayland (future development)
 * Qt Wayland (future development)


 $ ./
 $ make
 $ make install

 See for more information on general
 Wayland building requirements/options (e.g. installing in a custom location).


 You need to load the wayland-fits test extension into your Wayland compositor (Note:
 an implementation of the wfits test extension is needed for each compositor,
 currently Weston is the only one supported at the moment):

 For Weston, this is "" and it's loaded with the --modules option:

  $ weston &

  NOTE: The module supports x11-backend, drm-backend, and the
  headless-backend.  However, not all tests can be run on the headless-backend;
  particularly the egl-based ones.

  NOTE: Ensure that all shell animations are turned off (i.e. in weston.ini).
  These animations have a tendency to break the input-based test cases.

 If you define the environment variable WESTON_WFITS_INPUT_EMULATOR=<method>, the module will use that method when it loads at startup.  The
 available methods are 'notify' and 'uinput'.  The 'notify' method does not require
 a suid/root weston whereas the 'uinput' method does.

 Next, run the test suite:

  $ wfits

 You can filter the tests you want to run by using the --filter option.  This
 option takes a boost-regex style expression (POSIX-extended, case-ignored),
 for example:

  $ wfits --filter core.*
  $ wfits --filter .*pointer.*

 Run 'wfits --help' for more options.
 NOTE: You can set the environment variable "CK_FORK=no" to have wfits run in non-forked
 test mode.  This is especially useful for debugging with gdb
 (e.g. CK_FORK=no gdb --args wfits --filter <testname>).


 If a test is failing, try to determine if it's an actual bug in the test or a
 bug in the component that is being tested.  If it's a bug in the test, file at:

 Otherwise, file a bug in the appropriate database assigned to the failing
 Wayland component if one does not already exist.


 Send patches via github pull requests:

You can’t perform that action at this time.