How to test Weston gfx (Re: Weston test suite)

Pekka Paalanen ppaalanen at
Mon Aug 31 01:58:31 PDT 2015

On Tue, 25 Aug 2015 10:43:22 +0300
Pekka Paalanen <ppaalanen at> wrote:

> On Tue, 25 Aug 2015 10:16:17 +0300
> Pekka Paalanen <ppaalanen at> wrote:
> > Btw. I CC'd you on
> > where we have been talking about testing things. I wonder how you'd
> > handle some tests being specific to a backend, and some tests being
> > generic such that a user (the person doing 'make check') could run it
> > against any backend he chooses? If we need such things... perhaps
> > backend-specificity comes mostly from configuration and options, so
> > maybe we might be able to unify the options so much that the
> > differences don't matter.
> > 
> > And then screenshot-based tests are likely something we want to run
> > once for each possible renderer for a chosen backend.
> > 
> > 
> > Hmm... I just got an idea.
> > 
> > We've been adding renderer support to so that we
> > could run screenshot-based tests headless. What if... we kept headless
> > backend without real renderers (only mocked renderer, one capable of
> > initialising EGL_WL_bind_wayland_display though), ran Weston/wayland on
> > top of Weston/headless, and test clients on the Weston/wayland instance?
> > 
> > It might require some work on the wayland-backend, but it would also
> > leave all testing related mocks and hacks into the headless backend
> > code, without leaking it into gl-renderer or such. And it would stress
> > the wayland-backend which I imagine could use more use.
> > 
> > Well, that's just a wild idea, I'm not sure what it would entail. What
> > do you all think?
> Wait... using Weston/headless to host Weston/wayland would immediately
> enable software GL rendering, wouldn't it? The EGL Wayland platform in
> Mesa today supports software-GL on wl_shm. This means we should be able
> to test Weston's gl-renderer on llvmpipe by just running it with the
> wayland-backend on another Weston instace.

Hi all,

I think this needs a bit of discussion. Should we be adding more and
more renderer features into the headless backend, or should we move to
running Weston/wayland on top of Weston/headless for 'make check'?

It is a blocker question for things like
which Dawid is working on.

Derek, I recall you had plans to control Weston's repaint loop from
tests. How would that be affected if we run nested instead of directly
on headless?

The reason why I like the nested approach now is that while it allows
immediately to run things with llvmpipe, we would not need to modify
gl-renderer to e.g. render into an FBO just for testing. We could have
the headless backend even initialize a render node and support
EGL_WL_bind_wayland_display. Code only related to testing would be
limited into the headless backend with its built-in mock-renderer.

What do you think?

Hmm, and we could pull in fullscreen-shell into the mix and use it on
headless. The wayland backend seems to already have code for
it. This would avoid running weston-desktop-shell or the VKB app for
the headless instance.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the wayland-devel mailing list