libweston: Introduce weston-clock to support fake time
weston-clock is a component that abstracts time related functionality and allows us to replace real time with fake time that can be controlled by test clients.
On the server side we replace calls to relevant time related functions with weston_clock_* functions. These functions use either real time (by default) or fake time if configured to do so. On the compositor level this configuration is currently performed with an environment variable. It would be cleaner to configure this with a config file entry, but weston_compositor creation is not currently configurable. Let's discuss more about next steps to improve the situation.
weston-clock uses the same fake time for all clocks, since we don't have a current testing need for more independent clocks and it makes the code simpler, but it's not hard to change this in the future if required.
weston-clock also provides the weston_clock internal protocol which can be used by test clients to control the passage of time.
As an example of using fake time with weston-clock, presentation-test is updated to use fake time and verify the presentation time returned from the presentation feedback protocol. This verification requires knowledge of specific delays employed by weston core and the headless backend, so a future improvement would be to configure these parameters from within the test, to remove any such assumptions about the code under test.
v2:
- Made weston-clock related state local/per-compositor, encapsulated in an opaque
struct weston_clock - Provided weston_compositor_* convenience functions for timers that wrap around the internal weston_clock.
- Changed client_advance_time() test helper function to use struct timespec.
- Added a more complex weston-clock test verifying correct behavior with a long chain of dependent events.
- Modified test infrastructure to provide the compositor in client tests, and used this feature to verify the compositor repaint state in presentation-test (see last two commits). If these modifications turn out to be a point of contention we may want to move them to a separate MR for further discussion.