[RFC] [tests] Running the wayland tests against compositor-headless

[Sam Spilsbury]

On Mon, Apr 22, 2013 at 11:02 PM, Eoff, Ullysses A
<ullysses.a.eoff at intel.com> wrote:
>> -----Original Message-----
>> From: Sam Spilsbury [mailto:smspillaz at gmail.com]
>>>
>>> <snip>
>>>

<snip>

>
> Yes, it would be trivial to enable the input-based tests to run on the
> headless backend... however, it's unclear to me whether the headless
> backend should be the one responsible for initializing/tracking the
> keyboard and pointer inputs.  That kinda feels counter intuitive to the
> definition of "headless" (but perhaps not :-/).  Maybe we could have the
> weston-test extension module initialize the inputs in an idle loop
> callback, for example if the output->model == "headless", then
> do:
>
>         weston_seat_init_pointer(seat);
>         weston_seat_init_keyboard(seat, NULL);
>

They'll probably need to be lazy-initialized at least. At the moment
weston is segfaulting because the tests trigger callbacks in weston
that expect the pointer and keyboard interfaces to be present on a
seat. Either that or a "headless" seat implementation might be in
order.

> For the other two, which ones are they and what kind of protocol
> support is lacking?  Perhaps there is another way we can get them
> to work on "headless"?
>
>> The broader reason I'm looking into this is because I want to see if
>> we can eventually export the weston-test module as part of the
>> installation as well as the headless and no-op backends so that
>> applications can run integration tests against weston to verify that
>> they handle input, shell surface changes etc correctly. I'm looking
>> into doing some GSoC work on a project where I suspect that the
>> wayland backend will not be run all the time, and it will be good to
>> have integration tests in place to ensure that it doesn't break
>> accidentally because developers may not be able to run it regularly.
>>
>
> The headless backend module gets installed, already.  But if you're
> also talking about exporting headless backend header(s), then I'm
> willing to bet that won't happen.
>
> As for the weston-test module being exported (module and headers),
> that would have to be the maintainer's decision (Kristian; aka, krh)
> and/or a consensus from other community contributors.
>
> If nothing else, you can always write your own test extension, too, that
> will enable you to do integration testing on your particular application
> use-cases.

Lets have a discussion about this when Kristian gets back. I think
having an upstreamed module providing wl_test will be beneficial for
lots of downstream application developers because it means they can
use some common protocol which they know works and integrate that into
their applications.

In the event that we don't want to do that, another alternative would
be to look into making weston-test an external module as part of a
broader external modules proposal so it can have its own direction in
terms of what it supports.

Of course the final alternative is to just have applications ship
their own modules and test protocols, but this is not really ideal.

>
>> So - shall I create and submit some patches to get the tests working
>> on headless? I suppose this is a desirable thing right?
>>
>
> I wouldn't be the one to make the ultimate decision on their
> inclusions into upstream.  It'd be nice to hear what others think about
> this topic, too.  Either way, it wouldn't hurt to send patches for review,
> feedback, and discussion... even if they end up getting rejected for a
> different solution ;).

I'll write up some patches ASAP.

>
>> Best,
>>
>> Sam
>>
>> > <snip>
>
> Cheers,
>
> U. Artie


Thanks,

Sam

--
Sam Spilsbury