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

[Derek Foreman]

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.

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...

> 
> Thanks,
> pq
>