[PATCH weston 5/6] test: Add client driven repaint

[Pekka Paalanen]

On Thu, 02 Apr 2015 12:47:38 -0500
Derek Foreman <derekf at osg.samsung.com> wrote:

> On 27/03/15 07:44 AM, Pekka Paalanen wrote:
> > On Fri, 19 Dec 2014 12:45:49 -0600
> > Derek Foreman <derekf at osg.samsung.com> wrote:
> > 
> >> Allow a test client to call for a repaint.
> >>
> >> Signed-off-by: Derek Foreman <derekf at osg.samsung.com>
> >> ---
> >>  protocol/wayland-test.xml | 1 +
> >>  tests/weston-test.c       | 9 +++++++++
> >>  2 files changed, 10 insertions(+)
> >>
> >> diff --git a/protocol/wayland-test.xml
> >> b/protocol/wayland-test.xml index 7133555..4b914b4 100644
> >> --- a/protocol/wayland-test.xml
> >> +++ b/protocol/wayland-test.xml
> >> @@ -64,5 +64,6 @@
> >>        <arg name="sec" type="string"/>
> >>        <arg name="nsec" type="string"/>
> >>      </request>
> >> +    <request name="repaint"/>
> >>    </interface>
> >>  </protocol>
> >> diff --git a/tests/weston-test.c b/tests/weston-test.c
> >> index ba37cdf..8d64d89 100644
> >> --- a/tests/weston-test.c
> >> +++ b/tests/weston-test.c
> >> @@ -255,6 +255,14 @@ settime(struct wl_client *client, struct
> >> wl_resource *resource,
> >> weston_compositor_presentation_clock_settime(test->compositor,
> >> &ts); } 
> >> +static void
> >> +repaint(struct wl_client *client, struct wl_resource
> >> *resource) +{
> >> +	struct weston_test *test =
> >> wl_resource_get_user_data(resource); +
> >> +	weston_compositor_schedule_repaint(test->compositor);
> >> +}
> >> +
> >>  static const struct wl_test_interface test_implementation = {
> >>  	move_surface,
> >>  	move_pointer,
> >> @@ -264,6 +272,7 @@ static const struct wl_test_interface
> >> test_implementation = { get_n_buffers,
> >>  	enable_test_mode,
> >>  	settime,
> >> +	repaint,
> >>  };
> >>  
> >>  static void
> > 
> > So, does patch 4 and this together mean that Weston will not
> > repaint at all unless commanded by the repaint request?
> 
> Right.  That was the intent.
> 
> > If yes, I think this should solve the repaint delay timer
> > problem completely: it becomes the responsibility of the test
> > client to control both the clock and the repaints to happen as
> > intended. In test mode, the repaint timer would simply not be
> > used at all.
> > 
> > However, does this cause the timing-sensitive areas of repaint
> > to become untestable? Maybe that's a good thing, timing
> > sensitive tests are usually non-deterministic.
> 
> Hmm, the drm vblank handler uses times from a clock we're not
> wrapping, so that will probably make some things untestable.
> I'll need to think about wrapping that one.

Are you referring to the drm vblank handler that is only used with
hw planes (sprites)?

If yes, feel free to ignore it. It's part of the known-broken hw
planes code which will be replaced with atomic.

If it's the drm page flip completion, then I suppose we might need
to relay that to test client instead... but all that adds a lot of
complexity, putting the test client in charge of driving all the
sequences which means we don't test weston's own logic.

That's what I mean by untestable: putting too much control into the
test client, which may deviate from Weston's own logic.


Thanks,
pq
 
> Is that the only timing sensitive part I've missed?
> 
> I don't see how we can reliably use "how long we waited for (a
> real) vblank" or anything like that in a test...