With Mir 0.28 we’ve got basic Wayland client support - keyboard, mouse, and touch input, (mesa) EGL and software client rendering, and a bit of basic window management via wl_shell. Mir 0.28.1 will fix up a couple of bugs there, particularly a nasty one involving Xwayland, and should be the first Mir release building on Fedora including the testsuite.
So, what’s next for Mir’s Wayland support?
The work we’ve done so far has been based on some work I did in 2015 to investigate the feasibility of providing a Wayland socket; obviously the result was “yes, that’s feasible”. There’s a significant difference between the current Wayland-support code and the rest of the code in Mir, though - the Wayland code has approximately no tests!
That’s what I’m doing next for Mir’s Wayland support.
There’s currently not a good Wayland test suite - something you can run against your compositor implementation to verify that your implementation of the protocol behaves as expected. There have been a number of projects started, but they’ve never really gone anywhere. Weston has some tests, but they don’t even approximate a full conformance suite.
We have lots of good infrastructure in the Mir testsuite for running compositor tests. While we’ve never had a Mir conformance suite - supporting competing implementations of libmirserver has been an explicit non-goal - our acceptance tests have a pretty good coverage of server behaviour. As a first pass I’ll be porting the Weston testsuite to use some of this infrastructure.
But there are lots of compositors implementing Wayland protocols. All of them would benefit from a conformance suite, and we could benefit from other people writing conformance tests. It would be particularly excellent if we could get to a point where any new protocol proposal was expected to come with a set of conformance tests! So while I’m developing these tests for Mir, I’ll be doing so in a way that can be generalised to other projects.
The Weston testsuite is based on a private weston_test_runner protocol, and goes over the same Wayland socket as a regular client. This has the advantage that your tests can be individual small binaries run against your regular server binary. It has the disadvantage that your tests run in a different process to your server, which makes it harder to write tests. Most of the Mir testsuite runs the compositor in the same process as the tests, so they can read compositor memory, easily use mutexes for synchronisation, and so on. Fortunately, the architecture of most Wayland compositors means we can keep the in-process testing - they’re built as a library that a shell uses.
So, once the testsuite is up and running and I’ve got Mir using it, it can be exported as a separate libwlcs project. Then other compositors should be able to add an extra build target, provide a small C API and link to libwlcs to build a conformance-suite binary.