[PATCH weston 6/6] compositor-headless: Add test mode

[Derek Foreman]

On 27/03/15 07:50 AM, Pekka Paalanen wrote:
> On Tue, 27 Jan 2015 12:38:46 +0000
> Daniel Stone <daniel at fooishbar.org> wrote:
> 
>> Hi,
>>
>> On 19 December 2014 at 18:45, Derek Foreman <derekf at osg.samsung.com> wrote:
>>>  static int
>>>  headless_output_repaint(struct weston_output *output_base,
>>>                        pixman_region32_t *damage)
>>>  {
>>>         struct headless_output *output = (struct headless_output *) output_base;
>>>         struct weston_compositor *ec = output->base.compositor;
>>> +       struct wl_event_loop *loop;
>>>
>>>         ec->renderer->repaint_output(&output->base, damage);
>>>
>>>         pixman_region32_subtract(&ec->primary_plane.damage,
>>>                                  &ec->primary_plane.damage, damage);
>>>
>>> -       wl_event_source_timer_update(output->finish_frame_timer, 16);
>>> +       if (ec->test_mode) {
>>> +               loop = wl_display_get_event_loop(ec->wl_display);
>>> +               wl_event_loop_add_idle(loop, finish_frame_handler_idle, output_base);
>>> +       } else
>>> +               wl_event_source_timer_update(output->finish_frame_timer, 16);
>>>
>>>         return 0;
>>>  }
>>
>> Hmm, these make me a bit nervous, and like we should perhaps be doing
>> this at a higher level - e.g. in the core repaint/finish_frame, rather
>> than per-backend. That would mean we could do automated testing of,
>> e.g., the DRM backend, when your hardware supports CRC summing, as at
>> least Intel and Exynos do.
>>
>> Was this something you looked at and discarded? If there's good reason
>> to avoid it then fair enough, but if not, it'd be good to check out so
>> we can get more equal testing.

Hadn't occurred to me. :(

When I wrote this I hadn't really considered its use outside of the
headless backend.

> Hmm... maybe the test client would need even more control over the
> repaint cycle: an event to tell when the backend would like to call
> finish_frame in realtime, and a request to actually call finish_frame
> after you have possibly munged the clock. That should keep the hardware
> in sync with test actions.

Nice - that's at least a step towards how I'm going to fix the drm
vblank_handler having a clock source of its own.

Perhaps the client should co-operate with the hardware to generate a
fake vblank event.

set clock
call repaint
set clock again
inject a fake vblank

the finish frame handler won't actually occur until both a real vblank
from the hardware and a fake vblank from the client occur?  The
timestamp of the event would come from the fake clock instead of the
vblank event.

I think I can do this without badgering individual back-ends.

Thanks for looking, both of you - sorry to take so long to get back to it!