Architect internal API for special test setup
Tests may often want to configure bits inside the compositor, to do things that only make sense for very specific tests. For example, use fake clocks in !453 or forbid the use of the renderer screenshooting function in !458 or disable atomic modesetting (a hypothetical future test to ensure legacy KMS keeps working).
We could use environment variables for those, but they make an awkward API.
We already have
wet_testsuite_data_get() that are roughly at the right level in
compositor/testsuite-util.c, but their problem is that they depend on a global variable to work. If we are ever going to run tests on e.g. the wayland-backend, which requires running two instances of Weston, any kind of global data is going to be a problem.
Therefore the test settings should be made on an object that is per-compositor-instance, probably on
struct weston_compositor or something new that can be used by
wet_main() and forwarded. We could add a new argument to
wet_main() that is
NULL when called from
compositor/executable.c but carries the test setup when called from
We can also add stable ABI to libweston to set these special test bits, I don't think that hurts when documented properly. The test bits flow would be: test -> compositor fixture ->
wet_main -> libweston.
Having proper API (functions) for this stuff also make it clear where to document these tricks, when other projects want to use Weston as a test bed and maybe control things like the clocks.
I'm thinking that all the test bits should probably be in a single new
struct that has a single path through the whole weston stack from the executable to the backends and plugins. No functions that are specific for a backend, for instance. These test bits probably do not need to be toggleable after compositor start. Making something that is toggleable on the fly or ever introducing direct function calls between a compositor and a client is something for another time.